| Subject | Re: [firebird-support] Re: Coexistance of autonomous applications |
|---|---|
| Author | Helen Borrie |
| Post date | 2007-11-13T08:35:43Z |
At 07:16 PM 13/11/2007, you wrote:
2. Embedded - depends on platform. Embedded on Windows bypasses user authentication entirely.
3. You don't "add users" to "databases". Sysdba adds users to the security database.
Where you are stuck, regardless of the server model you use, is in not being able to create users on the server *to which the database is deployed*. You can run a privileges script on a database anywhere: users don't have to exist to be granted privileges. However (except for Windows embedded) they *do* have to exist to pass through the authentication at the server and thereafter to be recognised as the user to which the privileges apply.
It seems you are stumped by bad deployment decisions on the part of the creator of the original software. Because it's *possible* to deploy systems in silly ways, it's inevitable that some people will do it...
I would keep trying to find *someone* who knows the SYSDBA password...or can insist that the vendor of the old software provide it.
./heLen
P.S., could you refrain from top-posting and requoting, please?
>Is it possible to use the embeded firebird to create the database and1. You can't create users without the SYSDBA login.
>add users, then to switch to superserver and login as the user
>created using the embeded server.
2. Embedded - depends on platform. Embedded on Windows bypasses user authentication entirely.
3. You don't "add users" to "databases". Sysdba adds users to the security database.
Where you are stuck, regardless of the server model you use, is in not being able to create users on the server *to which the database is deployed*. You can run a privileges script on a database anywhere: users don't have to exist to be granted privileges. However (except for Windows embedded) they *do* have to exist to pass through the authentication at the server and thereafter to be recognised as the user to which the privileges apply.
It seems you are stumped by bad deployment decisions on the part of the creator of the original software. Because it's *possible* to deploy systems in silly ways, it's inevitable that some people will do it...
I would keep trying to find *someone* who knows the SYSDBA password...or can insist that the vendor of the old software provide it.
./heLen
P.S., could you refrain from top-posting and requoting, please?