On 5/3/2019 12:00 PM, Fernando Dias wrote:
> I have just recreated here your example and what I see is "ElevateDB
> Error #1005 Cannot lock the row in the table OP" when the *first* SQL
> statement is executed. The other SQL statements are never executed
> because it stops at the first one because of the lock error.
> This is exactly what is supposed to happen - I don't understand your point.

Same here - i'm getting same results.


> The trigger has no effect whatsoever in this example.

Agreed but trigger does work in general - it overwrites the new value
with the current value resulting in status column not changing after update.

Raul

On 5/5/2019 8:24 PM, Raul wrote:
> Agreed but trigger does work in general - it overwrites the new value
> with the current value resulting in status column not changing after
> update.

Never mind - read it as "newrow.status=oldrow.status" instead of what it is

Raul

Terry Swiers wrote:

<< Can you provide some more details on the server and session settings so that we can duplicate your environment as closely as possible:


Good morning Terry,

here's my Server-Ini-File:

[Server]
Configuration In Memory=0
Configuration Folder=C:\Program Files (x86)\MicrotronX\mxDatabaseServer\MXDBConfig
Standard NULL Behavior=1
Show Database Catalog Information=1
Buffered File IO=1
Buffered File IO Flush Check Interval=60
Maximum Log File Size=16777216
Log Information Events=1
Log Warning Events=1
Log Error Events=1
Server Run Jobs=1
Server Job Category=
Server Address=
Server Port=12010
Server Thread Cache Size=10
Server Encrypted Only=0
Server Session Timeout=180
Server Dead Session Interval=30
Server Dead Session Expiration=300
Server Maximum Dead Sessions=64
Server Authorized Addresses=*<#CR#><#LF#>
Server Blocked Addresses=
Trace=0
Current Folder=
Trace File Name=
Max Trace File Size=134217728
Auto-Increment Trace File Name=0
Max Auto-Increment Trace File Name=64
Temporary Tables Folder=C:\Program Files (x86)\MicrotronX\mxDatabaseServer\MXDBConfig\TempTables\
Buffered File IO Settings=*,64,32,180,0<#CR#><#LF#>*\op*.*,64,128,120,0<#CR#><#LF#>*\datei*.*,128,128,300,0<#CR#><#LF#>*\pos*.*,128,128,300,0<#CR#><#LF#>*\position*.*,128,512,300,0<#CR#><#LF#>*\dispo*.*,64,128,300,0<#CR#><#LF#>*\adressen.*,128,256,300,0<#CR#><#LF#>*\kd*.*,64,128,300,0<#CR#><#LF#>


ALL: This test with Triggers etc. has nothing to do with data. I Know, the Trigger does not change anything is is only there doing a fieldvalue=fieldvalue so we have a trigger because the customer who had issues has some triggers so i wanted to know if it has something to do with the trigger + lock etc.

We have added the all database directories to exlusion list of antivirus software + backup is doing his job in the night (acronis), so access to the files should be not blocked by any other software.

What i see is, if i get the server one time into a hanging issue, a lot of other things are hanging. So the reproduce steps are not 100%. Today in the afternoon i will have more time to check this on a new VM to see if i can get a 100% clear reproducable steps ...

... and sorry for confusion with the trigger.
Yusuf Zorlu
MicrotronX

and Cache Modules is activated
Yusuf Zorlu
MicrotronX

Yusuf,

This sounds very much like the scenario that you already sent me where you were trying to update a non-existent row in a query with a WHERE clause that applied to a row that was already edited and resulted in a fly-away row (the result set was a constrained, sensitive result set).  The row ID checks that I added a while ago will catch this scenario and prevent any further issues.

I did have a customer report an issue with the *session-level* buffering last week, and I'll be issuing a new build shortly that corrects it.  However, the issue *only* occurred when the table was opened exclusively and updated in a certain way, and it wouldn't account for the "#300 Cannot lock table for write access" error.  When a table is opened exclusively, EDB buffers the table more aggressively at the session-level (not the global file I/O buffering).

But, at any rate, you should give it a try when it's released to see if it is somehow related.

Tim Young
Elevate Software
www.elevatesoft.com

Tim i think this is something different but I don't know it 100% because the problem is not 100% reproducable at the moment; possible that something totally different like Operating system, antivirus or something else is responsible for this.

We'll try your next version asap it is avaible.

Thank you very much for your hard work!
Yusuf Zorlu
MicrotronX

Yusuf,

Per my email, here's the incident report that describes the problem and the resultant fix:

https://www.elevatesoft.com/incident?action=viewaddr&category=edb&release=2.31&incident=4741

Thanks again for the project that reproduced the issue.

Tim Young
Elevate Software
www.elevatesoft.com

For all readers, this issue is now fixed (notes in the incident report on the cause, etc.):

https://www.elevatesoft.com/incident?action=viewaddr&category=edb&release=2.31&incident=4741

The build system is building 2.31 B3 right now, and it should be available by tomorrow morning (EST).

Tim Young
Elevate Software
www.elevatesoft.com

Thank you Tim. With Build 4 now everything look very very good.
Yusuf Zorlu
MicrotronX