Hello,

My main application is a Delphi application that uses an ElevateDB database.  I have a new need to allow Microsoft Word to access my data for mail merges.

It looks like the right solution is to use the ODBC driver and setup a Data Source that points to my database. If that is not the case please let me know and I can skip a few steps.

I have the ODBC driver installed and see in the help manual the different parameters that can be setup for the Data Source entry.  What I am missing is how to correctly install the driver on the client machine.  Are my users supposed to download and run the ODBC install from Elevate?  Is there an MSI merge module some where I can use?  Do I just put the edbodbc.dll in my application's directory and register it from there?  

I was expecting to see some type of redistributable install for the ODBC driver but I could not find one.  Installing in my own directory seems like a bad idea unless I can use a custom name for the Driver name under the ODBCINSTS.INI section in the registry.

Any advice or just pointing me to the right section of the help file will be appreciated.

Thanks,

Mark

On 3/28/2013 1:20 PM, Mark Elder wrote:
> I was expecting to see some type of redistributable install for the ODBC driver but I could not find one.  Installing in my own directory seems like a bad idea unless I can use a custom name for the Driver name under the ODBCINSTS.INI section in the registry.
>
> Any advice or just pointing me to the right section of the help file will be appreciated.
>
I would suggest you start with this article:
http://www.elevatesoft.com/articles?action=view&category=edb&article=deploying_elevatedb_applications

There is a section on ODBC.

Raul

Mark,

<< I have the ODBC driver installed and see in the help manual the different
parameters that can be setup for the Data Source entry.  What I am missing
is how to correctly install the driver on the client machine.  Are my users
supposed to download and run the ODBC install from Elevate? >>

No, definitely not.  You should never set up a link to the complete
ElevateDB ODBC Driver setup that we provide, either on our site or your
site.  We've had issues in the past with this where people were downloading
the product for free from a customer's web site because they did something
similar.

<< Is there an MSI merge module some where I can use? >>

The ODBC driver only requires a bare minimum of registry entries, and the
link that Raul gave details them under "ODBC Driver Requirements".

<< Do I just put the edbodbc.dll in my application's directory and register
it from there? >>

Yes, you can register it from there.

<< I was expecting to see some type of redistributable install for the ODBC
driver but I could not find one.  Installing in my own directory seems like
a bad idea unless I can use a custom name for the Driver name under the
ODBCINSTS.INI section in the registry. >>

See the notes I just added to the technical article mentioned in the section
mentioned:

==========================

You can use a different name other than "ElevateDB 2 ODBC Driver" for the
main registry key and the registry value under the ODBC Drivers key. Just be
sure to use the same name in both places. However, the name must match the
name of the driver as specified in the version information for the driver
DLL. For example, the Unicode version of the ElevateDB 2 ODBC Driver is
called "ElevateDB 2 ODBC Driver (Unicode)". You can find out the name of the
driver by right-clicking on the driver DLL file name in Windows Explorer,
and then selecting the Properties option. The name of the driver will be
found on the Details tab of the Properties dialog, under the Product Name
field.

Note:
If you want to use a custom name for the driver DLL, then you'll need to
edit the version information in the driver DLL, or re-compile it using the
ElevateDB ODBC Driver source code (ElevateDB DAC Standard with Source or
Client-Server with Source products). However, if you edit the version
information in the driver DLL using an external editor, the code-signing
will be removed from the driver DLL in the process.

==========================

So, you *can* change the version information for the driver externally,
you'll just lose the code-signing in the process.  However, you'll then have
a custom driver that won't interfere with any other ElevateDB ODBC driver
installation.

If you have any other questions, please let me know.

Tim Young
Elevate Software
www.elevatesoft.com

OK so I can use my own name.  That still leaves me with the question if I *should* use my own name or not.  It sounds like I am correct that installing with the standard name could affect other user's installs.  Is there a standard folder I should install to i.e.
C:\Program Files (x86)\ElevateDB 2 DAC-STD\libs\edbodbc
or maybe C:\Program Files (x86)\Common Files\ElevateDB\?

Right now it seems like my two options are both less than ideal.  

In the case of using my own name...
 - I need to hack the dll's first before I add them to my install.
 - I need to remember on updates to repeat the hack each time there is an update.
 - Without source I need to go without code signing.

In the case of using the standard name:
 - I run the risk of affecting other companies installs.
 - I also risk having others affect my install.
 - I need to pick a default location to install to.

Any idea on what most customers are currently doing?

"Tim Young [Elevate Software]" wrote:

<< If you want to use a custom name for the driver DLL, then you'll need to
edit the version information in the driver DLL, or re-compile it using the
ElevateDB ODBC Driver source code (ElevateDB DAC Standard with Source or
Client-Server with Source products). However, if you edit the version
information in the driver DLL using an external editor, the code-signing
will be removed from the driver DLL in the process. >>

OK so am testing trying to setup the driver with my own name.  I run into all types of trouble when setting the name without adjusting the DLL but I am wondering why?  I can't find anything on MSDN that indicates this is a requirement and looking at the MS Access DLL I don't see a match in the names.  

Is there something specific to ElevateDB that requires this?

Thanks,

Mark

Mark,

<< OK so am testing trying to setup the driver with my own name.  I run into
all types of trouble when setting the name without adjusting the DLL but I
am wondering why?  I can't find anything on MSDN that indicates this is a
requirement and looking at the MS Access DLL I don't see a match in the
names.

Is there something specific to ElevateDB that requires this? >>

The EDB ODBC driver uses the DLL version information (Product Name) to
determine what "driver name" to use for the registry.  It's the only way to
make the driver name flexible without requiring customers to hard-code a
change in the source code.

If you have any other questions, please let me know.

Tim Young
Elevate Software
www.elevatesoft.com

Mark,

<< OK so I can use my own name.  That still leaves me with the question if I
*should* use my own name or not.  It sounds like I am correct that
installing with the standard name could affect other user's installs. >>

Yes, it could do so.

<< Is there a standard folder I should install to i.e.
C:\Program Files (x86)\ElevateDB 2 DAC-STD\libs\edbodbc
or maybe C:\Program Files (x86)\Common Files\ElevateDB\? >>

It doesn't matter.  What matters is the driver name used.

<< Right now it seems like my two options are both less than ideal. >>

If you can come up with a better arrangement, I'll be happy to implement it.
There's just no really "clean" way of customizing a DLL/driver in this
manner.  I've thought about offering an ODBC "component" that can be
customized in a shell project, similarly to the edbsrvr.dpr project, but
that also suffers from similar issues with breaking the code-signing,
requiring re-compilation, etc.

I'll have to see if I can come up with a utility to stamp the driver with
company-specific version information.

<< Any idea on what most customers are currently doing? >>

It's a mixed bag.  I usually recommend to customers that they deploy a
custom driver, but it's up to them as to what they ultimately choose.

If you have any other questions, please let me know.

Tim Young
Elevate Software
www.elevatesoft.com

Everything seems to be running good for me now.  I am installing with my own name.  Really the only downside is needing to change the Product Name in the DLL.

Others may be different but I really consider the ODBC drive to be an application runtime.  Those typically have a standard location they are installed to.  Usually something under c:\program files\common files.  The only way for us users to install it to a standard location is for you to publish and document what the correct standard location is.

Usually runtimes include a setup program, a merge module (msm) or something similar to ensure that end users don't mess up the install.  The installer that you would provide would always install to the same location, make sure that old versions are not installed over the top of newer versions, etc.

Other than the DLL modification I don't have a problem with adding it to my custom install.  I am still wondering about the need for the Product Name to be set in the DLL give that Microsoft does not do that from their own drivers.

Mark,

<< Others may be different but I really consider the ODBC drive to be an
application runtime.  Those typically have a standard location they are
installed to.  Usually something under c:\program files\common files.  The
only way for us users to install it to a standard location is for you to
publish and document what the correct standard location is. >>

Again, regardless of what it is considered, it can be installed anywhere.
It doesn't matter where it is installed in terms of proper operation, and
all that matters is how the registry entries are set up.  We are not selling
a standardized product, and are specifically selling to customers that
*embed* the various parts of the product into *their* product.  Therefore,
there *isn't* any standard installation location.

<< Usually runtimes include a setup program, a merge module (msm) or
something similar to ensure that end users don't mess up the install.  The
installer that you would provide would always install to the same location,
make sure that old versions are not installed over the top of newer
versions, etc. >>

Again, we don't do this, or encourage this, because we are not giving away
the driver for free.  We have had issues in the past where this has led to
customers providing such a distribution on their web site.  This is why we
tell customers to provide their own installation and not use ours.

<< Other than the DLL modification I don't have a problem with adding it to
my custom install.  I am still wondering about the need for the Product Name
to be set in the DLL give that Microsoft does not do that from their own
drivers. >>

We're kind of talking in circles here: MS does not enable you to
customize/brand their drivers and registry entries, so I'm not sure how MS's
distributions are relevant to this discussion.  Unless you're saying that
they allow you to use a different driver name in the registry entries, yet
use the same DLL ?

In case I'm not being clear on this point, the reason that the driver needs
to know the driver name is because it has to pass the driver name to various
ODBC API calls that require it for writing out DSN's, etc.  So, it has the
option of hard-coding it (no customization possible without source code), or
using something from the version information.  The only other alternative I
can think of is some sort of .ini/.xml/configuration file that has to be
present in the same location as the .dll and provides this information.

Tim Young
Elevate Software
www.elevatesoft.com

"Tim Young [Elevate Software]" wrote:
<< In case I'm not being clear on this point, the reason that the driver needs
to know the driver name is because it has to pass the driver name to various
ODBC API calls that require it for writing out DSN's, etc.  >>

Ok that was the part I was missing.  I have my install all working now so no problems on my end.  But if I was going to suggest something I would say use the File Name as the driver name. Renaming the file does not affect code signing the same way that changing version information does.  With long file names I could easily get a nice looking file name/driver name.

Thanks for your help!

Mark