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. HB
