Showing results for 
Search instead for 
Did you mean: 

SQL Toolkit crashing with multiple threads

Go to solution

Hello everyone and Happy New Year!

I was hoping someone might be able to shed some light on this problem. I am updating an older application to use multiple threads. Actually the thread that is causing a problem right now is created by using an Asynchronous timer.


I am using CVI 2010, and I think the SQL toolkit is version 2.2.

If I execute an SQL statement from the main thread, there is no problem.

hdbc = DBConnect( "Provider=Microsoft.Jet.OLEDB.4.0;Data Source=sample.mdb;Mode=ReadWrite|Share Deny None" );
hstmt = DBActivateSQL( hdbc, "SELECT * FROM SAMPLES" );


If I add code to do the same functions in a timer callback, it causes a stack overflow error.

.. start main thread


NewAsyncTimer (5.0, -1, 1, &gfn_quicktest, 0);

 .. end main thread

.. and then the timer callback

int CVICALLBACK gfn_quicktest (int reserved, int timerId, int event,  void *callbackData, int eventData1, int eventData2)
    int hdbc = DBConnect( "Provider=Microsoft.Jet.OLEDB.4.0;Data Source=params\\sample.mdb;Mode=ReadWrite|Share Deny None" );
    int hstmt = DBActivateSQL( hdbc, "SELECT * FROM SAMPLES" );
  return 0;


The program crashes with a stack overflow error when the DBActivateSQL statement is called.

I understand that the ODBC driver for Access may not support multithreading, but I am only connecting to that database from the same thread with those 2 statements only so it should be fine ?

Any insight would be appreciated,

0 Kudos
Message 1 of 3
Accepted by topic author Mande

I just tried this using the sample access database that comes with CVI. It uses a DSN instead of mdb. It worked fine though. I don't see any reason multithreading would be a problem here if you are opening and closing the connection in the same code segment. I do notice that you are using params in the asyn callback connection string. Where does this come from? Maybe try using the sample database and see if that works.

National Instruments
0 Kudos
Message 2 of 3

Thank you very much for trying this, it is so helpful to figure if it happens the same to others...


It appears that the problem arises from going directly to the Microsoft.Jet.OLEDB driver.  If I do the same test through a ODBC DSN connection then it works properly.  I guess I will have to find a way to work around this in our application.


Note: The params was a typo when putting my code on the forum and making it easy to read and duplicate.  Sorry about that.

0 Kudos
Message 3 of 3