Chris,

<< What happens if I write a program for a customer and it sets up the
configuarion file. Then another company writes an app. using ElevateDB ODBC
and tries to install onto the same customers computer. >>

In such a case you'll want to buy the ODBC source code and brand the driver
for your particular application so that it doesn't interfere with other
applications.

At least for now.  I've got to figure out if there's a way around this
issue.

--
Tim Young
Elevate Software
www.elevatesoft.com

Chris,

<< I have just checked the manual on the ElevateSoft web site for the Win32
version and it shows that for each application you can change the
configuration file by setting the path in the engine so I would have
expected the same functionality for teh ODBC driver. >>

Yes, except ODBC doesn't have the concept of an engine, and the driver is a
DLL and we can't control how/when it is loaded by the application.  This is
why the registry fall-back was required.

<< However all of this could be a mute point as I was planning on using the
ADO driver when it becomes available. >>

ADO.NET has the same issue - everything is connection-based and doesn't
allow for an "application-wide" data object, at least not part of the
general framework design for the data access.

--
Tim Young
Elevate Software
www.elevatesoft.com

So does this mean that there is no way of specifying the Configuration
filepath at connection time?

Chris Holland

Tim Young [Elevate Software] wrote:
> Chris,
>
> << I have just checked the manual on the ElevateSoft web site for the Win32
> version and it shows that for each application you can change the
> configuration file by setting the path in the engine so I would have
> expected the same functionality for teh ODBC driver. >>
>
> Yes, except ODBC doesn't have the concept of an engine, and the driver is a
> DLL and we can't control how/when it is loaded by the application.  This is
> why the registry fall-back was required.
>
> << However all of this could be a mute point as I was planning on using the
> ADO driver when it becomes available. >>
>
> ADO.NET has the same issue - everything is connection-based and doesn't
> allow for an "application-wide" data object, at least not part of the
> general framework design for the data access.
>

Chris,

<< So does this mean that there is no way of specifying the Configuration
filepath at connection time? >>

No, and there most likely won't be.  The workaround that I'm working on will
require that the config path be configured like it is now, but will allow
for app-specific driver configuration.

--
Tim Young
Elevate Software
www.elevatesoft.com

Can you eloborate a bit more on this, or is it to early to say yet?

Chris Holland

Tim Young [Elevate Software] wrote:
> Chris,
>
> << So does this mean that there is no way of specifying the Configuration
> filepath at connection time? >>
>
> No, and there most likely won't be.  The workaround that I'm working on will
> require that the config path be configured like it is now, but will allow
> for app-specific driver configuration.
>

Chris,

<< Can you eloborate a bit more on this, or is it to early to say yet? >>

I have to go through everything a bit more before I can comment any further.
The whole thing is basically a structural issue with the way that the ODBC
drivers and ADO.NET data providers are structured vs. the way EDB requires
the configuration, so I want to make sure that I get it right.

--
Tim Young
Elevate Software
www.elevatesoft.com

Hi Tim,

Could I just rename the ODBC.dll and give it its own registry settings.

Chris Holland


Tim Young [Elevate Software] wrote:
> Chris,
>
> << What happens if I write a program for a customer and it sets up the
> configuarion file. Then another company writes an app. using ElevateDB ODBC
> and tries to install onto the same customers computer. >>
>
> In such a case you'll want to buy the ODBC source code and brand the driver
> for your particular application so that it doesn't interfere with other
> applications.
>
> At least for now.  I've got to figure out if there's a way around this
> issue.
>

Chris,

<< Could I just rename the ODBC.dll and give it its own registry settings.
>>

You don't need to rename the DLL - you simply need to change the version
info name for the DLL.  Then you can give it its own registry settings that
are isolated from any other application's use of the DLL.  I'm working on
something that will be very similar, but won't require modifying the DLL
version info.

--
Tim Young
Elevate Software
www.elevatesoft.com