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] "Glen Moffitt" <gd.moffitt@verizon.net> wrote in message
news:4c01f458.0309131004.38dd196c@posting.google.com...
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..