Group: Forum Members
Posts: 2K,
Visits: 6.6K
|
Lets step back a bit. You are typically dealing with two databases when you do security. First, there is the StrataFrame database. This is the one that uses the project ID. Typically you will put all you permsissions in here and likely a very few security users, if any, that are simply the ones you want in the database during a fresh install. You likely might also include roles here too. This allows for easier development. This data must then be deployed to the runtime database.
That is because the SF db isn't ever used at runtime and strictly speaking, isn't actually required. You must deploy the security database tables and optionally, the permissions/roles/base security users configured in the StrataFrame database. This is done most simply via the DDT. You then setup a connection to the database that contains the security tables in the SetDataSources method and you setup security keys/vectors in InitApplication. This database can be your main application database or a specialized security database....but never, ever is the StrataFrame database used at runtime. At runtime the project ID isn't every used: when you call the SecurityDialog at runtime, it just isn't used.
I just want to make sure you have this straight, because if don't have the connection to the runtime security database setup correctly and have your security data deployed, then things can get weird fast.
|