Subject | RE: [IBO] Invalid Transaction Handle |
---|---|
Author | Helen Borrie (TeamIBO) |
Post date | 2002-08-08T09:23:04Z |
Gerhardus,
Basically, the situation you describe seems to indicate that you are not
addressing the transaction context of the task at all...and probably not
handling exceptions too well at this point, because of your confusion about
the transactions.
Yes, it's possible to "mix-and-match" and hybridise TIB_* and TIBO*
components (but not controls) but this mix you are using isn't called
for. TIBODatabase has all the stuff you need when your application design
doesn't care about isolating tasks in their own transactions. It looks
after all the layers in between that your app is ignoring...
Without further ado, would you please try this:
Remove the IB_Transaction and IB_Connection objects and replace them with a
TIBODataset. Set all of the properties according to those you gave to the
old connection and transaction objects....then set its Databasename
property to something easy (like MyDB)...and don't forget you need to
supply run-time code to open the connection.
Next thing: I don't think TIBOStoredProc can handle a SELECT procedure
(unless Jason's help text is out of date).
Replace the TIBOStoredProc with a TIBOQuery having the SQL property
select * from FILTER_DIARY (:IN_DATE, :IN_USER)
Set its IB_Connection and IB_Transaction properties in a single hit by
setting the query's Databasename property to the name you gave to the
TIBODatabase. You should then see that the query's IB_Connection property
is IBODatabase1 and its IB_Transaction property is <default>. Don't change
these.
On the event where you want to run the SP, check the InTransaction property
of the IBODatabase, just as demonstrated before, check for Prepared and
Prepare if you need to, then assign the params. Call Open and everything
should go like clockwork...
I have to say I don't see why you need a stored proc to get this dataset,
all the same. It's just grabbing a set of rows and pushing them out as an
arms-length dataset. If you used a regular parameterised query just like
the one inside the SP, you would get the same data and it would be directly
live through the KeyLinks...you lose much when your output set isn't
table-based. Keep select SPs for those really curly output sets that need
columns you can't acquire through regular SQL.
regards,
Helen Borrie (TeamIBO Support)
** Please don't email your support questions privately **
Ask on the list and everyone benefits
Don't forget the IB Objects online FAQ - link from any page at
www.ibobjects.com
Basically, the situation you describe seems to indicate that you are not
addressing the transaction context of the task at all...and probably not
handling exceptions too well at this point, because of your confusion about
the transactions.
Yes, it's possible to "mix-and-match" and hybridise TIB_* and TIBO*
components (but not controls) but this mix you are using isn't called
for. TIBODatabase has all the stuff you need when your application design
doesn't care about isolating tasks in their own transactions. It looks
after all the layers in between that your app is ignoring...
Without further ado, would you please try this:
Remove the IB_Transaction and IB_Connection objects and replace them with a
TIBODataset. Set all of the properties according to those you gave to the
old connection and transaction objects....then set its Databasename
property to something easy (like MyDB)...and don't forget you need to
supply run-time code to open the connection.
Next thing: I don't think TIBOStoredProc can handle a SELECT procedure
(unless Jason's help text is out of date).
Replace the TIBOStoredProc with a TIBOQuery having the SQL property
select * from FILTER_DIARY (:IN_DATE, :IN_USER)
Set its IB_Connection and IB_Transaction properties in a single hit by
setting the query's Databasename property to the name you gave to the
TIBODatabase. You should then see that the query's IB_Connection property
is IBODatabase1 and its IB_Transaction property is <default>. Don't change
these.
On the event where you want to run the SP, check the InTransaction property
of the IBODatabase, just as demonstrated before, check for Prepared and
Prepare if you need to, then assign the params. Call Open and everything
should go like clockwork...
I have to say I don't see why you need a stored proc to get this dataset,
all the same. It's just grabbing a set of rows and pushing them out as an
arms-length dataset. If you used a regular parameterised query just like
the one inside the SP, you would get the same data and it would be directly
live through the KeyLinks...you lose much when your output set isn't
table-based. Keep select SPs for those really curly output sets that need
columns you can't acquire through regular SQL.
regards,
Helen Borrie (TeamIBO Support)
** Please don't email your support questions privately **
Ask on the list and everyone benefits
Don't forget the IB Objects online FAQ - link from any page at
www.ibobjects.com