InstantForum 2017-1 FinalStrataFrame Forumhttp://forum.strataframe.net/StrataFrame ForumTue, 09 Jun 2026 17:02:14 GMT20http://forum.strataframe.net/FindPost4919.aspxThe 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.</P><P>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?</P><P>ThanksMon, 04 Dec 2006 14:10:32 GMTStarkMikehttp://forum.strataframe.net/FindPost4935.aspxUnfortunately, 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 :)Mon, 04 Dec 2006 14:10:32 GMTStrataFrame Teamhttp://forum.strataframe.net/FindPost4934.aspxAh, I get it. I guess I wasnt thinking. I assumed when I ran that script that I could manage the permissions at design-time. ;)Mon, 04 Dec 2006 14:08:35 GMTStarkMikehttp://forum.strataframe.net/FindPost4931.aspxThe SFSProjects table is not needed at runtime... neither are the foreign keys that tie the SFSProjects table to SFSUsers, SFSRoles, SFSPermissions, SFSRestrictionSets, and SFSPreferences.&nbsp; The SFSProjects is only needed at design-time for the security editor to keep the groups of objects together based on a "project."&nbsp; That's why the security script did not include the SFSProjects table.&nbsp;</P><P>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.Mon, 04 Dec 2006 13:55:00 GMTStrataFrame Team