I started my database by using a copy of the Strataframe Example database which had the Security tables.  I open the Security Dialog box through code (see below).  The editor allows me to add/edit users and roles, but not permissions.  What is wrong?

Program.cs Code:

System.Data.SqlClient.SqlConnectionStringBuilder builder = new System.Data.SqlClient.SqlConnectionStringBuilder();

builder.DataSource = "1LPJPAGLEY\\SQLEXPRESS";

builder.InitialCatalog = "CEI";

builder.UserID = "sa";

builder.Password = "access";

DataLayer.DataSources.Add(new SqlDataSourceItem("", builder.ConnectionString));

//Set the data source key for the security tables

SecurityBasics.SecurityDataSourceKey = "";

 

Form Code:

MicroFour.StrataFrame.Security.SecurityDialog frm = new MicroFour.StrataFrame.Security.SecurityDialog();

frm.ShowDialog();

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 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 ).