|
| HExecuteQuery and Transactions |
| Iniciado por guest, 14,ene. 2016 11:31 - 9 respuestas |
| |
| | | |
|
| |
| Publicado el 14,enero 2016 - 11:31 |
Hello,
In a WD 19 application I have a LONG running transaction.
When I do a HExecuteQuery(query) on a query that has data modified by the transaction, I get a fatal error.
Is this NORMAL behaviour ?
I would think that the query would go on, using the data prior to the transaction.
I know that I should NOT use LONG LONG running transactions, but this is done just to emulate a heavy user environment ....
Steven Sitas |
| |
| |
| | | |
|
| | |
| |
| Publicado el 14,enero 2016 - 14:16 |
Hi Steven,
Have you added the "hWithTransaction" constant when calling HExecuteQuery()?
Kind regards,
Alexandre Leclerc |
| |
| |
| | | |
|
| | |
| |
| Publicado el 14,enero 2016 - 14:34 |
Hi Alexandre,
I tried "hWithTransaction" but NO luck.
I am going to setup WD20 and HFSQL 20 and see if this is just a v19 problem.
They fixed some problems in this area with WD20, but what is really bothering me is, that nobody else has reported it ....
Steven Sitas |
| |
| |
| | | |
|
| | |
| |
| Publicado el 14,enero 2016 - 15:08 |
Hi Steven,
There is a hole in my experimental knowledge here. But 3 questions:
1. Is it possible that HTransaction...() not be compatible with the execution of queries?
2. What is your query doing?
3. Are you in HFSQL Classic or C/S mode?
From what the documentation says is that HExecuteQuery() with the hWithTransaction is creating a transaction for the query itself. It does not speak about using a query in a HTransaction.
Also, I've seen this page: http://doc.windev.com/en-US/…
In the "Differences of behavior between the ISAM and Client/Server transactions" section it shoes what is the effect of calling HExecuteQuery within a transaction.
Hopefully this will be of help to you.
Best regards,
Alexandre Leclerc |
| |
| |
| | | |
|
| | |
| |
| Publicado el 14,enero 2016 - 15:32 |
Hi Alexandre,
This section talks about INSERT/UPDATE queries.
My queries are just simple queries on C/S.
The same problem is with Classic HFSQL also ....
Steven Sitas |
| |
| |
| | | |
|
| | |
| |
| Publicado el 14,enero 2016 - 15:51 |
Hi Steven,
Maybe the "transaction isolation level" doc might help you, since that has been modified in V19: http://doc.windev.com/en-US/…
Usually while in transaction you are still able to make a query to the same file. But maybe it requires a different HFSQL context? (I do not know exactly what is your test are what you try to do. I'm sorry.)
Now you say that you do "HExecuteQuery(query) on a query that has data modified by the transaction". There are two queries? One is a query that uses a transaction with modifications?
Best regards,
Alexandre Leclerc |
| |
| |
| | | |
|
| | |
| |
| Publicado el 14,enero 2016 - 16:40 |
Alexandre,
here is a simple situation that shows the problem
(1). Only 1 file, say an Inventory file.
I loop through the inventory file and increase the prices by 10%
I have the loop and all the code in a TRANSACTION
In the loop (and in the transaction) I use Info("something") after say 100 updates, so Its like temporary pausing the TRANSACTION.
Just to simulate a HEAVY user environment.
(2) from another instance of the application, I try to do a simple select query on this file.
Boom - I get a fatal error saying that a record of the Inventory file is in a transaction !!!!
I think the query (which is a simple select query) should have NO problem in this situation ...
Steven Sitas |
| |
| |
| | | |
|
| | |
| |
| Publicado el 14,enero 2016 - 19:23 |
Hi,
After doing some tests, it seems like WD20 doesn't have this problem anymore !!!
Also - although my testing here is limited - it seems like even a v19 Windev application does not have this problem, when used with C/S HFSQL v20 !!!
Another PLUS for C/S HFSQL v20 - even with a v19 application - is that it can catch interrupted transactions from a client computer when the PC/or App stopped abnormaly.
Under certain HEAVY conditions, this was a problem with v18 and v19 (but NOT with v17) C/S HFSQL.
Hope this info helps somebody else.
Steven Sitas |
| |
| |
| | | |
|
| | |
| |
| Publicado el 15,enero 2016 - 09:11 |
Hi Steven,
Personally I doubt if it is a good idea to loop trough your article file in a transaction.
If you have a huge article file, then more and more articles will be 'locked in transaction' during the whole process. And because you are doing all these things in a transaction, it will even take more time. Transactions should be kept as short as possible.
Maybe you should consider not using transactions and for instance using an extra field in your article file that holds a time-stamp of the latest inventory...
That's what i think...
Kind regards,
Joris. |
| |
| |
| | | |
|
| | |
| |
| Publicado el 15,enero 2016 - 11:13 |
Hi Joris,
You are right, transactions should be as short as possible ...
The code (looping through an inventory file in a transaction) is just an EXPERIMENT.
With it I try to EMULATE a HEAVY enviroment - with 1000s of users ....
If I hadn't done the above, I would never have found the problem in the first place !!!!
Steven Sitas |
| |
| |
| | | |
|
| | | | |
| | |
|