Ed Dressel wrote:
> Any suggestions?
Several days ago, you wrote:
> We are in the middle of letter our users upgrade their database from
> 1.56 to 3.x at their will. Users can upgrade when they want to--so
> we install 1.56 embedded db as gds32.dll and 3.x as fblcinet.dll in
> the same directory (using IBObjects, we can select which DLL is
> used). Almost all of our users use the embedded version.
> The problem is when a database exception occurs--the "firebird.msg"
> file is used. Is there a way to configure the name that the DLL uses
> for the firebird.msg file? Or should the FB databases be installed
> in separate sub directories? Any suggestions here would be appreciated.
When I read that, I groaned and let it go. This is not a sane way to
deploy an upgrade from a 15-year-old engine to Fb3 (or any full
upgrade, come to that!). So, to avoid trying to write a small book,
I'll make a few suggestions in the hope that you'll start to see that
this isn't a task for the Tooth Fairy.
1) It's not a question of where the databases are installed. The ODS
10.1 and ODS 12 dbs could be in the same subdir, if their names are
different. Use aliases in the respective .conf files to distinguish
them, so that your application will connect to the right one. But
deploying the databases in separate subdirs won't solve the problems
you're planning to create here.
2) I suppose you are aware that the Fb3 engine can't connect to a
sub-ODS 12 database.
3) The rules for deploying embedded apps haven't changed. You still
have to have completely separate and self-contained file structures
for each embedded app, with the Firebird components in their correct
places relative to the application executable. These relative places
are not the same for v.1.5 and v.3.0 so you'll need to study release
notes very thoroughly and TEST your assumptions.
> Almost all of our users use the embedded version
4) Taking 3) into account, if you are deploying the software in
company with full server versions, this whole thing could become a
total mess really quickly.
5) Give up on this idea of letting the users choose. Give them test
versions beforehand if necessary, but have them make the choice before
you deploy; test what they have chosen to make sure it works as
expected; then deploy just that.