When you get back to it you make make it more simple.  The SFS tables and the SFS views that are in your StrataFrame database are required for your application (minus the SFSprojects table).  But other than that they will be identical.  So if you are not using the DDT, you can have SSMS create the scripts for you and then deploy them that way.  I will be sure to update the help docs with the manual scripts.  Most people use the DDT....including us.  We too have a very deep understanding of SQL Server, this is not the point of the DDT.  The DDT is designed for deployment and making deployment much easier.  This is why the DDT has a wizard that allows you to just click which RBS project you are using, and it will bring in all of the data for your security project.  If you do this manually, well, it is going to be much hard to distribute your permissions, etc.  It doesn't mean that it is not possible, it just requires more elbow grease.

But I know what you mean about staying on schedule.  When you start back up, start with the RBS sample, it might speed things up since you are a strong developer and a sample may be all that you need.

Hi Trent.

I really appreciate all the help you and all the others here have given me to help me get up to speed on the framework. What I am thinking is that when I get back to retrofitting this application after go live, I may just move all the RBS tables into the application and set everything up using the app. Would that work?

If you only plan to have one RBS application, then that would work.  But as soon as you were to create your second application, then you would have a problem. 

OK. Then I will handle thos in the VS IDE and export the data to the tables in the app

Thanks again

That would be the safest way to go.