PC SOFT

PROFESSIONAL NEWSGROUPS
WINDEV, WEBDEV and WINDEV Mobile

Home | Recent messages | Connect |  | English US
Home → WINDEV 2024 → [WD21] Unable to cancel transaction
[WD21] Unable to cancel transaction
Started by DarrenF, Sep., 22 2017 4:27 PM - 13 replies
#1
Posted on September, 22 2017 - 4:27 PM
Hi guys,

A customer is getting an "Unable to cancel transaction" error. I introduced the Transaction processing ages ago (over a year), so it's not a common occurrence; 1st time it's happened in fact. Looks like something out of the ordinary has happened.

I've not got any feedback from the customer as of yet; I'll try to find out what was going on at the time of the problem, but in the mean time I presume it's a matter of using WDTRANS to cancel the (outstanding) transaction? ...but are there any other things I should be aware of when fixing this error on the customer's site?

Cheers...
#2
Posted on September, 22 2017 - 5:04 PM
Hi Darren,

is it a HF Classic or a C/S database?

Steven Sitas
#3
Posted on September, 22 2017 - 5:13 PM
Hi Steven,

It's Classic.
#4
Posted on September, 22 2017 - 5:43 PM
You probably know this already but don't forget to do a backup (including the transaction file) before using WDTRANS.
You may have a corrupt transaction file - probably because the computer abnormally shut down and the user hasn't turned off the cache of the hard disk.

good luck

Regards
Steven Sitas
#5
Posted on September, 22 2017 - 5:56 PM
Thanks for the info.

Do you know if WDTRANS will "force" the cancel even if the transaction file is/maybe corrupt.
#6
Posted on September, 22 2017 - 6:23 PM
If your transaction file is corrupt you may have to use a valid backup.
It all depends on the damage ...
But it could be something simple and everything may work just fine.

Generally, I think it is a lot better to use the C/S engine (since it handles these problems automatically), but a UPS and turning the hard disks cache OFF is always a must.

Regards
Steven Sitas
#7
Posted on September, 22 2017 - 7:10 PM
Darren

As Steven suggests make a backup of the database and the transaction files TRS/TRX

Without the TRS/TRX files there is no rollback.

I had an issue in a single user application that started in v16 and was updated every year and then in v19 or v20 can't remember which I experienced an issue that ended up being that the the expected location of my transaction files changed resulting in the inability to automatically roll back a failed transaction upon app startup. I don't remember the error so it may not be your exact case but I would look to see if your code successfully found your TRS/TRX files.

Eric W
#8
Posted on September, 22 2017 - 8:25 PM
Hi,

Ok, I've found out a bit more info.

The full error is:
WL call: Process of 'Global Procedure CancelClassicTransactions' (Global Procedures of ObjectPos.CancelClassicTransactions), line 38, thread 0 'HTransactionCancel' function, syntax 1 What happened? Unable to cancel transaction. Error code: 140005 Level: fatal error Dump of the error of 'wd210trs.dll' module (21.0.7.0). Debugging information: TRS = C:\ObjectPos\20170921173255592_EPOSSTKMAINT File = \\AMD-PC\OBJECTPOS\EPos_Header.FIC llHNumEnr = 21960 TRS852 IEWDHF=3.307 Module= Version=<21.0.124.5> Fonction (7,141) Additional Information: EIT_PILEWL : Global Procedure CancelClassicTransactions (Global Procedures of ObjectPos.CancelClassicTransactions), line 38 Initializing ObjectPos (), line 249 EIT_DATEHEURE : 22/09/2017 18:04:28 EIT_TYPE_WDFILE : <7> EIT_IDCODE : <458752>
When I start up my application I have some Project Code that attempts to do a tidy-up exercise and cancel transactions - it's this code that's generating the above error.

I've looked at the customer's machine and there's a .TRS file for yesterday at around the time they closed their system down for the day. It was this morning when they experienced the error, so it looks as though a transaction hadn't finished for some reason :confused:

Can I just delete the .TRS file without any bad effects? The customer accepts that he might lose the last transaction; he can just put the EPOS sale through again (hopefully).

As always thanks for any advice :cheers:
#9
Posted on September, 22 2017 - 8:51 PM
Generally, you can delete it but:
1. make sure you reindex your files
2. use WDTrans to free any locked records

Regards
Steven Sitas
#10
Posted on September, 22 2017 - 9:00 PM
Darren

This is my take of it and I haven't had to clean up many of these so someone else may correct me.

When a transaction is initiated the records involved are marked in the file and the changes are carried out in a log file prior to committing them. The TRS is the files involved and the TRX are the data records.

You want to cancel (rollback) the transaction via WDTRANS with your TRS/TRX files this is the cleanest.

IF you were to delete the TRS/TRX files you would still have to deal with the file records marked in your original files.

You can test this with WDMAP just browse a copy of the affected file and when you hit the record it will fail to display the record - as your code would.

I believe without the Transaction files you can "FREE" these records with WDTRANS which allows you to access them normally, but only you know the structure of your data and the contents of a particular transaction so the significance of canceling or freeing records involved is hard for me to judge.
#11
Posted on September, 23 2017 - 1:41 PM
Ok, thanks guys, I'd forgotten the actual records are also "marked".

When running WDTrans I'm getting the red crosses on the window controls, you know the ones - when something isn't quite right with a style sheet? It probably won't affect the running of WDTrans but any ideas how to get WDTrans looking nice; especially if I end up having to present it to an end customer?

Also, after looking at the help page for WDTrans (https://help.windev.com/en-US/…), the list of dll's wasn't quite correct; it wouldn't run correctly without the addition of "wd210mat.dll".
#12
Posted on September, 28 2017 - 3:35 PM
Hi guys,

Just an update to this issue...

I used WDTrans on the customer site. Attempting to Cancel the transaction gave exactly the same error... which I kind of expected. So I had to opt for the clear marked records option on the affected files (4 of them). When I tested the application it failed with duplicate ID's - not expected! After re-indexing the 4 affected files everything is now up and running.

Still have no idea what caused this issue. Customer says there was no power cut and the terminals weren't being worked on at the time of their evening shutdown, so I'm officially at a loss as to the cause. This is pretty worrying as I like to know what causes these types of things.

One interesting observation was that I noticed that there was a set of Transaction index files left behind from (I suspect) a previous "bad happening" and no TRS file - not sure why these index files are still there :confused:

Anyhow, all seems to be running ok now - thanks to all for getting involved and giving advice - much appreciated!
#13
Posted on September, 28 2017 - 7:07 PM
Hi Darren,
glad to know that everything is fine now ...
Now about what can cause these things:

1. Power failure or abnormal shutdown of a PC is number 1 on the list.
Doesn't matter what customers/users say - NEVER trust users !!!

2. Could be a NIC or the Ethernet cable etc.
If it this one, you will see it again soon.
Only solution here is to use the C/S HFSQL engine

3. The Server where you have your HF data may have had a "temporary blackout".
Due to a system update or antivirus etc ..
Again only solution here is to use the C/S HFSQL engine

4. A problem with your code, that shows up very rarely...
Always do extensive error checking inside your transactions

As a general rule, the C/S engine gives BETTER AUTOMATIC recovery options under all these circumstances and it is easy to go from HF Classic to C/S.


Steven Sitas
www.alpha360.biz
#14
Posted on September, 29 2017 - 12:28 PM
Hi Steven,

I believe them when they say there wasn't a power cut, but I do suspect that they powered down the server when other terminals/PCs on the network were still being used. I've already observed them doing this while I was on site and (erm) advised them of the error of their ways!

I've already developed a (kind of) WDTrans of my own. It's currently only available as a menu option at the moment which turned out to be useless in this scenario because I also have some Project Code that checks for Transaction files and attempts to Cancel them, but this means if the Transaction file is corrupt (as it was in my case), then my application (quite rightly), won't start! ...and then I have to get involved to manually fix the problem(s).

Because of the "red-x's" problem with the WDTrans utility's window (which made it really difficult to use), I'm now thinking of ways to extend the processing of my own "home-grown" Transaction management window to allow (not only) the Cancel Transaction mode but also add some processing to un-flag records then re-index files. If I add a call to this "home-grown" Transaction processing dialog to my Project Code, then hopefully this will avert or at least make it easier to "tidy-up" the situation should it happen again. Obviously I'll either password protect the window or write a log each time it's run so I know when and how often it's being used?
→ Go back to WINDEV 2024