Solved

Access violation in module MSDART.DLL

Posted on 2004-09-11
7
1,528 Views
Last Modified: 2012-06-21
I have a Delphi program accessing a MS/SQL database.
I initially used the BDE to access it and everything ran fine.
For technical reasons too long to explain here, I have decided to 'migrate' the program to ADO components.
And here I have some problems.
The migrations was of course very simple, moving to TADOconnection etc...
But at execution, I first got a problem that CoInitialize was not performed, so after searching, I found I had to insert a CoInitialize(nil) instruction before to invoke these AFO objects.
But now, just before to terminate, the program issues an access violation in module MSDART.DLL. (I get this when running if from the Delphi development environment)
What the program does is
1. connect to the database
2. read some data in a table via a stored procedure
3. write some of this data to the standard output (writeln(text))
4. terminate
The data is correctly written to the standard output (the console) but an addition info is written there : runtime error 216.
Please help !
0
Comment
Question by:LeTay
7 Comments
 
LVL 12

Expert Comment

by:Ivanov_G
ID: 12034473
Where is your TADOConnection? On a form or DataModule? Long time ago I had the same problem, but when the ADO Connection was moved to data module - it was fine...
0
 

Author Comment

by:LeTay
ID: 12042031
Neither on a form nor on a datamodule
I just create it at run time
0
 
LVL 17

Expert Comment

by:Wim ten Brink
ID: 12044843
The problem you're having is that you don't free any interface variable that gets initialized in your code. I've had the same problem and solved it like this:

program EnumADSI;

uses WhateverYouNeedToUse;

procedure ProcessDatabase;
begin
  // Whatever
end;

begin
  if Succeeded(CoInitializeEx(nil, COINIT_MULTITHREADED or COINIT_DISABLE_OLE1DDE or COINIT_SPEED_OVER_MEMORY)) then begin
    try
      // Call some procedure here that will do all the work with your database.  
      ProcessDatabase;
    except on E: Exception do WriteLn(E.Message);
    end;
    CoUninitialize;
  end;
end.

Whatever you do, try avoiding the use of global interface variables since Delphi is a bit lazy trying to clean them.

And don't forget to call CoUninitialize...

The runtime error just occurs because Delphi is trying to clean up some interfaces but for whatever reason they got messed up during the finalization.
0
 

Author Comment

by:LeTay
ID: 12063519
The remark of Ivanov (moving to a tdatamodule) looks going in the same direction that alex remark : some clean-up is not ... clean.
But now look at this :
I wrote this simple console application (I put some .../... on unuseful lines for this purpose) where there is nothing special done at the end (no couninitialize) and ... it works fine !
I think I need to have an indepth look at the code (much longer) that has the exception...
Here is the working code :
program P1;

uses
  Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
  Dialogs, StdCtrls, Buttons, ADODB, DB, ActiveX;
{$R *.res}
var
 DB1:TADOConnection;
function ADOConnectSQL(DB1:TADOConnection):boolean;
begin
 with DB1 do
  begin
   ConnectionString  := .../...
   ConnectionTimeout := 15;
   CommandTimeout    := 300;
   KeepConnection    := True;
   LoginPrompt       := False;
  end;
 try
  DB1.Open;
  Writeln('DB open successful');
 except
  Result := False;
  Writeln('DB open failed');
  Exit;
 end;
 Result := True;
end;
procedure ADOGetSQL;
var
 Temp:string;
 SP:TADOStoredProc;
begin
 SP := TADOStoredProc.Create(Application);
 with SP do
  begin
   SP.Connection := DB1;
   ProcedureName := .../...;
   Parameters.Clear;
  end;
 with SP do
  begin
   Parameters.CreateParameter(.../...);
   try
    Prepared := True;
    ExecProc;
    Temp := Parameters.ParamByName(.../...);
    Free;
   except
    Exit;
   end;
  end;
 Writeln('DB data is ' + Temp);
end;
begin
 CoInitialize(nil);
 DB1 := TADOConnection.Create(Application);
 if ADOConnectSQL(DB1) then ADOGetSQL;
 DB1.Free;
end.
0
 

Accepted Solution

by:
modulo earned 0 total points
ID: 13432786
PAQed with points refunded (500)

modulo
Community Support Moderator
0

Featured Post

Is Your Active Directory as Secure as You Think?

More than 75% of all records are compromised because of the loss or theft of a privileged credential. Experts have been exploring Active Directory infrastructure to identify key threats and establish best practices for keeping data safe. Attend this month’s webinar to learn more.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

The uses clause is one of those things that just tends to grow and grow. Most of the time this is in the main form, as it's from this form that all others are called. If you have a big application (including many forms), the uses clause in the in…
In my programming career I have only very rarely run into situations where operator overloading would be of any use in my work.  Normally those situations involved math with either overly large numbers (hundreds of thousands of digits or accuracy re…
This Micro Tutorial hows how you can integrate  Mac OSX to a Windows Active Directory Domain. Apple has made it easy to allow users to bind their macs to a windows domain with relative ease. The following video show how to bind OSX Mavericks to …
Windows 10 is mostly good. However the one thing that annoys me is how many clicks you have to do to dial a VPN connection. You have to go to settings from the start menu, (2 clicks), Network and Internet (1 click), Click VPN (another click) then fi…

895 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

13 Experts available now in Live!

Get 1:1 Help Now