Loosing Captured data

[mchibvongodze]

I have users who are capturing data into the database, and at some point they are running reports which show the captured data. But we reliased after 3 days that the data captured was not there. I am confused what might have happened, there was no restore of the database and not everything was lost, but things captured by one user, only on a particular date. I am running Progress Ver. 9.1d on windows.

 

[jdpjamesp]

How are they capturing the data? Is it manual entry? Is it possible that the transaction scoping of the program is badly off and that something went wrong completely backing out the information the user entered? If it's just the information entered by one user it's going to be something that user did or experienced differently to the other users.

 

[mchibvongodze]

The capturing of data is manualy, I also thought that it could be transaction scoping. So ewnt and switched this user's machine while he was capturing and at one point disconnected him from the network by pulling the network cable, but this time it did not lose the data he was capturing. How do I test transaction scoping?

 

[RealHeavyDude]

For 1 you could use the LISTING option in the COMPILE statement which will produce a listing which shows the buffer and transaction scopes for each procedure you compile.

For 2 there is also the TRANSACTION function which you can use to do something like IF TRANSACTION THEN ...


HTH, RealHeavyDude.

 

[tamhas]

Back in the old days of the Varnet application, there was a facility using applhelp.p in which a user could press a function key and leap from the middle of one program over to another. Unfortunately, since pretty much all of the CRUD functions in that software were structured of updates to a DB buffer, when one did that, one was always in the middle of a transaction. Depending on setup, this meant that users could leap out to the menu system, do a bunch of work, print the results of that work, and then finally hit F4 and find themselves back in the middle of the function they left from. If they forgot why they were there, it was natural to F4 again, undoing the open transaction ... and ALL of the work that had been done in between. You might have something similar in which normal processing is not a problem, but a special execution path is resulting in a long open transaction.

 

[Osborne]

Mchibvongodze, did you ever discover the reason for the data going missing? The weird thing is we have started to have the exact same problem in that data entered is available then a few days later discover it is no longer there. This happens very rarely, only on certain records, no database restore nor deletion of the records has taken place but for some reason the data is no-longer there. Also like you are on Windows (XP) and Progress 9.1D - tried and tried to get them to upgrade but no joy. The transaction scoping looks okay and there just does not seem to be anything there that could cause this and wondered if you had uncovered the problem.

 

[RealHeavyDude]

The symptoms you describe tend to make me think of a Progress classic: Transaction scope being much bigger than it needs to be and therefore, in undoing something else - maybe just the print of a report raising an error with the transaction scope, the whole transaction is undone.

Something like: "My invoice report failed to print and the whole invoice is missing in the database. What's going on?"

Although 9.1d is more than 10 years old software, retired by Progress and known to be buggy - I've never heard of such a bug in the software.

Heavy Regards, RealHeavyDude.