Groups | Blog | Home
all groups > sql server replication > september 2003 >

sql server replication : Replication of table permissions and column settings


gd.moffitt NO[at]SPAM verizon.net
9/13/2003 11:04:47 AM
A recent test of an application we use against a copy of the SQL
Server 2000 database at a remote site turned up some issues with lack
of replication of table permissions and some table column settings.

The Public SQL group has certain permissions to some tables on the
production system. These permissions were not being replicated.
Also, in spot-checking some tables, while certain column settings were
replicated (such as data type, and whether nulls were allowed), other
settings, such as default values were not. So..when the user tried to
create a new record in the remote replicated system, errors occured
because the field (correctly) did not allow nulls, but (incorrectly)
there was no setting for a default value.

Is there some setting I'm missing in the replication setup? The only
thing I could see that might be a possibility was I did not have the
correct settings in the snapshot article? In the Default Table
Article Properties I have:
1) Drop the existing table and re-create it
2) For copy objects to destination I have only clustered &
non-clustered indexes checked, and convert user-defined to base data
type.

What setting should I change/add/drop to get the permissions and
column properties to properly replicate?

Glen Moffitt
9/13/2003 12:33:34 PM
Vyas,
thanks for the info. This system has four databases with
frequent table creations and deletions. Perhaps using MS
Replication is not the right thing in this
circumstance..However I was expecting the table properties
would be replicated in whole, not just half-way. Was
going by the MSDB library book for replication, which
talked about publishing tables, "When you publish these
objects, their definitions are copied to Subscribers.
When you add or drop columns to a publication database,
those changes to the definitions of the objects will be
propagated to Subscribers".

Does anyone have recommendations for a third-party tool
that could handle this scenario better (i.e.,
automatically replicate tables with all property changes,
and new objects such as tables)?
[quoted text, click to view]
Narayana Vyas Kondreddi
9/13/2003 7:37:54 PM
for this reason, replication is not really meant for the scenario you are
using it it. If you want a complete copy of the database on the remote
server, why not backup and restore it on the remote server. Then you could
use replication to just transfer the data.

--
HTH,
Vyas, MVP (SQL Server)
http://vyaskn.tripod.com/
What hardware is your SQL Server running on?
http://vyaskn.tripod.com/poll.htm




[quoted text, click to view]
A recent test of an application we use against a copy of the SQL
Server 2000 database at a remote site turned up some issues with lack
of replication of table permissions and some table column settings.

The Public SQL group has certain permissions to some tables on the
production system. These permissions were not being replicated.
Also, in spot-checking some tables, while certain column settings were
replicated (such as data type, and whether nulls were allowed), other
settings, such as default values were not. So..when the user tried to
create a new record in the remote replicated system, errors occured
because the field (correctly) did not allow nulls, but (incorrectly)
there was no setting for a default value.

Is there some setting I'm missing in the replication setup? The only
thing I could see that might be a possibility was I did not have the
correct settings in the snapshot article? In the Default Table
Article Properties I have:
1) Drop the existing table and re-create it
2) For copy objects to destination I have only clustered &
non-clustered indexes checked, and convert user-defined to base data
type.

What setting should I change/add/drop to get the permissions and
column properties to properly replicate?

TIA..

AddThis Social Bookmark Button