|
| HtransactionCancel, WD 19 |
| Iniciado por guest, 19,ene. 2015 15:06 - 12 respuestas |
| |
| | | |
|
| |
| Publicado el 19,enero 2015 - 15:06 |
Hi,
I am testing an HF SQL (v19) application, that uses transactions.
As soon as I start the transaction and do a couple of adds, I stop the application (from the debugger/WD). So of course my transaction is now CORRUPTED.
Here is my code for starting the transaction:
HFTransaction() // ->this is HF SQL
/// do adding
IF tr=false
HTransactionCancel()
ELSE
HTransactionEnd()
END
So at the beginning of my code I have code to catch an interrupted transaction:
If HTransactionInterrupted(myconnectin)=true
HTransactionCancel(etc...)
END
The problem is that HTransactionInterrupted is NEVER true, although I have a corrupted transaction. I know it because as soon as I do a query, I get a report for an interrupted transaction from WD19.
I tried to run HTransactionCancel, without checking HTransactionInterrupted and it doesn't cancel the transaction ...
The only way to do it, is go to the Control Center and do it Manually ...
Everything works as expected with HF Classic
Any Ideas? |
| |
| |
| | | |
|
| | |
| |
| Publicado el 20,enero 2015 - 15:48 |
Hi Steven,
It might not be of help, but HTransactionCancel() uses the local users' transaction file. If this file is lost, you can't cancel the transaction. Your only chance in that case is HTransactionFree() which is the "panic" button. At least, this is the only method I know of.
Kind regards,
Alexandre Leclerc |
| |
| |
| | | |
|
| | |
| |
| Publicado el 20,enero 2015 - 16:05 |
Steven
I run the following procedure called from the project initialisation.
Not had any issues during the last 2 years or so + it has the advantage of closing any transactions left lurking about if I exit the app during debugging.
PROCEDURE pCloseTransactions() lsTransactID is string lsTransactItem is string lsTransactList is string lsTransactStatus is string // Retrieve the list of transactions lsTransactList = HTransactionList(:msConnection) IF lsTransactList <> "" THEN //If found then check the current status FOR EACH STRING lsTransactItem OF lsTransactList SEPARATED BY CR lsTransactID = ExtractString(lsTransactItem,1,TAB) lsTransactStatus = ExtractString(lsTransactItem,5,TAB) //Cancel transaction is status = 0 (Interrupted) IF HTransactionInterrupted(lsTransactID) = True THEN HTransactionCancel() END END END |
| |
| |
| | | |
|
| | |
| |
| Publicado el 20,enero 2015 - 17:25 |
Hi DerekT,
Nice little code. I think I'll implement it in the C/S mode of my application. It might be just what I need for the weird cases we had. (Maybe not too, because the transactions where not showing. It was a very weird and bad state we had in those cases.) I might just give it a try.
Best regards,
Alexandre Leclerc |
| |
| |
| | | |
|
| | |
| |
| Publicado el 20,enero 2015 - 20:10 |
Hi Alexandre and Derek,
the code Derek posted, will NOT help in this situation - I have tried it with NO luck.
The user/app/machine that started these transactions, terminated abnormaly.
I use EndProgram to emulate this situation by code ...
The problem is that V19 of HF SQL, thinks that everything is OK with these transactions, and does NOT recognise them as Interrupted. It doesn't "know" that the application that started them is NO longer running. V19 thinks everything is FINE, just a LONG transaction on the server ....
Previously HF SQL v17, "somehow" recognised when an app/user etc terminated abnormaly and it tooked care of the transactions automatically.
Now as I said you have to STOP and Restart HFSQL ....
Please note that according to PCSofts documentation this is not normal |
| |
| |
| | | |
|
| | |
| |
| Publicado el 20,enero 2015 - 20:15 |
Hi Steven,
Have you tried HTransactionFree()? It did the thing all the time for me, in the same exact context: transactions were not even listed, no visible problems, but the files were blocked in transaction. In this case, looping through all the file and calling HTransactionFree() for each of them has solved the problem. No more HFSQL reboot, etc.
Best regards,
Alexandre Leclerc |
| |
| |
| | | |
|
| | |
| |
| Publicado el 20,enero 2015 - 20:50 |
Hi Alexandre,
I haven't used HTransactionFree in my code, but I did use it from the HFSQL CC.
Double Clicked a file ->Transactions->Free the transactions.
According to the docs this is the same as using HTransactionFree in code ...
In C/S HF SQL it was a DISASTER - I got data modified on HALF POSTED transactions.
According to docs (?) this is just our last chance to get things running - but since it ignores transactions it doesn't look like a good idea !!!!
Steven Sitas |
| |
| |
| | | |
|
| | |
| |
| Publicado el 20,enero 2015 - 21:16 |
Hi Steven,
Indeed, this will convert all "in transaction" records as normal records. So yes, this is the "panic button" solution because it leaves your DB in a half-posted state.
But if you absolutely need a solution to unlock a customer which fell in that situation, this is your only solution. (Easier and faster than going through HFSQL Control Center and unlock all the files, especially if they are password protected.)
I agree with you, this is not the best solution, but it can be very useful.
Now, if you are able to replicate the case every time, send the a demo application to PCSoft with the how-to to make it do so and ask them for a clean solution to fix the transaction problem. You would be the first one I know that can reproduce the problem efficiently and it would help a lot. I do have the same similar problem in one customer installation. But it happens only one in a while.
Best regards,
Alexandre Leclerc |
| |
| |
| | | |
|
| | |
| |
| Publicado el 21,enero 2015 - 20:33 |
Hi Alexandre,
I have finally made a very SIMPLE WD application - with 1 file and 10 lines of code - that ALWAYS shows the problem !!!!
It took me a couple of days to figure things ...
The "secret" is the complexity of the table and the mix of fields.
With the same code and simple tables, I cannot "reproduce" the problem.
But with the table/file I just sent to PCSoft (and the complete project) they can hopefully find the problem and give us a solution.
But along the way I found a lot of bugs in the Control Center (of C/S HFSQL).
Specially for international users ...
I will do a more detailed post, as soon as I get some info from PCSoft support.
Now back to work .....
Steven Sitas |
| |
| |
| | | |
|
| | |
| |
| Publicado el 21,enero 2015 - 21:59 |
Hi Steven,
Now this is great news! I wish for you that they can reproduce and find the source of the problem. I'll subscribe to this post for any updates.
Best regards,
Alexandre Leclerc |
| |
| |
| | | |
|
| | |
| |
| Publicado el 22,enero 2015 - 18:18 |
Hi Alexandre,
just got an email from PCSoft that they can now reproduce the problem.
Incident reference #90 886/258632 - forwarded to their developers ...
Hopefully we will have a solution soon
Steven Sitas |
| |
| |
| | | |
|
| | |
| |
| Publicado el 22,enero 2015 - 20:39 |
Hi Steven,
Thank is good new. I'll ask to be informed about that ref. Thank you very much. :spos:
Alexandre Leclerc |
| |
| |
| | | |
|
| | |
| |
| Publicado el 22,enero 2015 - 23:05 |
Hi Steven,
keep us informed please.
It's a major bug and I hope they fix that in WX20. |
| |
| |
| | | |
|
| | | | |
| | |
|