I think that the thread name is not directly available to the Database Inbound protocol context. There are no ‘variables’ that can be placed in the SQL that will be valued with any context information.
Only information returned from the query will be placed in messages created by the inbound protocol. In the inbound tcl / UPOC you may be able to determine the context / thread name. But I think you wanted the thread name so you could update something in Oracle?
Also, the count of rows returned is not made available to the read success or read failure actions. However this can be achieved by using a stored procedure instead of a raw SQL query in the primary inbound query:
– use a stored procedure
– have the stored procedure keep a count of the rows returned
– have the stored procedure return both a set of rows (application data) and a numeric return code which is the count of rows. If you need return code to indicate success or failure, then perhaps you can use a negative number to indicate failure.
This is just one option. Another would be to put logic in the stored procedure to track which rows have been retrieved by adding a new column used to hold a unique transaction ID. The stored procedure would generate a new txnid for each execution and update that column with the txnid. The Post-Read action would not have access to this value, but other database processes would have access to it, so possibly this will be useful.
Another option is to use a view instead of a table. There would be many views of the same data, but each view would be associated with the thread. I think the stored procedure would have access to the current view name and therefore could determine the thread name.
I hope this helps.
Peter Heggie
PeterHeggie@crouse.org
.
