> Alan,
>
> Why is it that you insist on this model?
>
> Your application will not scale if you insist on causing an entire dataset
> to be scanned on the server just to fetch a single record out of it.

I'm not - you're making incorrect assumptions. I am not trying to locate one
record from an SSP. I am trying to remove the CURSOR unknown error. I
suspect now that a mix of raKeepdatapos and keylink being defined where SSP
are being used maybe the culprit (in my other applications)
I use the WHERE clause sparingly at the moment in a new project where it
helps me avoid creating test SSPs for development. That's all.

>
> IBO needs to be enhanced as I suggested earlier for this to work in a
> totally efficient manner. It is on my list of things to do. Perhaps you
> can twist my arm a little if you provide for me a good working model to
> operate with when designing this.

I have no need for a design change - only to track this error.

>
> You will need at least two stored procedures. One for the whole
> dataset and
> another with additional columns parameters for keylinks columns that will
> return an individual record.

That's possible but since I have the ID in question returning in the SSP. I
could just as easily datasource it and have a new query return features I
want from the source table.

>
> It may also be possible to use a single procedure as well, you would just
> have the keylinks columns as parameters and when you want your
> whole dataset
> put NULL in them and take that to mean a whole dataset request,
> however, if
> there are values in those parameters then take it as a single
> record request
> and then inside your stored procedure you can handle each case
> efficiently.
>
> I hope this helps clarify where the root issues of efficiency, and IBO's
> current deficiency in addressing this is at.
>
>
> Jason Wharton

Alan