Hello Gediminas,

> suppose, SP query is: select * from SP_Select_Name( :Name_ID )
>
> pCursor->Prepare;
> /* Eof=false, Bof=true */
> pCursor->First;
> /* no data until pass Name_ID parameter, Eof=false; Bof=false */
> pCursor->ParamByName( "Name_ID )->AsInt = 20;
> /* has data for Name_ID=20, can work with it, Eof=false; Bof=false */

That's the wrong order. After preparing, you should *first* assign any
params, en *after that* call First.

If you want to know if the set is empty or not, you can use the
generic procedure I posted earlier in this thread. But it doesn't make
sense to call it before you assign the parameter. So the order should
be:

1. Prepare if necessary
2. Assign parameter
3. Call CanEdit( pCursor )
4. If that returns true, work with the set

Everytime you change the param you get another set, so you must call
CanEdit() again if you need to know whether it's empty.

But...

You said you wanted a generic procedure that works for buffered and
non-buffered datasets. OK, it's no problem writing such a procedure.
But using it only makes sense if you don't know (at the time you call
the procedure) what kind of dataset you are working with. However, in
the example above you are explicitly working with a cursor. Why not do
this then:

pCursor->Prepare();
pCursor->ParamByName( "Name_ID" )->AsInteger = 20;
pCursor->First();
if ( ! pCursor->Eof ) // if Eof true, the set is empty
{
...do whatever you want to do...
}

And everytime you change the param, *again* call First() and
check Eof.


Greetings
Paul Vinkenoog