Hello, I have a database and I need to copy and attach it in a customer SQL
server. But I don't want them to be able to see the tables structures or my
company's stored procedures. Is this possible to have the database in their
sql server and not allow them to see the data or tables. Or only with a
password be able to access the database. Like in Microsoft Access that you
can assign a password to the database and everytime I open the file it
prompts for the password.
Thanks in advance
JennyferdYou can "encrypt" the stored procedures (see BOL, Create Procedure "With
Encryption"), but there are tools out there that pretty handily defeat such
encryption. It's pretty much just enough to keep unmotivated honest people
honest. You could use Views to prevent people from accessing the underlying
tables directly, but on their box they will presumably have sa/administrator
access and will be able to view your table structures... I'm not sure of
any methods to hide that info... Although someone else here may know.
To be honest, to me it's a little counter-intuitive - I usually supply full
documentation on the database tables and structures to clients, since they
invariably try to generate reports, etc., on their own... to me it makes
more sense to give them the tools to access it the right way, set up
read-only views, etc., so they don't trash the system...
"Jennyfer J Barco" <pdwhitt@.nospam.wdsinc.com> wrote in message
news:uTp4scxLFHA.3420@.tk2msftngp13.phx.gbl...
> Hello, I have a database and I need to copy and attach it in a customer
> SQL
> server. But I don't want them to be able to see the tables structures or
> my
> company's stored procedures. Is this possible to have the database in
> their
> sql server and not allow them to see the data or tables. Or only with a
> password be able to access the database. Like in Microsoft Access that you
> can assign a password to the database and everytime I open the file it
> prompts for the password.
> Thanks in advance
> Jennyferd
>
Showing posts with label customer. Show all posts
Showing posts with label customer. Show all posts
Sunday, March 11, 2012
Sunday, February 12, 2012
about foreign key conflicts in merge replication
PLS HELP ME. SOS!
Our customer has two fatctories and a marketing center with long distance.
So we have to syncronize data through sql server replication. Because both
publisher and subscriber can modify data, we use merge replication. But when
we tested, foreign key conflicts occured even we only modified data from
subscriber side.
Pls help me, thanks a lot.
Titanicliu,
in merge replication, it can be the case that parent and child generations
are in separate generation batches.
To avoid the error you could set the foreign key to have the NOT FOR
REPLICATION attribute.
You can also increase the -UploadGenerationsPerBatch and
the -DownloadGenerationsPerBatch parameters to their max of 2000 to 'ensure'
the PK and FK rows are processed together.
HTH,
Paul Ibison
|||Hi,Paul
Thanks for your kindly help. I will try it. Thanks again!
BR,
Titanicliu
"Paul Ibison" wrote:
> Titanicliu,
> in merge replication, it can be the case that parent and child generations
> are in separate generation batches.
> To avoid the error you could set the foreign key to have the NOT FOR
> REPLICATION attribute.
> You can also increase the -UploadGenerationsPerBatch and
> the -DownloadGenerationsPerBatch parameters to their max of 2000 to 'ensure'
> the PK and FK rows are processed together.
> HTH,
> Paul Ibison
>
>
Our customer has two fatctories and a marketing center with long distance.
So we have to syncronize data through sql server replication. Because both
publisher and subscriber can modify data, we use merge replication. But when
we tested, foreign key conflicts occured even we only modified data from
subscriber side.
Pls help me, thanks a lot.
Titanicliu,
in merge replication, it can be the case that parent and child generations
are in separate generation batches.
To avoid the error you could set the foreign key to have the NOT FOR
REPLICATION attribute.
You can also increase the -UploadGenerationsPerBatch and
the -DownloadGenerationsPerBatch parameters to their max of 2000 to 'ensure'
the PK and FK rows are processed together.
HTH,
Paul Ibison
|||Hi,Paul
Thanks for your kindly help. I will try it. Thanks again!
BR,
Titanicliu
"Paul Ibison" wrote:
> Titanicliu,
> in merge replication, it can be the case that parent and child generations
> are in separate generation batches.
> To avoid the error you could set the foreign key to have the NOT FOR
> REPLICATION attribute.
> You can also increase the -UploadGenerationsPerBatch and
> the -DownloadGenerationsPerBatch parameters to their max of 2000 to 'ensure'
> the PK and FK rows are processed together.
> HTH,
> Paul Ibison
>
>
Subscribe to:
Comments (Atom)