Devart Forums

Hi

Rambling:
My company develops its application using Borland C++ Builder 5 and have recently migrated from using the Borland Database Engine over to SDAC, the transition has mostly been seamless but at one of the sites where our software is installed we have found that a 'Lock request timeout' occurs quite frequently which seems to be caused by queries waiting with the wait type ASYNC_NETWORK_IO . The offending query that was causing the ASYNC wait is
Our lead developer has scoured the source code and cannot find the source of this query which leads me to suspect that it is not being called directly but rather as a precursor to or bi-product of some functionality, Presumably it would be there in order to load that table into memory.

Question: Are there any objects or functions of SDAC that call 'select * from ....' behind the scenes?

It'd be much appreciated if someone could help with this matter and as this is my first post please let me know if more information is required to be of assistance.

Thank you all

To solve the issue, try the following:

1. Increase the default locking interval for connection, e.g., up to 15000 . For this, set the TMSConnectionOptions.DefaultLockTimeout proeprty to 15000 .

2. Please make sure the participants table has a primary key. If the table has no primary key, and you are trying to lock a particular record, then the whole table will be locked instead of this record.

3. A similar issue is described in the MSDN blog: http://blogs.msdn.com/b/joesack/archive ... ected=true . Try the suggestions from this article.

Thank you very much for your response Azyk, We managed to trace the source of the select * query. It turned out to be a TTable object which was invoking the query and FetchAll had been set to true.

Turning off FetchAll has almost eliminated the Lock Request Timeout occurrences (has happened once since) but even so we are planning to remove the TTable because the participants table should never need to be loaded onto the client machines in it's entirety and that call is causing unnecessary overhead.

If there is anything else I can help you with, please contact me.