Deploying Security Data Without the DDT...


Author
Message
StarkMike
StarkMike
Advanced StrataFrame User (542 reputation)Advanced StrataFrame User (542 reputation)Advanced StrataFrame User (542 reputation)Advanced StrataFrame User (542 reputation)Advanced StrataFrame User (542 reputation)Advanced StrataFrame User (542 reputation)Advanced StrataFrame User (542 reputation)Advanced StrataFrame User (542 reputation)Advanced StrataFrame User (542 reputation)
Group: Forum Members
Posts: 436, Visits: 944
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

StrataFrame Team
S
StrataFrame Developer (4.7K reputation)StrataFrame Developer (4.7K reputation)StrataFrame Developer (4.7K reputation)StrataFrame Developer (4.7K reputation)StrataFrame Developer (4.7K reputation)StrataFrame Developer (4.7K reputation)StrataFrame Developer (4.7K reputation)StrataFrame Developer (4.7K reputation)StrataFrame Developer (4.7K reputation)
Group: StrataFrame Developers
Posts: 3K, Visits: 2.5K
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.

StarkMike
StarkMike
Advanced StrataFrame User (542 reputation)Advanced StrataFrame User (542 reputation)Advanced StrataFrame User (542 reputation)Advanced StrataFrame User (542 reputation)Advanced StrataFrame User (542 reputation)Advanced StrataFrame User (542 reputation)Advanced StrataFrame User (542 reputation)Advanced StrataFrame User (542 reputation)Advanced StrataFrame User (542 reputation)
Group: Forum Members
Posts: 436, Visits: 944
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. Wink
StrataFrame Team
S
StrataFrame Developer (4.7K reputation)StrataFrame Developer (4.7K reputation)StrataFrame Developer (4.7K reputation)StrataFrame Developer (4.7K reputation)StrataFrame Developer (4.7K reputation)StrataFrame Developer (4.7K reputation)StrataFrame Developer (4.7K reputation)StrataFrame Developer (4.7K reputation)StrataFrame Developer (4.7K reputation)
Group: StrataFrame Developers
Posts: 3K, Visits: 2.5K
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 Smile
GO

Merge Selected

Merge into selected topic...



Merge into merge target...



Merge into a specific topic ID...




Similar Topics

Reading This Topic

Login

Explore
Messages
Mentions
Search