Yep.  I knew that.  I guess I should have been more specific.  Let's say I want to create a View to query the users and departments information or any view for that matter which needs to return the user name.  The SFUsers table resides in the Strataframe database.  When I go to deploy the database and move all of the security tables to the production database, all of the views associated with the SFUsers table located in the Strataframe databse will be broken.  What does everyone do in this case when moving from development to production?

Also, in regards to deployment of security, the administrator will be adding new users and roles to the production database which will not be in my development database.   In this case, I only want to update the permissions data in their production database.  Will the DDT enable me to do that? 

The administrator can add as many users and roles as he would like, just not permissions.  The system, by default, allows users to be created at run-time as well as roles.  So that won't be an issue.  As for your view, why would it break?  I don't understand how deploying data would break your view.  Are you hard-coding primary keys, user names, etc?  If not, then your view would not change whether it is being maintained in your production environment or whether you are deploying through the DDT.  Structures aren't changing, just the contents of the tables.  So I don't guess I understand your point here....I could just be misunderstanding what you are trying to accomplish with your view also.  You may need to elaborate some more.

Sorry about the confusion.  Let me explain it this way.  This is only during development.  My UsersDepartments table is in my current development database called "CEI".  The SFSUsers table is in the Strataframe Database.  I want to combine the two tables into a single View in my CEI development database.    Therefore, within my development database I would have to create a View which includes this SQL statement:

SELECT     us_pk AS UserID, us_Username AS UserName, us_FirstName + N' ' + us_LastName AS FullName
FROM         StrataFrame.dbo.SFSUsers

As you can see I specifically have to refer to the StrataFrame database in the SQL.   Now I am using this view in my application. When I deploy my development database to a production database and deploy the SFSUsers table to production database, I will not be able to point to Strataframe.dbo.SFSUsers in the saved View, because the SFSUsers table will now be local to my production database.   When the application runs the View or any view using this SQL, they will fail.   I would have to alter all of the Views to drop the "Strataframe" before deploying them.  Maybe I am confused, but this is what I am seeing is my issue.  What don't I understand?

Thanks,

Jeff

Okay...there is the problem.  The StrataFrame RBS tables get deployed in YOUR database, not the StrataFrame database.  There is a help topic that gives you the scripts to create these tables or you can use the DDT and it will import the structures (and the Deployment Data with your permissions, etc.) into YOUR database.  The StrataFrame database should never be used as part of an actual production setting or views like this.

Backing up, if you were to go into the DDT, you would see that if you create your own database that you would use for distribution, there is a link to import the structures of the RBS tables into your database profile.  Then, when you deploy your database, the SF tables that are used for security are actually in your database.  Next, you want to populate those deployed tables with data from your development environment.  That is why you would want to use the DDT Data Deployment Wizard to pick the appropriate RBS development project, then when you build the DDT profile it will bring in the appropriate records.  Then when you deploy that package, your deployed database of your database, not StrataFrame, houses the actual security records.  It is an export and distribution process that is handled for you by the DDT.

We have a number of queries in our medical application that directly reference those tables as our DB name can change from install to install, but this is never a concern because the SF RBS security tables are in our medical database, not the StrataFrame database.

Hope this clears things up.

Hi Jeff,

Yes you are right to be confused, I have been there too before

This is what you have to do:

1. Using the Role Based Security, create all the users, permissions and groups you will be using in your application.  This would be like a template which then will be copied or deployed (with DDT) to the final database.
   
2. Start using the DDT, it will help you a lot in this case and many others, it is really a must have tool.
3. With the DDT create a new Deployment Data using the wizard to deploy the "Role Based Security Data" to your own database or if you prefer a separate database.  In my case I have it in the application's database.
4. Once this is done, then you can create your view using the real tables and everything will be ok. 
   

After all your testing are done and everything is fine, you can always use the DDT to re-deploy new permissions to your test database, and then the final production database as you wish.  There are a lot of messages in the forum about how this is done so do a search and be ready to dig deeper into this since once you understand it, it will be much more easier and as many things in SF you will be very happy to see the logic behind those features.

P.S.
After using the Wizard to deploy your security tables, pay attention to the "Merge Type" used for each deployment, since that behavior is very important to know what to expect every time you deploy your data, the help file also have more detail information about this as well as messages in the forum.

Edhy Rijo

Jeff,

I've been catching up on this and this statement makes me a bit uneasy.



The StrataFrame database holds meta data used to define BOs, define localization and to define security data. This is used at design time. The meta data in the StrataFrame database must some how get deployed for use. In the case of BOs, you have to build the partial designer file, which gets put into your VS project.  In the case of localization you either export the XML files to be deployed with the app or embedded into the app or you must deploy them to a SQL server. In the case of the security data, it must be deployed to a SQL Server database.  None of the data in the StrataFrame database is usable at runtime.   It is used to simplify the development of the app. And just like the app, you have to deploy it to use it.

If that makes sense, then you need to somehow deploy the information within the StrataFrame database to a runtime app/security database.  You have a couple of options here:

- You can integrate the security tables within you main app database. This is easy if you are using DDT to manage that database as you can easily import the security tables/views into the database in DDT.

- You can use a separate database for security. You might want to do this if several apps all share the same security or if you can't use DDT to manage the main app (perhaps you don't have control over that database). 

In either case you must some how deploy the data from the StrataFrame database before you can use it.

Here's the basic process:

1. Add security tables and views to application database. Three ways to do this:
    a) If using the DDT for main database, you can just import the security tables.
    b) If you aren't using the DDT, but still want the security tables in the same database, see help file for information on to manually add the security tables/views.
    c) If you aren't using the DDT and can use a separate security db, then use DDT to setup the security database, importing the security tables/views.
2. Configure permissions, default/required roles etc using Security Dialog from within VS. This stores that information in the StrataFrame database, so it is not yet in the actual database and is unusable at run time. It is usable at design time though.
3. Before testing the app with the new permissions, you need to deploy the data in the StrataFrame database to the runtime database. DDT makes this easy (via deploying a data package), but you can do manually too via T-SQL.

Before we talk about this any more, does this make sense?

Jeesh, Trent and Edhy beat me to it! Hopefully between the three explanations you're starting to get less confused (and not more confused!).

Hi Edhy, Trent and Greg,

As always, thank you for the awesome support and for all of the information.  Sorry, I really do not want you guys to spend some much time explaining the RBS deployment scenario.  But as a result, I do understand what is needed.  My confusion was I don't know yet what all of the permissions or groups I need, because I am just starting to look at RBS for the application.   Currently, I am at the mercy of the company users and management and things like Security during development can change often.  I was hoping there was a way to keep everything in Strataframe while I was creating the RBS system.  At this point, I see I will have to dive into DDT to deploy my security data as it changes.  To be honest, it is just one more thing I did not want to have to tackle at the moment.

Thanks,

Jeff

If your using the DDT, the actual deployment takes about a minute.  It'll take a bit to figure it out, but once you dive in, we're here to help with the issue that come up.  Start with the help file, search the forum (there are lots of info about this...I think Edhy and I both asked about this when we were staring out). 

Well, if it is that fluid at the moment, just write an SQL script to extract the contents from the RBS tables in the StrataFrame database and dump them into your database.  It is the same thing, really.  That way you can just continue to add your permissions, etc. and then go run your script to move those permissions into your DB.  Just make sure that you have the RBS tables in your database, then write a script that extracts from StrataFrame and dumps into your database.  By doing this you don't have to tackle the DDT (which would probably be faster, BTW ).