Unfortunately, no, we don't allow you to manage the permissions from "your" SFS tables because the users shouldn't be allowed to modify the permissions at runtime... little caveat there

Ah, I get it. I guess I wasnt thinking. I assumed when I ran that script that I could manage the permissions at design-time.

The SFSProjects table is not needed at runtime... neither are the foreign keys that tie the SFSProjects table to SFSUsers, SFSRoles, SFSPermissions, SFSRestrictionSets, and SFSPreferences.  The SFSProjects is only needed at design-time for the security editor to keep the groups of objects together based on a "project."  That's why the security script did not include the SFSProjects table. 

As for copying records from one table to another, that's perfectly fine... just make sure you turn IDENTITY_INSERT ON so that you can manually specify the primary key for the records... otherwise, the foreign keys will be broken.

The script you included to create the RBS Security tables in another database is missing the SFSProjects table in it... I tried to copy the SFSProjects table into my destination database but that didnt work.

Also, If i've created data in the default SFS tables in the StrataFrame database can I simply copy them across to my new tables or will that be a violation of either the primary or foreign keys?

Thanks