Delphi Pages Forums

Delphi Pages Forums (
-   DB-Aware (
-   -   [SOLVED] TADOQuery crashing on open in thread (

ShaunVW 10-21-2016 06:35 AM

TADOQuery crashing on open in thread
What used to run fine is now crashing, and I can't seem to figure out why.
I have placed the TQuery (of type TADOQuery) in a try/except block, but it never gets to the except part.
When I single step it, I can get it all the way to a procedure in Data.Win.ADODB as per the below:


procedure TADOCommand.OpenConnection;
  if not Assigned(CommandObject.Get_ActiveConnection) then
    if ConnectionString <> '' then
    else if Assigned(FConnection) then
    end else

I can't get it further than the line
CommandObject._Set_ActiveConnection(FConnectionStr ing)

When I F7/single step it from this line, it goes to the procedure in Systems.Variants as per below:

procedure _VarFromWStr(var V: TVarData; const Value: WideString);
  if (V.VType and varDeepData) <> 0 then
  V.VOleStr := nil;
  V.VType := varOleStr;
  WideString(Pointer(V.VOleStr)) := Copy(Value, 1, MaxInt);

However, it processes each of these lines fine, gets to the final 'end', and then crashes, so I'm not sure how to find the reason.

I have previously had a problem like this, and someone said to include a
TQuery.ParamCheck := False;
which I have done, but it still crashes.

This is my procedure in the thread...


 TQuery : TADOQuery;
 query : String;
 i : Integer;
 TQuery := TADOQuery.Create(nil);
 TQuery.ConnectionString := 'FILE NAME=c:\ProductionDB\MP2.udl';
 TQuery.ParamCheck := FALSE;
 query := 'SELECT empcode, firstname, lastname, socsecnum, hiredate, description, costcenter FROM emp ' +
          'LEFT JOIN dept ON emp.department = dept.department';
 i := 0;
  i := 9; //used just so I can single step to this line

Norrit 10-21-2016 07:51 AM

Did you change the content of the .udl?
Since that is holding your real connection settings.

Try rebuilding your .udl

Other thing that I can think of is permissions on the .udl. Perhaps it's locked exclusively somewhere. Rebuilding it would also solve this issue (in the short run). If that's the case you still should figure out what is locking it (perhaps some test code, it's open in an editor, or whatever you could think of)

Is all this still not working try giving the connectionstring directly in the AdoQuery.ConnectionString (database, user, and so on that is now configured in your udl). Check if that's working properly, perhaps there's something wrong there (db changed permissions on user or whatever).

ShaunVW 10-21-2016 08:08 AM

I haven't changed the UDL file at all, still the original one.
And I use this UDL in other programs too.
But this is its contents anyway, with user/pw removed...


; Everything after this line is an OLE DB initstring
Provider=SQLOLEDB.1;Persist Security Info=False;User ID=...;Password=...;Initial Catalog=MP2;Data Source=\sqlexpress

To check if some process had it locked, I made a copy of it, deleted the original, and renamed the copy to original name again, still same issue.

Norrit 10-21-2016 09:52 AM

And you've provided the AdoQuery connectionstring with this one as suggested?

Furthermore, naming a variable TQuery is also not a good idea. Since TQuery is also a class in DBTables.
I would refactor it to:

query: TADOQuery;
 sql: String;

And if all this still doesn't work, what happens if you create a TAdoConnection and set it to Connected, does that work?
And if that works, instead of the ConnectionString assign the Connection with this new AdoConnection.

Just figuring out if it goes wrong in the connection or in some other part.
For example executing the query, but that would normally give an exception, as connection failure should do also. Therefor my refactoring remark (it's a real longshot though)

ShaunVW 10-21-2016 10:16 AM

Thanks Norrit for your efforts trying to help me.
So I tried to manually set the connection string for the ADOQuery, still crashes.
Then I also changed the TQuery to query, and the query to str as suggested, same result.
Lastly I tried the ADOConnection, it hangs for about 15 seconds trying to assign the connection string, then crashes (before I even set it to connected).
I then tried setting the connection string to a different database (MySQL, the first being an MSSQQ), same result.

The strange thing is that I use this exact setup in my other threads and it works, This one also used to work. I was just wanting to debug it as it wasn't giving me the results I was expecting, and now it just doesn't get past this point.

Norrit 10-21-2016 12:05 PM

And that's the only code in this thread?
What might be an issue is that you call this code from another part where you also did CoInitialize...

Then you could get a construction like:

    ... do some things
    ... do some more things

procedure DoSomething();
    // bla...

If you reach the "... do some more things" you've called CoInitialize(nil) twice, called CoUnitialize (which has no clue of what to unitialize so all will be done).
And I'm not sure what calling CoInitialize(nil) twice has for an effect???

But again, another longshot...

ShaunVW 10-24-2016 05:49 AM

I have found the problem, and it was being caused from the main program!
I have a lot of threads being called from the main program, so in testing this thread, not sure what I thinking when I wrote the code below, but I was calling the procedure that set up the thread, and then told the application to shutdown!
This is what I had...



Obviously it just needed the exit, not the Appllication.Terminate;

Norrit, thanks for pointing me back to the main program, even if it wasn't the CoInitialize that was the problem. Just to answer your question though, I only call these threads once at a time, and if it is still busy, I don't try calling it again, so there will never be a time when CoInitialize has been invoked more than once per thread.

All times are GMT. The time now is 12:51 PM.

Powered by vBulletin® Version 3.8.8
Copyright ©2000 - 2019, vBulletin Solutions, Inc.