Subject | Re: [IBO] Using Stored procedures exclusively |
---|---|
Author | David Cornelius |
Post date | 2002-04-03T18:28:13Z |
Jason,
You said below: "Your inserts won't work if your key values are generated in the proc or the triggers." I'm using stored procs for everything--including inserts and the primary keys (auto-inc ints) are generated in a trigger of the table being inserted when the value is null. Everything seems to be working fine. What do you mean by this? Am I heading into a mine field of problems when I try to tackle more advanced issues?
Thanks,
David Cornelius
corneliu@... 503-494-0612
Database Administration & Programming
OHSU General Clinical Research Center http://www.ohsu.edu/gcrc
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
You said below: "Your inserts won't work if your key values are generated in the proc or the triggers." I'm using stored procs for everything--including inserts and the primary keys (auto-inc ints) are generated in a trigger of the table being inserted when the value is null. Everything seems to be working fine. What do you mean by this? Am I heading into a mine field of problems when I try to tackle more advanced issues?
Thanks,
David Cornelius
corneliu@... 503-494-0612
Database Administration & Programming
OHSU General Clinical Research Center http://www.ohsu.edu/gcrc
>>> jwharton@... 04/02/02 05:10PM >>>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/