| Subject | Re: [firebird-support] Custom SYSDBA in Applications |
|---|---|
| Author | Helen Borrie |
| Post date | 2010-11-01T18:52:32Z |
At 04:06 AM 2/11/2010, johnporteous@... wrote:
There's not a "one solution fits all" way to deal with this, other than to configure that single host machine on the *assumption* that later software additions from outside that use a Firebird back-end are potentially going to want to break what you have there already. IOW, make a range of ports available for Firebird instances, pay close attention to the presence (or not) of Registry and envvar dependencies and provide enough resources on the host machine to handle multiple running servers. If I've made that sound simple, it's not.
./heLen
>In addition to our own programming (Delphi 2010 and Firebird 2.1) we have purchased PC based equipment that has also installed and used Firebird.It sounds as though you are referring to "separate host machines" here, not separate instances of Firebird server. Trying to run disparate database products on a single host machine under the same instance of Firebird server is likely to be fraught with problems if the applications were written hard-wired for different Firebird server versions or models. It's also a source of messes where the third-party products assume they are the first and only instance of Firebird on the host machine and depend on the Firebird environment variables and/or (on Windows) the out-of-the-box Registry keys to find things.
>
>All of our programs (internal use only) either use a trusted login to the databases, or a user name based on the Windows login name used. The SYSDBA login is used only for database changes, backup/restore sequences, etc.
>
>We currently have one 3rd part program where the program logs in using SYSDBA using a bespoke password (a cable checker controlled from a PC). We were able to change the SYSDBA on our main server to be able to have all 'working' databases on the same server.
>
>We are now faced with a second company doing the same thing. Is there an easy solution (other than loading firebird onto separate servers for each such application)? Not buying the associated product isnt an option.
There's not a "one solution fits all" way to deal with this, other than to configure that single host machine on the *assumption* that later software additions from outside that use a Firebird back-end are potentially going to want to break what you have there already. IOW, make a range of ports available for Firebird instances, pay close attention to the presence (or not) of Registry and envvar dependencies and provide enough resources on the host machine to handle multiple running servers. If I've made that sound simple, it's not.
./heLen