Thanks!

Sandi.



Sandi,
>SQL-Selects are always done on the data on your server, never on uncommitted data that is inside a transaction or buffered or in a view. To run a report on buffered data or data inside a transaction you'll have to use other techniques, such as creating a blank cursor and filling it with SCAN/ENDSCAN or COPYing data to a temporary table.
>
>HTH
>Barbara
>
>>I have a form that calls a prg as a posting routine. In the prg I use a transaction to wrap around the posting code and ensure that everything in the posting routine works or the associated records rollback. This part works good. I needed a pre-post report which allows the user to see a report of what will happen if they press the post button. This is implemented by calling a report within the transaction and then if the post button wasn't pressed (a parameter in the calling sequence), the system rolls back and nothing is committed. The problem is that the reporting needs an SQL command to gather the data (many to one) and when I run the SQL and watch it I noticed that while the tables used for the SQL contain one set of data, the result of the SQL shows that the SQL was run on a different set of tables, (pre-ones). The datasessions never switch, and both the input tables and resulting cursor are found in the same datasession, it just seems that the SQL drew it's information from a
>>different data session, not the one that appears current. What am I doing wrong, or is there a way to force the SQL to act on the transaction-wrapped data tables?
>>
>>Thanks for your help
>>
>>Sandi Cassidy
>>scassidy@canaccount.com