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

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