Adding a new ODBC Driver to the BDE during installation

I see that Borland (Inprise?) added an DbiAddDriver() API call to BDE 4.0
(32-bit version that shipped with Delphi 3.0).

I am trying to ship a product using Delphi 1.47, BDE 2.52, ODBC 2.10 and an
Access 2.0 MDB file.  My installation can install a BDE, ODBC and
successfully configure an ODBC alias by writing the correct entry into
ODBC.INI:

[ODBC Data Sources]
TPMgr=Microsoft Access Driver (*.mdb)

[TPMgr]
Driver=C:\WINNT\SYSTEM\odbcjt16.dll
DBQ=C:\TPMGR\DATA\MAIND.MDB
DefaultDir=C:\TPMgr\DATA
Description=Training Plan Manager
DriverId=25
FIL=MS Access
JetIniPath=odbcddp.ini
UID=admin

However, to get the BDE to connect to this, someone (my customer?) needs to
go into the BDE Configuration program and make the final "bridge" by
clicking the "New ODBC Driver" button and filling in the three boxes that
appear there to install a new driver (called, say, ODBC_TPMgr) that
connects to this ODBC alias.  Only then can my Delphi program use a
TDatabase component and set its DriverName property to "ODBC_TPMgr" and
thus make the connection to my Access Database.

This is possibly a bit unprofessional, in my estimation.

So I assume one of the following applies:

1) There is a secret way that I don't know about.  I've searched long and
hard for it.
2) The whole world gets its customers to do this step for them.

Since Borland added it to BDE 4.0, I can only assume there is a demand for
this API call but I also assume that they aren't going to bother putting it
into the 16-bit API because 16-bit is dead and buried.  Try telling that to
a lot of my customers with Windows 3.1 machines out there!

To come to the point...

If you have some way of solving the problem I'd love to hear about it.  On
the other hand, if you don't but would like some way of doing it, I have
written a program that has a reasonable stab at fixing the problem.  I'm
perfectly willing to make it available at no charge if anybody fancies
trying it out.

Basically, I deciphered the structure of IDAPI.CFG and worked out the bytes
required to "insert" a new ODBC driver.  I've tested it very well and I'm
happy that I don't ever cause anything to break.  As a couple of safety
measures, I do the following:

1) Any modified IDAPI.CFG is always backed up as IDAPI.000, IDAPI.001 etc
so that you always have backup copies of before my program went to work on
it.
2) Any driver will only be installed ONCE.  In other words, if you attempt
to install a driver called ODBC_Test into a .CFG file which already has a
driver by that name, it simply won't do it.  This allows you to run the
program as often as you like without dupicating drivers.  On the other
hand, it does mean that it can't be used to MODIFY a driver's settings.  (I
could make it do this if there was a demand for it but I have no need to do
this).

My program works like this:

At the MS-DOS prompt (or Shell'd from Delphi) you type:

    EDrv C:\IDAPI\IDAPI.CFG MYFILE.TXT

My program (EDRV.EXE) opens IDAPI.CFG and inserts the relevant binary data
to install the driver(s) described in MYFILE.TXT, where MYFILE.TXT looks
like:

Driver:ODBC_TPMgr
    Major:INIT
        Minor:VERSION=1.0
        Minor:TYPE=SERVER
        Minor:DLL=IDODBC01.DLL
        Minor:ODBC DRIVER=Microsoft Access Driver (*.mdb)
        Minor:DRIVER FLAGS=
    End
    Major:DB OPEN
        Minor:USER NAME=
        Minor:ODBC DSN=TPMgr
        Minor:OPEN MODE=READ/WRITE
        Minor:SCHEMA CACHE SIZE=8
        Minor:SQLQRYMODE=
        Minor:LANGDRIVER=
        Minor:SQLPASSTHRU MODE=
    End
End

Driver:ODBC_Another
    Major:INIT
        Minor:VERSION=1.0
        Minor:TYPE=SERVER
        Minor:DLL=IDODBC01.DLL
        Minor:ODBC DRIVER=Microsoft Access Driver (*.mdb)
        Minor:DRIVER FLAGS=
    End
    Major:DB OPEN
        Minor:USER NAME=
        Minor:ODBC DSN=TPMgrUpgrade
        Minor:OPEN MODE=READ/WRITE
        Minor:SCHEMA CACHE SIZE=8
        Minor:SQLQRYMODE=
        Minor:LANGDRIVER=
        Minor:SQLPASSTHRU MODE=
    End
End

etc.

And that's it.  Bear in mind, I do no validation on the sections you enter
or whether you put the relevant number of "Ends" in or whether or not the
correct sections are listed.  You don't have to indent the file contents
like this but it helps to illustrate the structure of the driver entry.

The example shown can be customised to suit any Access driver you want.

In addition, I have written a CFGDUMP program which dumps out the binary
data in a CFG file in a semi-readable format so you can use the "New ODBC
Driver" button to let the BDE Configuration program do it for you and then
inspect to determine the lines you should put in your parameters file
above.  This is how I did it.

I also managed to insert something like the following entry:

Driver:ODBC_Funny
    Major:INIT
        Minor:VERSION=1.0
        Minor:TYPE=SERVER
    End
    Major:DB OPEN
        Minor:SCHEMA CACHE SIZE=8
        Minor:SQLQRYMODE=
    End
End

It worked.  The BDE Configuration program didn't complain, but the "Delete
ODBC Driver" button wouldn't remove it since it didn't look like an ODBC
driver.  Time for that all important IDAPI.007 backup file.

Anyway, hours of endless amu{*word*224}t for you and your installation programs.

Or there's an easy way and I've been rather silly spending time doing this.

Either way, I'd be interested in your comments...