I finally getting around to seeing how security works. It appears that I don't have it configured correctly to see the security tables, which are in a the StrataFrame db, which is on an instance of SQL Server 2005, while the app data is on the default instance, which is SQL Server 2000.



I setup a required datasource item with a key of 'security' for the security database and set the SecurityDataSourceKey='security'. However, I've obviously done something wrong, because it isn't finding my users. There is another required data source for my app data, with a blank key. This one is working, because when I login as admin, the app data is there.



What am I not getting?

Well, to give you a 100% positive confirmation on where you have gone wrong I would need to see your AppMain.vb file to look at your data sources and to verify that the security tables are in fact in the database you specified as 'Security'.  Generally you do not have to totally separate server connections talking to each piece of your application, though you can, this is just not the norm.  Secondly, the DDT (Database Deployment Toolkit) has an import feature to not only include the security data structures in your application database, but it will gather up all of your security data into a deployment package to ensure that it si deployed to your production environment.

The security tables in the StrataFrame database are not to be used within your production environment from that location.  These records are to be pulled out and then exported to your production databases.

So first, read the help documentation on the Deployment Package Wizard (DDT Help): Deployment Data Packages -> Deployment Package Wizard

This will get your security data into the proper database.  Doing this manually is more difficult.  Once you get your databases setup properly, and have created the deployment packages that will gather the proper security data you created through the Role-Based Security Editor....then you need to make sure your environment for your app is setup.

If you import the security tables into your default database within your application, then you do not need to setup another data source for security, it will just use the default.  In this scenario, get rid of your required database with the "Security" data source key.  Also, set the SecurityDataSourceKey property to an empty string ... this will tell security that your security tables are in the default application connection.

Here is the AppMain.vb file.



I understand that the security tables/data need to be deployed along with the app, however, I'm evaluating the product and just testing stuff. I assume you don't have to deploy the security stuff every time you hit F5 to run the app to debug it. Likely I'm missing something here.

You have to redeploy your security everytime to make a change, otherwise those changes will not be in your database.  That is why it is so important to use the DDT because all you have to do is click the "deploy to server" let it repackage and it will pull out your changes and dump them into your production server.  This is the best way...if you try using the security tables in the StrataFrame database, you are going to have problems the moment you create a second project. 

Try this approach first to see if you get your user issue resolved.  So remove the Security connection and just use the DDT to include your security tables and project data and then see if you have the same results.

Ugh...So, in order to test the security features, I have to now learn the DDT? I only have one project, I'm just seeing if the security will work for my app, which is hitting an existing database, which I assume I'll have to somehow get into DDT. Also, I'm working on a SQL Server 2000 database. Will the DDT work with SQL Server 2000?



I'm also confused. In the security documentation, it says







This seems not to be the case. It seems that what it means is that any time the application is run, the security data must be deployed (if it has changed since the last time the app was run in any case). If this is the case, you might want to update your help file.



Also, looking at the structure of the tables, the tables all have a project reference to the 'Security project primary key', and the table structure looks just like it does within the StrataFrame db, so I'm confused why the security tables in the StrataFrame db couldn't be used, or why more than one project would be a problem. It was my understanding that you could put your security in a separate database and then hit it from many apps.



Finally, I don't understand how the SF security app interacts with all of these databases. I've read the help file, but must not be getting it.



Yes, I'm confused



P.S. Sorry if I'm a bit snippy, I'm rapidly running out of time to evaluate SF (license expires today, though I've requested an extension), I haven't slept much in a couple of weeks now...

Yes, the DDT works with SQL Server 2000. 

Let's just go back to the beginning because I will have to write a novel through the forum to explain all of this and neither of us have that kind of time .  The help docs go through the security thoroughly and explain each piece.  But for now, just leave your connection the way it is and let's figure out why you cannot see the users.

Do this, leave your settings as you had them before.  Login with the Administrator user and password.  Within your application somewhere, call the security dialog:

Dim loForm As New SecurityDialog()

loForm.ShowDialog()

This is the editor used at run-time (it will look very familiar ).  Does the user you created appear within this editor?

OK, I did that, and it worked fine. My users, roles, permissions are all there.

That is the security dialog works fine...still can't login as one of these users.

But when you try to login with a user that is in your database, it does not authenticate?

Could you package up your SQL database and project...I think that is the only way I am going to be able to get a handle on what you are seeing.