Subject | RE: [IBO] XSQLDA bug |
---|---|
Author | Helen Borrie |
Post date | 2003-10-23T07:48:21Z |
At 04:59 PM 23/10/2003 +1000, you wrote:
process so, when you need help for a wrapper property, you need to read the
help for the wrapper (in this case TIB_Statement).
Here it is, anyway:
If a stored procedure does not perform any DML operations then it is
posssible to make it so that executing it will not activate the transaction.
Which isn't very clear, is it? What it might mean is that, if you are
using a StoredProc component to get a dataset, and this particular stored
proc executes some DML besides generating the dataset, then the DML won't
be executed. But that's only a guess.
If you have such a stored proc in your database, I strongly advise
splitting it up into two procedures - one that does the DML (an Executable
procedure) and one that gets a dataset (a Selectable procedure). These
dual-purpose SPs are terrible, because the DML stays uncommitted until you
commit the transaction. The rows the client is looking at will include
the uncommitted values. It's one of those cases where "Just because you
can, doesn't mean you should".
Helen
>OK. I've managed to prevent the sqlda bug from appearing by settingYup, there's help for the property. The IBO help file is built by an OO
>StoredProcHasDML property of the TIBOStoredProc to False. I'm a little
>worried what side-effect this may have as the stored procedure does have
>dml in it. Unfortunately there is no help on this property at the moment
>so I was wondering if anyone could explain exactly what this property does?
process so, when you need help for a wrapper property, you need to read the
help for the wrapper (in this case TIB_Statement).
Here it is, anyway:
If a stored procedure does not perform any DML operations then it is
posssible to make it so that executing it will not activate the transaction.
Which isn't very clear, is it? What it might mean is that, if you are
using a StoredProc component to get a dataset, and this particular stored
proc executes some DML besides generating the dataset, then the DML won't
be executed. But that's only a guess.
If you have such a stored proc in your database, I strongly advise
splitting it up into two procedures - one that does the DML (an Executable
procedure) and one that gets a dataset (a Selectable procedure). These
dual-purpose SPs are terrible, because the DML stays uncommitted until you
commit the transaction. The rows the client is looking at will include
the uncommitted values. It's one of those cases where "Just because you
can, doesn't mean you should".
Helen