dBExpress Deployment for MS SQL Server

streatley · Post by **streatley** » Mon 09 Oct 2006 18:24

We have the dBExpress drivers from you for both SQL Server and Oracle - the development environment is VCL under Borland BDS 2006.

These questions relate to SQL Server.

The default dbxconnections.ini & dbxdrivers.ini reside in (typically) C:\Program Files\Borland\BDS\4.0\dbExpress. This is OK for development but when we come to deploy we ideally want to ship the exe, dbexpsda30.dll and the ini files for installation in one directory. This raises the following questions:

1. What determines where such an exe 'looks' for the ini files?

2. How does one change this?

3. Is it possible for multiple sets of these two ini's to co-exist on one machine?

and finally

4. Can the dbexpsda30.dll file be 'built' into the exe?

Thanks, in advance for your help.

Regards
Anton
Streatley Software

Jackson · Post by **Jackson** » Tue 10 Oct 2006 12:23

> 1. What determines where such an exe 'looks' for the ini files?

Paths to these files are stored in registry. See sources of
LoadParamsFromIniFile method (TSQLConnection) in SqlExpr.pas

> 2. How does one change this?

Most likely you'll have to modify it manually. We advice you not to use inifiles.
Store parameters in Params property.

> 3. Is it possible for multiple sets of these two ini's to co-exist on one machine?

Use LoadParamsFromIniFile method (TSQLConnection).

> 4. Can the dbexpsda30.dll file be 'built' into the exe?

If you are user of DbxSda Professional Version, you can use something like this:

Code: Select all

uses
  ...dbxsda, ...;
...
initialization
  RegisterDbXpressLib(@getSQLDriverSQLServer);
end;

But you should keep in mind that you can't statically link more than one driver.
This is restriction of dbExpress technology.

For more information please see Delphi help.

streatley · Post by **streatley** » Tue 10 Oct 2006 13:46

Many thanks for your reply.

From what I understand the LoadParamsfromininFile method will enable us to dispense with the dbxconnections.ini, but are we still left with having to use the dbxdrivers.ini?

Regards
Anton

Jackson · Post by **Jackson** » Wed 11 Oct 2006 15:19

If you use different versions of dbxconnections.ini file at run time set
LoadParamsOnConnect to True to ensure that at runtime the connection is
established using the configuration associated with ConnectionName in the dbxconnections.ini file.
In such case you have to deploy the dbxconnections.ini file with your application.
For more information please see LoadParamsOnConnect property in in Delphi Help.

streatley · Post by **streatley** » Wed 11 Oct 2006 15:24

Thank's for your reply - I think I am quite comfortable as to what's required regarding the dbxconnections.ini.

What I am confused about is whether only one dbxdrivers.ini is allowed, whether we still need it or if the entries can somehow be incorporated in the approach you've recommended.

Regards
Anton

Jackson · Post by **Jackson** » Fri 13 Oct 2006 11:34

We do not recommend you to use ini files.
At run time you should to set LibraryName, VendorLib and GetDriverFunc properties
Example of setting up SQLConnection parameters at run time you can find in ReadMe.html.

Babnik42 · Post by **Babnik42** » Tue 28 Nov 2006 12:00

It's not quite true that you can only statically compile in one dbexpress driver. It's actually quite easy.

1) Create a new Driver function :

function getSQLDriver(SVendorLib, SResourceFile: PChar; out Obj): SQLResult; stdcall;
begin
//depending on the vendorlib, return the correct driver
if sVendorLib = 'sqloledb.dll' then
Result := getSQLDriverSQLSERVER(sVendorLib, sResourceFile, Obj)
else if sVendorLib = 'dbexpoda30.dll' then
Result := getSQLDriverSQLORANET(sVendorLib, sResourceFile, Obj)
else
Result := DBXERR_DRIVERINITFAILED;
end;

2) Register this driver :

RegisterDbXpressLib(@GetSQLDriver);

That's it.

May I add that some of the code is common between drivers (Memutils, dbxpress30, daconsts etc etc), and since it IS actually possible to compile in more than one, there should be a common folder for this code used by all drivers.

Jackson · Post by **Jackson** » Wed 29 Nov 2006 11:22

You are right, you can use this method to link more than one driver statically.
You can also put common files in common directory, but it is necessary to be sure that they are compatible.