thanks to everyone for their comments!

I presume Jason is saying that he will add the capability of IBO recognizing
primary key return values if so coded. that's slick and would be useful.
thanks jason! We'll definitely check it out when its ready.

re: select stored procedures, in some cases we are likely to have to log
selects. Furthermore, we do use Asta and will also be building some web
apps both of which use connection pooling. So I haven't really seen a way
around using SP for selects. yes we are generating key values in the SP.
I guess we will have to take geoff's suggestion and prefetch the primary
key.....

re: interactive queries we'vbe been using SQL like this that works: SELECT
* FROM my_procedure WHERE myField=1 and it seems to work just fine. I have
not yet verified that the result set limits are applied on the server then
sent versus applied on the client but I'm guessing its done on the server,
so I am not sure why the interactive query stuff won't work. Obviously its
something we haven't been using yet.

thanks.

rob

----- Original Message -----
From: "Jason Wharton" <jwharton@...>
To: <IBObjects@yahoogroups.com>
Sent: Tuesday, April 02, 2002 5:10 PM
Subject: Re: [IBO] Using Stored procedures exclusively


> Rob,
>
> Not much time, let me say real quick, I like the idea of having a stored
> procedure which returns column values. This would be a nice way to avoid
> having to use the buffersynchroflags re-fetch if upon executing the DML
> stored proc its return values were spliced into the buffer. This could
also
> eliminate the need for GeneratorLinks too and allow triggers to set
things.
> You would just have to make sure it returned the pertinent column values.
>
> I will add this capability as an automatic feature in the next major
version
> of IBO.
>
> Few more comments below.
>
> Regards,
> Jason Wharton
> CPS - Mesa AZ
> http://www.ibobjects.com
>
>
> ----- Original Message -----
> From: "Rob Schuff" <rob@...>
> To: <IBObjects@yahoogroups.com>
> Sent: Tuesday, April 02, 2002 1:50 PM
> Subject: [IBO] Using Stored procedures exclusively
>
>
> > hi folks,
> >
> > I am just now venturing into the world of using stored procedures for
all
> > select, insert, update, and delete (SUID) activities. I'm hoping
someone
> > will give some general advice and be able to answer a couple of
questions.
> > We are using TDataset stufg with TIBOQueries almost exclusively. D5.01
> and
> > IBO v4.2Fn
> >
> > 1. We code the insert update and delete procedures to execute the SP's
in
> > question. This seemed to work well until i thought we should return the
> > newly generated primary key as part of the Insert SP. When we did this
we
> > started getting an error about expecting a message length of 8 and
getting
> > 0. As I am writing this I am thinking that in general it really doesn't
> > make sense to have the stored procedure return the primary key of the
> record
> > it just inserted. Comments here?
> >
> > 2. Do we need to set the keylinks properties still? So far everything
> still
> > seems to work as expected but its very early to tell for sure.
>
> Your inserts won't work if your key values are generated in the proc or
the
> triggers.
>
> > 3. Anybody have a general comments about doing all activities through
SPs
> > and how it changes the way a delphi app is coded? We are doing this to
> set
> > the stage for a developing a solid journaling system.
>
> Using procedures for selecting data makes it so that you cannot use search
> mode and dynamic where clause optimizied queries.
>
> > Any general comments appreciated.
> >
> > many thanks!
> >
> > rob
>
>
>
>
>
___________________________________________________________________________
> IB Objects - direct, complete, custom connectivity to Firebird or
InterBase
> without the need for BDE, ODBC or any other layer.
>
___________________________________________________________________________
> http://www.ibobjects.com - your IBO community resource for Tech Info
papers,
> keyword-searchable FAQ, community code contributions and more !
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>