The previous post was getting burried, so here it is again:

Cameron,

The function that is failing with that error message is the TRANSACT function.

Here's the code I just used for testing:

compile subroutine temp(void)

declare function transact

Stat=2

SQLState="

result=Transact( Stat , SQLState)

return

The "ENG0010: temp line 5. Variable has not been assigned a value" error message comes up as soon as I execute the "result=Transact(Stat , SQLState)" line.

The curious thing is that the first time I execute the procedure (from the EXEC line as "run temp") , both result and SQLState are set to 0 when the error message comes up.

From the second time on, the result variable is still set to 0 but SQLState is set to 1003.

Now aside from that, as soon as I acknowledge the ENG0010 error message, I cannot continue stepping through the rest of the code, but rather have to close the debugger. (This is probably normal, but I figured I'd mention it anyway.)

Now would you be so kind and tell me :

1. is this piece of code doing the same thing on your system?

2. what is it that I'm doing wrong?

I'm seriously considering writing my own TRANSACT function that will write records to a temp file and commit them from there or delete them on Rollback. It would not be as elegant as using the existing Transact function though, so that' s why I want to make this work.

Please let me know ASAP what you think is happening here because I need to deliver the code that includes this by Thursday.

Thanks

P.S. I ran this on OI 3.5 pre-release 3 on both Win95 and Win NT 4.0 workstation. Both on standalone and network. With the same results.

Hi Dave

We started using the OI Transaction Control some years ago and had considerable success with it, despite the fact that it seems to be an "unsupported" area of OI. We were forced to de-activate it due only to the fact the some users are on Citrix Winframe, and the Station ID being returned to the system was the same for all these users - causing fatal errors in the Commit process. There is one significant weakness in that if a number of transactions are queued for the commit process, and a workstation goes down, then the queue halts and you need manual intervention to get the thing started again. For this purpose we developed a form that looked at the REVCOMMITLOG table and allowed superusers to abandon selected transactions in the queue.

All this doesn't help your immediate problem, and I must confess I haven't really looked at it in detail, but if you need assistance or some test code, then give me a shout. I was always really surprised that no-one seemed to use Transaction Control in OI (or no-one ever responded to my requests in this forum, anyhow).

nick@wsa.co.za

View this thread on the forum...