Subject | Re: [IBO] How to get the DB to see a Deletion then add aForeign Key constraint? |
---|---|
Author | Helen Borrie |
Post date | 2006-01-13T00:13Z |
At 03:56 PM 12/01/2006 -0800, you wrote:
fiddle with constraints.
the Windows user, not the server user. In fact, embedded bypasses server
authentication, meaning that any old combination of username and password
(including ones that don't even exist) will get you into a database via
embedded.
Inside the database, though, permissions apply, so the correct username and
password would still need to be passed on connection, even though they are
not used for server authentication. It's the Windows user that "owns" the
exclusive lock, so the embedded model doesn't prevent the same Windows user
from connecting to the database multiple times, e.g. run several apps
concurrently and/or run multiple instances of the same app.
But don't take my word for it. Test your planned production environment
rigorously.
Helen
>Thanks, Helen:Yes. But don't forget that only sysdba or the owner of the table can
>
>Couple of additional questions:
>1. I understand the need to shutdown the database and on my development
>computer, I'm using the full FB server.
>I found the IBOAdmin component to do this--looks like IBOConfigService has the
>Shutdown and ServiceStart procedures to do this. Is this correct?
fiddle with constraints.
>2. Does all this apply for my end users who will be using FB embedded?Theoretically yes, since the exclusive access thing in embedded applies to
the Windows user, not the server user. In fact, embedded bypasses server
authentication, meaning that any old combination of username and password
(including ones that don't even exist) will get you into a database via
embedded.
Inside the database, though, permissions apply, so the correct username and
password would still need to be passed on connection, even though they are
not used for server authentication. It's the Windows user that "owns" the
exclusive lock, so the embedded model doesn't prevent the same Windows user
from connecting to the database multiple times, e.g. run several apps
concurrently and/or run multiple instances of the same app.
But don't take my word for it. Test your planned production environment
rigorously.
Helen