> > > >Then, do I call Open() or Execute()? Which is correct in this case?
> > >
> > >Call Open on an IB_Query. Call First on an IB_Cursor. Call Execute on an
> > >executable (that has the EXECUTE PROCEDURE(...) syntax).
> >
> >What about an IB_Cursor using the EXECUTE PROCEDURE syntax?
>
>Same.

Same as which? If I'm using an IB_Cursor with the EXECUTE PROCEDURE
syntax, and I need just that one return value, and am not displaying the
value in a control, would I use Execute(), or First()? Or does it matter?

>If this is your design approach and you potentially have "stub" SQL

What is "stub" SQL?

>But it sounds as if you
>might be talking about recycling the same data object for calling different
>SPs.

Yes, I plan on recycling a generic TIB_Cursor to call different SP's.

>As I indicated before, it all depends on which particular requirement
>you need to implement. Mostly, I want to discourage you from getting into
>the mindset that there is only one "best way" to manage all SPs in your
>app. Consider them all and work with any and all of them, case by case, to
>get the best possible performance value.
>
>Gotta stop now.

Thanks for all you help, Helen.

I've been very reluctant to use SP's up until this point, since I consider
them to be less flexible than changing my C++ code if a bug is found
later. I try to limit my metadata changes as much as possible, but my app
changes often. But it's come to the point where I need both the
performance increase and the added functionality. I was very relieved to
find that I was able to learn about them very easily by reading the IB 6.0
documentation. I was able to learn all about them and write two somewhat
complex SP's in one evening. Unfortunately, I didn't find as much
documentation about how to use them with IBO, so I started with
TIB_StoredProc. Thanks for pointing me in the right direction.

-Joe