Board index » delphi » BDE, MS SQL Server and DLL in D4 c/s

BDE, MS SQL Server and DLL in D4 c/s

MS SQL Server access I have no problem with, making and using a DLL I have
no problem with, it's when the DLL is to have a TDataModule or even just a
TDatabase!  The ".EXE" does not have any data connectivity built into it at
all.  It initializes the DLL and that causes a create on a data module in
the DLL.  At this point I get a BDE error that I cannot seem to trace!  I
was wondering if anyone had any code examples of doing this or not?  Does
not need to be with MS SQL Server, just using a TDatabase in a DLL.

Thanks,

Michael P. Bobowski
CADDPlus, Inc.
Milwaukee, WI, USA
e-mail: mb...@execpc.com

 

Re:BDE, MS SQL Server and DLL in D4 c/s


Michael,

  Funny you should ask this. It was discussed a while back. Here's the
bottom line.

If you put a tdatabase in a dll and then create that dll multiple times or
have several dll's
with tdatabases in them, realize that each tdatabase will have it's own
connection. This may
not be a deal with true sql server but if you happen to be using the sql
server that comes with
SBS then you will run out of connections. (Just an FYI type of deal) I think
the best way to
handle this is to have one tdatabase (and maybe the login) in your exe and
then pass the
tdatabase into your dlls. This preserves the login from the exe and all dlls
will be using the
same connections. I use this approach but a little differently. I have an
exe with all of my forms
and put all of my reports in the dll.

He'res the code you will need.

In your exe...
procedure ShowForm1(d : tsession); external 'dllprj.dll';

implementation

procedure TForm1.Button2Click(Sender: TObject);
begin
ShowForm1(session);
end;

In your dll ...

procedure ShowForm1(d : tsession);
var
 form1 : tform1;
begin
 session := d;
 form1 := tform1.create(application);
 form1.Query1.Databasename := d.Databases[0].DatabaseName;
  form1.show;
end;

Regards,

Craig Baugh

Quote
Mike B. <mb...@execpc.com> wrote in message

news:7er8iu$9vl8@forums.borland.com...
Quote
> MS SQL Server access I have no problem with, making and using a DLL I have
> no problem with, it's when the DLL is to have a TDataModule or even just a
> TDatabase!  The ".EXE" does not have any data connectivity built into it
at
> all.  It initializes the DLL and that causes a create on a data module in
> the DLL.  At this point I get a BDE error that I cannot seem to trace!  I
> was wondering if anyone had any code examples of doing this or not?  Does
> not need to be with MS SQL Server, just using a TDatabase in a DLL.

> Thanks,

> Michael P. Bobowski
> CADDPlus, Inc.
> Milwaukee, WI, USA
> e-mail: mb...@execpc.com

Re:BDE, MS SQL Server and DLL in D4 c/s


Craig,

    Thanks for the reply.  However it was a stupid error on my part that was
causing the error, still don't know exactly why I couldn't step through it
with the de{*word*81} though.  I had a field in SQL that was "tinyint" acting as
a boolean (0/1) and in code I put ".AsBoolean".  It should have been
"Boolean(.AsInteger)".  It's all working now.
    Normally I would follow the path you discribed for larger scale
applications.  However, the application was one exe with one dll just to
execute applications.  We call it "Launch".  With this you never directly
execute the application that you want, instead you execute the "Launch"
application with the actual application passed as a parameter.  The "Launch"
application then checks a network location of current executables for file
versions and updates the local PC if need be.  We put all the version
checking and update copying code into a DLL so that the "Launch" can
actually update itself as well.  This is why the TDatabase had to be in the
DLL not the EXE.  If we need in the future to update the data access in any
way the EXE just copies a new DLL.  Then we tied all that to a MS SQL Server
database which we designed for full version control.  This way all changes
are recorded and when new updates get copied to someone's PC, they see a
list of modifications.  As well the database has a full list of associated
DLL, OCX, VBX, etc. to update for the application.

Thanks again,

Michael P. Bobowski
CADDPlus, Inc.
Milwaukee, WI, USA
e-mail: mb...@execpc.com

Other Threads