8 replies to this topic

[Mike Schoen]

We are porting our application to mssql, and have found another fine feature.

I found this while trying to find a way to force a rollback in mssql, which is something we use in oracle.

Update function
reads mssql file DC1REC, which has 1 record in it.
reads mssql file 2 ROLLBACK, with the following SQL statement in before read
SELECT INVALID_COLUMN_NAME FROM DC1REC
reads mssql file 3 ARCF (customer file) before read set the key, and read no error umsg(ARCF_NAME)

The first time the function runs, I get the SQL error message, then get to the @RFUNCT rollback screen.
I F3 out of this, then run the function again.
I get the SQL error message, then my umsg with the customer's name

Has anyone else experienced this? Is there some sort of flag or something we need to reset when a rollback occurrs, or an environment setting that will make pro-iv treat ALL rollbacks as rollbacks?

[Lewis Mccabe]

What version are you on?

[Mike Schoen]

Sorry,

This is under 5.5r517 under oracle and linux, and release 5.5r18 under windows and mssql.

I just tested under both platforms, and this happens with both oracle and mssql it turns out.
The function in the attached prx will generate a rollback and go to @RFUNCT the first time it is run only.

I thought that this was an mssql issue only, but now it seems I have to worry about our oracle app also "missing" rollbacks and carrying on to do work it shouldn't.

The main task I am trying to acheive under windows is to be able to call a global function to trigger a rollback so that if a required record ( Ie g/l account or the product we are posting costs for) gets removed by a user, we can rollback the function and also get the error logged by our rollback logging function.

Attached Files

•  sqlbug.prx   6KB   111 downloads

[Joseph Bove]

Mike,

I'm afraid I'm only replying to your question with a question:

Is your rollback logging function only used in rollback situations that you force or every rollback that is encountered by the system?

Regards,

Joseph

[Lewis Mccabe]

We run MSSQL. I will try to reproduce problem. We force rollbacks as well so it will be interesting to find out if this is a bug simply waiting to strike.

[Lewis Mccabe]

We do not have a rollback problem with MSSQL. I checked our use of ROLLBACK and found the following: Since PRO-IV uses dirty reads in Lookup mode, we write our session locks against database and then do a ROLLBACK to release them. This is done in a heavily used function. If there were a problem with ROLLBACK this would have been reported as a problem by our customers. We are on kernel 5.1.8 and client 5.6.7.0. Have you been able to reproduce this in a simple function to narrow it down specifically to ROLLBACK?

[Lewis Mccabe]

We are on MSSQL 2000 ver 8.00.760 SP3

[Mike Schoen]

Lewis,

My problem is not with the ROLLBACK() logic statement, but with database-side rollbacks.

If a function gets a rollback due to a database error, say a reference to a bad column name, or a bad SQL/ENDSQL statement. In those cases, the first rollback is trapped by pro-iv, but subseqent ones are ignored. I was able to write a simple test function that would trigger a rollback the first time, and then proceed to happily complete transactions with data modifications despite rollbacks.

After having had a few customers with database errors due to space and disk problems, the thought of a pro-iv installation that can potentially ignore rollbacks and keep processing worries me a great deal.

Mike

[Wim Soutendijk]

So far I have seen the same with SQL Server.
During development time, if we make a mistake in the SQL statement, or in the alternate variable names, we only get a SQL error and @RFUNCT screen the first time.
We have to fix the problem, log off, and retest the function. If we don't log off after an error, we won't know if the problem was fixed or not.
Not a problem on our production server, as by the time we set our software live, these kind of problems won't be in the code anymore