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

Hi Trent,

Yes, I understand why the permissions are not available to add/edit to the end user.  However, I am trying to setup the initial permissions in the security tables in my database during my development.  I added the (true, true) parameter values.  It still does not allow me to add/edit the permissions!?!? 

Also, the other reason why I need this ability is I am going to need to be able to allow an administrator to add permissions for future updates of the software at a remote site.  How does other developers handle adding permissions to their databases once the app and database has been deployed?

Thanks,

Jeff

Are you going into the Security Editor through Visual Studio?

1. Open Visual Studio
   
2. Click StrataFrame -> Role Based Security Editor

If you are not working off of a project then the permissions can't be shown.  The only way to work off of a project in this case to add permissions is through VS.

OK.  Then how do I point the IDE RBS Editor to the security tables in my database instead in the Strataframe database?

Jeff

Jeff,

How are you developing?  It is generally not a good idea to work off of your production or distribution database. The easiest and best way is to let the DDT do it for you.  It will package up all of your security tables and deploy them to your production environment.  There is a wizard that will create the deployment data packages for you and then deploy them to your production environment.  This also provides you with a distribution mechanism.  Even if you are writing an internal application, you will still want to work this way.  If you don't want to use the DDT, then you will want to do what the DDT does for you and extract them from the Security tables in the StrataFrame database and import them into your production database.  Using the DDT does this for you in seconds though, so it is really the route you will want to take.

I have not deployed the production database yet.  I am still working on the developing the database.  However, I have not used the DDT.  So what you are saying is once I develop my production database then I can add the security tables and their records from the Strataframe database to my production database using the DDT, correct?  What if I have two or more projects in the RBS Editor system for different development applications I am working on.  Will the DDT enable me to deploy the security tables and only the records associated with the security project which is setup for the application I am deploying? 

Jeff

Working backwards, if you have two projects then you need to create 2 security projects.  Once for each, so if you set this up correctly, then yes, you can distinguish between each project and deploy them appropriately.  When you create the permissions, then you just pop over to the DDT, repackage, then deploy data only (after the tables have been created) to update your database with the appropriate permissions.