Copy Permissions

Hi,
I've copied tables and views from one SQL Server to another, but the
permissions for each user/role are not copied.
How come.
Thanks,
B.Bart
--
EXEC databasename..sp_helpuser 'username'
SELECT OBJECT_NAME(id),*
FROM databasename..syspermissions
WHERE grantee=USER_ID('username')
If you use BACKUP/RESTORE command to copy your tables/views so please
search on internet for "sp_help_revlogin" two stored procedures provided by
MS to copy logins beween SQL Servers
"Bart Steur" <solnews@.xs4all.nl> wrote in message
news:OtwLA6myFHA.460@.TK2MSFTNGP15.phx.gbl...
> Hi,
> I've copied tables and views from one SQL Server to another, but the
> permissions for each user/role are not copied.
> How come.
> Thanks,
> B.
>

Copy Permissions

Hi,
I've copied tables and views from one SQL Server to another, but the
permissions for each user/role are not copied.
How come.
Thanks,
B.
Bart
EXEC databasename..sp_helpuser 'username'
SELECT OBJECT_NAME(id),*
FROM databasename..syspermissions
WHERE grantee=USER_ID('username')
If you use BACKUP/RESTORE command to copy your tables/views so please
search on internet for "sp_help_revlogin" two stored procedures provided by
MS to copy logins beween SQL Servers
"Bart Steur" <solnews@.xs4all.nl> wrote in message
news:OtwLA6myFHA.460@.TK2MSFTNGP15.phx.gbl...
> Hi,
> I've copied tables and views from one SQL Server to another, but the
> permissions for each user/role are not copied.
> How come.
> Thanks,
> B.
>

Copy objects Wizard - deleted data??

I have not used the copy objects wizard that much. I used it today to copy 4
views from my dev box to production. It copied the views, but also wiped out
my data in all the tables that the views are built around!!! In
production!!!!

Can someone provide me some insight into why this happened?

Thanks,
ChadChad Richardson (chad@.NIXSPAM_chadrichardson.com) writes:
> I have not used the copy objects wizard that much. I used it today to
> copy 4 views from my dev box to production. It copied the views, but
> also wiped out my data in all the tables that the views are built
> around!!! In production!!!!
> Can someone provide me some insight into why this happened?

Extremely nasty. I have not used the wizard in question myself, and I
think you understand why after this experience. It's a bit ironic: the
wizards are there to help, but you can only use them, if you know
exactly what they do, and in such case you may not need them.

Anyway my guess is that the wizard saw reason to recreate the underlying
tables as well; possibly because the defintion in production was different
from your dev box.

The correct way to deploy things in production is through change scripts
that are created from information in the version-control system.

--
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techin.../2000/books.asp|||Yes, very nasty. Luckily my hosting company (ReadyHosting) was able to
restore everything from their backup and the transaction logs.

Normally, whenever I make DB table changes I save the scripts and put them
in a "To Promote to Prod" directory, then use SQL Analyzer to apply those
changes to prod. But changes to views don't prompt for you to save these
changes as a script.

What specifically do you mean by "the version control system"? (As you can
tell by my question, I know just enough of SQL Server to be dangerous, so
any insight on how to handle version contol is appreciated.)

Thanks,
Chad

"Erland Sommarskog" <esquel@.sommarskog.se> wrote in message
news:Xns9682EF2F57F5DYazorman@.127.0.0.1...
> Chad Richardson (chad@.NIXSPAM_chadrichardson.com) writes:
>> I have not used the copy objects wizard that much. I used it today to
>> copy 4 views from my dev box to production. It copied the views, but
>> also wiped out my data in all the tables that the views are built
>> around!!! In production!!!!
>>
>> Can someone provide me some insight into why this happened?
> Extremely nasty. I have not used the wizard in question myself, and I
> think you understand why after this experience. It's a bit ironic: the
> wizards are there to help, but you can only use them, if you know
> exactly what they do, and in such case you may not need them.
> Anyway my guess is that the wizard saw reason to recreate the underlying
> tables as well; possibly because the defintion in production was different
> from your dev box.
> The correct way to deploy things in production is through change scripts
> that are created from information in the version-control system.
>
> --
> Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
> Books Online for SQL Server SP3 at
> http://www.microsoft.com/sql/techin.../2000/books.asp|||Chad Richardson (chad@.NIXSPAM_chadrichardson.com) writes:
> Yes, very nasty. Luckily my hosting company (ReadyHosting) was able to
> restore everything from their backup and the transaction logs.
> Normally, whenever I make DB table changes I save the scripts and put them
> in a "To Promote to Prod" directory, then use SQL Analyzer to apply those
> changes to prod. But changes to views don't prompt for you to save these
> changes as a script.
> What specifically do you mean by "the version control system"? (As you can
> tell by my question, I know just enough of SQL Server to be dangerous, so
> any insight on how to handle version contol is appreciated.)

"version control system" or "source code control" is nothing specific
to SQL Server, but fundamentals of software engineering. In a version
control system, developers adds their files. Later a file may be
checked out, maybe by the same developer, maybe by someone else. The
person who checked out the file, performs some changes to it, and
then checks back in again, after proper testing.

When it's getting time to make a build for an integration test, someone
who is a "build master", "configuration manager" or similar puts some
label on all the most recent versions of files, to create a baseline.
During tests, bugs may be uncovered and fixed. The fixes can be inserted
into that baseline, or a new baseline be created.

Eventually, the thing is put into production and a baseline is created for
this. Now, development of 2.0 starts. However, there may be need to
fix bugs in production as well. Say that version 12 of file foo.cs
was in the shipment baseline. By the time a critical bug in production
is discovered, the file at version 14 for 2.0 development. But you
check out version 12, and fix that, and check it in as 12.1 - you
have now created a branch.

The exact terminology for these various actions are different from
product to product. The most commonly used version-control system
in the Microsoft world is Visual SourceSafe. It performs branching
different that about any other product. VSS has a lot of short-comings
as a version-control system, but it's easy to start with, and it's OK
for smaller teams.
--
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techin.../2000/books.asp|||For a tool that links the drop/create scripts (for ALL database
objects) in any source control system to your development, test and
production databases have a look at DB Ghost (www.dbghost.com).

The approach is to regard the drop/create scripts as the only true
representation of the desired schema i.e. your 'source database'. Once
you have modifed the drop/create scripts DB Ghost will build a brand
new database from them in an extremely fast manner whilst taking care
of any dependencies. This a) verifies that no syntax or dependency
errors have been introduced and b) gives you a real source database to
use as the basis for a compare and upgrade of your actual target i.e.
the test or production database. DB Ghost does this also and creates a
rock solid delta script of the differences that is guaranteed to work
with no hand coded modifications.

What you end up with is a target database that matches a (labelled) set
of scripts under source control. If this approach is used for all
releases then a full audit trail of who changed what, why and when is
maintained in the source control system so it is easy to do reports
such as 'what changed between release X and release Y' or 'who first
changed sproc Z after release X'.

Relying on comments in sprocs etc. is a recipe for disaster in all but
the most disciplined of IT shops. Let your source control system do
the hard work for you and let DB Ghost handle all the SQL Server code.
It's called the DB Ghost Process and it can bring an amazing level of
quality to your deployments and code control in general.|||Erland,

Thanks for the explanation. I do have experience with source control tools
such as VSS and PVCS, but all have been for file/directory based source,
like VB. How do DB developers apply these principles (check in, check out,
etc.) to SQL Server? This is something I've curious about for a while now.

Thanks,
Chad

"Erland Sommarskog" <esquel@.sommarskog.se> wrote in message
news:Xns96833C7C3BFCYazorman@.127.0.0.1...
> Chad Richardson (chad@.NIXSPAM_chadrichardson.com) writes:
>> Yes, very nasty. Luckily my hosting company (ReadyHosting) was able to
>> restore everything from their backup and the transaction logs.
>>
>> Normally, whenever I make DB table changes I save the scripts and put
>> them
>> in a "To Promote to Prod" directory, then use SQL Analyzer to apply those
>> changes to prod. But changes to views don't prompt for you to save these
>> changes as a script.
>>
>> What specifically do you mean by "the version control system"? (As you
>> can
>> tell by my question, I know just enough of SQL Server to be dangerous, so
>> any insight on how to handle version contol is appreciated.)
> "version control system" or "source code control" is nothing specific
> to SQL Server, but fundamentals of software engineering. In a version
> control system, developers adds their files. Later a file may be
> checked out, maybe by the same developer, maybe by someone else. The
> person who checked out the file, performs some changes to it, and
> then checks back in again, after proper testing.
> When it's getting time to make a build for an integration test, someone
> who is a "build master", "configuration manager" or similar puts some
> label on all the most recent versions of files, to create a baseline.
> During tests, bugs may be uncovered and fixed. The fixes can be inserted
> into that baseline, or a new baseline be created.
> Eventually, the thing is put into production and a baseline is created for
> this. Now, development of 2.0 starts. However, there may be need to
> fix bugs in production as well. Say that version 12 of file foo.cs
> was in the shipment baseline. By the time a critical bug in production
> is discovered, the file at version 14 for 2.0 development. But you
> check out version 12, and fix that, and check it in as 12.1 - you
> have now created a branch.
> The exact terminology for these various actions are different from
> product to product. The most commonly used version-control system
> in the Microsoft world is Visual SourceSafe. It performs branching
> different that about any other product. VSS has a lot of short-comings
> as a version-control system, but it's easy to start with, and it's OK
> for smaller teams.
> --
> Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
> Books Online for SQL Server SP3 at
> http://www.microsoft.com/sql/techin.../2000/books.asp|||Chad Richardson (chad@.NIXSPAM_chadrichardson.com) writes:
> Thanks for the explanation. I do have experience with source control tools
> such as VSS and PVCS, but all have been for file/directory based source,
> like VB. How do DB developers apply these principles (check in, check out,
> etc.) to SQL Server? This is something I've curious about for a while now.

They use - or at least should use - files. I've seen a whole lot of
questions on version control of SQL objects as this should be something
difficult or special. It isn't. Source code is source code, and should be
handled as such.

I guess people are tricked by tools that permit you to store things in the
database directly, point-and-click GUI:n for creating tables etc. But all
of that is really files.

The one gotcha there is if you use a tool like Query Analyzer for editing
your SQL objects, is that you disrupt the normal procedure which is
1) check out 2) edit 3) save 4) compile 5) test 6) back to 2 until it
works 7) check in. With a tool like QA, 3 is taken out of the chain, which
can lead to that what you check is not what you tested.

In our shop, we avoid this problem by using a third-party editor, Textpad.
It has no special features for SQL - but it is a better editor than QA.
From Textpad 3 and 4 is one key-click, as we can activate a command-line
from Textpad. We have our own load tool for quite a few bells and whistles,
but the tool could be command-line OSQL.

The thing people seem to want to do, is to take the SQL objects from
the database, but this is actually really wrong when you think of it.
If you work in VB, would get the input for the version-control system
by disassembling the object modules?

--
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techin.../2000/books.asp

Copy Database or Database Restore

Hi,

I am restoring one of my database from test box to production box. I don't have all the logins defined(users for copied database) in production box, What happen if user tries to access the database. I guess they will not be able as user is defined but there is no matching logins.

Will Copy Database wizard creates all logins as Restore Database does not?

Thanks

No. When you copy the database as well as when you restore the database, you only get the database. The logins have to be copied over separately. This can be done with a copy logins tasks in SSIS. Then once the logins are moved, you can remap the users to teh logins using sp_change_userslogin.

Copy database AND users in automated way?

With 2005 (although the answer is probably the same for 2000):
I want to have BAK files copied to another server, the other server import
that copy of the database, and the other server be available for
testing/development purposes with current data. The problem is the user
records.
I know how to use TSQL to make a backup BAK file of a database. I know how
to restore that file onto another server (dev server) with TSQL. So far so
good. The problem is that the backup copy of the database imports in with
bad user records that don't really exist on the new server. Even if the
same user names exist, the record ID don't point at each other. As you may
know, you have to do an sp_dropuser on those "not aligned properly" records,
and then manually add back the users to the Development SQL Server, and then
add those users to the dev database copy. But I do this user stuff through
the GUI and not through TSQL and I need a way to have the BAK files copy
over and start working automatically. I could probably add the user to the
server through TSQL and add the user to a the database, with a specified
role, but 1) I don't know that TSQL (please tell me) and 2) I don't want
to have TSQL lying around on the server with user passwords in it.
Anyone know a good solution to this problem? Ideally I would like to run
some TSQL that will line up the record IDs for the users in the database
copy to users I place into the server one time only and that way I don't
have to enter passwords more than once.
Take a look at sp_help_revlogin. It allows you to extract the credentials
from the source server and apply them to the target.
http://support.microsoft.com/kb/246133
-oj
"HK" <replywithingroup@.notreal.com> wrote in message
news:1EoVf.12036$w86.3511@.tornado.socal.rr.com...
> With 2005 (although the answer is probably the same for 2000):
> I want to have BAK files copied to another server, the other server import
> that copy of the database, and the other server be available for
> testing/development purposes with current data. The problem is the user
> records.
> I know how to use TSQL to make a backup BAK file of a database. I know
> how
> to restore that file onto another server (dev server) with TSQL. So far
> so
> good. The problem is that the backup copy of the database imports in
> with
> bad user records that don't really exist on the new server. Even if the
> same user names exist, the record ID don't point at each other. As you
> may
> know, you have to do an sp_dropuser on those "not aligned properly"
> records,
> and then manually add back the users to the Development SQL Server, and
> then
> add those users to the dev database copy. But I do this user stuff
> through
> the GUI and not through TSQL and I need a way to have the BAK files copy
> over and start working automatically. I could probably add the user to
> the
> server through TSQL and add the user to a the database, with a specified
> role, but 1) I don't know that TSQL (please tell me) and 2) I don't
> want
> to have TSQL lying around on the server with user passwords in it.
> Anyone know a good solution to this problem? Ideally I would like to run
> some TSQL that will line up the record IDs for the users in the database
> copy to users I place into the server one time only and that way I don't
> have to enter passwords more than once.
>

Copy database AND users in automated way?

With 2005 (although the answer is probably the same for 2000):
I want to have BAK files copied to another server, the other server import
that copy of the database, and the other server be available for
testing/development purposes with current data. The problem is the user
records.
I know how to use TSQL to make a backup BAK file of a database. I know how
to restore that file onto another server (dev server) with TSQL. So far so
good. The problem is that the backup copy of the database imports in with
bad user records that don't really exist on the new server. Even if the
same user names exist, the record ID don't point at each other. As you may
know, you have to do an sp_dropuser on those "not aligned properly" records,
and then manually add back the users to the Development SQL Server, and then
add those users to the dev database copy. But I do this user stuff through
the GUI and not through TSQL and I need a way to have the BAK files copy
over and start working automatically. I could probably add the user to the
server through TSQL and add the user to a the database, with a specified
role, but 1) I don't know that TSQL (please tell me) and 2) I don't want
to have TSQL lying around on the server with user passwords in it.
Anyone know a good solution to this problem? Ideally I would like to run
some TSQL that will line up the record IDs for the users in the database
copy to users I place into the server one time only and that way I don't
have to enter passwords more than once.Take a look at sp_help_revlogin. It allows you to extract the credentials
from the source server and apply them to the target.
http://support.microsoft.com/kb/246133
--
-oj
"HK" <replywithingroup@.notreal.com> wrote in message
news:1EoVf.12036$w86.3511@.tornado.socal.rr.com...
> With 2005 (although the answer is probably the same for 2000):
> I want to have BAK files copied to another server, the other server import
> that copy of the database, and the other server be available for
> testing/development purposes with current data. The problem is the user
> records.
> I know how to use TSQL to make a backup BAK file of a database. I know
> how
> to restore that file onto another server (dev server) with TSQL. So far
> so
> good. The problem is that the backup copy of the database imports in
> with
> bad user records that don't really exist on the new server. Even if the
> same user names exist, the record ID don't point at each other. As you
> may
> know, you have to do an sp_dropuser on those "not aligned properly"
> records,
> and then manually add back the users to the Development SQL Server, and
> then
> add those users to the dev database copy. But I do this user stuff
> through
> the GUI and not through TSQL and I need a way to have the BAK files copy
> over and start working automatically. I could probably add the user to
> the
> server through TSQL and add the user to a the database, with a specified
> role, but 1) I don't know that TSQL (please tell me) and 2) I don't
> want
> to have TSQL lying around on the server with user passwords in it.
> Anyone know a good solution to this problem? Ideally I would like to run
> some TSQL that will line up the record IDs for the users in the database
> copy to users I place into the server one time only and that way I don't
> have to enter passwords more than once.
>

Copy database AND users in automated way?

With 2005 (although the answer is probably the same for 2000):
I want to have BAK files copied to another server, the other server import
that copy of the database, and the other server be available for
testing/development purposes with current data. The problem is the user
records.
I know how to use TSQL to make a backup BAK file of a database. I know how
to restore that file onto another server (dev server) with TSQL. So far so
good. The problem is that the backup copy of the database imports in with
bad user records that don't really exist on the new server. Even if the
same user names exist, the record ID don't point at each other. As you may
know, you have to do an sp_dropuser on those "not aligned properly" records,
and then manually add back the users to the Development SQL Server, and then
add those users to the dev database copy. But I do this user stuff through
the GUI and not through TSQL and I need a way to have the BAK files copy
over and start working automatically. I could probably add the user to the
server through TSQL and add the user to a the database, with a specified
role, but 1) I don't know that TSQL (please tell me) and 2) I don't want
to have TSQL lying around on the server with user passwords in it.
Anyone know a good solution to this problem? Ideally I would like to run
some TSQL that will line up the record IDs for the users in the database
copy to users I place into the server one time only and that way I don't
have to enter passwords more than once.Take a look at sp_help_revlogin. It allows you to extract the credentials
from the source server and apply them to the target.
http://support.microsoft.com/kb/246133
-oj
"HK" <replywithingroup@.notreal.com> wrote in message
news:1EoVf.12036$w86.3511@.tornado.socal.rr.com...
> With 2005 (although the answer is probably the same for 2000):
> I want to have BAK files copied to another server, the other server import
> that copy of the database, and the other server be available for
> testing/development purposes with current data. The problem is the user
> records.
> I know how to use TSQL to make a backup BAK file of a database. I know
> how
> to restore that file onto another server (dev server) with TSQL. So far
> so
> good. The problem is that the backup copy of the database imports in
> with
> bad user records that don't really exist on the new server. Even if the
> same user names exist, the record ID don't point at each other. As you
> may
> know, you have to do an sp_dropuser on those "not aligned properly"
> records,
> and then manually add back the users to the Development SQL Server, and
> then
> add those users to the dev database copy. But I do this user stuff
> through
> the GUI and not through TSQL and I need a way to have the BAK files copy
> over and start working automatically. I could probably add the user to
> the
> server through TSQL and add the user to a the database, with a specified
> role, but 1) I don't know that TSQL (please tell me) and 2) I don't
> want
> to have TSQL lying around on the server with user passwords in it.
> Anyone know a good solution to this problem? Ideally I would like to run
> some TSQL that will line up the record IDs for the users in the database
> copy to users I place into the server one time only and that way I don't
> have to enter passwords more than once.
>

copy database

I have copied a Database from one server to another server by detaching and attaching.Everything looks fine but i didn't get the logins associated with the DB onto new server.
How can i get those logins into the database on new server.
Thanks.Search this forum and www.sqlteam.com for sp_help_revlogin. You can run that script and it will produce all the logins with the correct SIDs.|||where should i run this script?on the source server or destination server?|||Run it on the source server. It will give you a permissions script to run on the destination server.

COpy Database

I ran the copy database wizard to set up a job to copy three dbs from one
server to another. The job copied two of the db's but not the third one.
It is possible that there was an open connection to that db. Will that
prevent a copy from executing? Also, it appears that this process is
accomplished by detaching the dbs as when I came in the two databases that
were copied were not reattached on the main server. Would the failure to
copy the other db prevent the reattach from executing?
Barry
looks like it didn't finishing attaching dbs. copy db wizard does detach and
attach the database. That's why I usually don't like to use it.
<barryfz@.home.com> wrote in message
news:ubR8Y%23zlEHA.396@.tk2msftngp13.phx.gbl...
> I ran the copy database wizard to set up a job to copy three dbs from one
> server to another. The job copied two of the db's but not the third one.
> It is possible that there was an open connection to that db. Will that
> prevent a copy from executing? Also, it appears that this process is
> accomplished by detaching the dbs as when I came in the two databases that
> were copied were not reattached on the main server. Would the failure to
> copy the other db prevent the reattach from executing?
> Barry
>
|||Hi Barry,
From your descriptions, I understood that your Copy Database Wizard failed
to transfer the third database while the first two succeed. Have I
understood you? If there is anything I misunderstood, please feel free to
let me know.
Based on my scope, to avoid data loss or inconsistency, you must be sure
there are no active sessions attached to the database being moved or
copied. If there are active sessions, the Copy Database Wizard will not
run. You could also find the descriptions above in BOL, Using the Copy
Database Wizard. Which is to say it is entirely possible the active session
in your third database lead to that copy failure.
Additionaly, here are some documents for you on how to transfer databases
between SQL Servers.
Moving SQL Server databases to a new location with Detach/Attach
http://support.microsoft.com/default...b;EN-US;224071
HOW TO: Move Databases Between Computers That Are Running SQL Server
http://support.microsoft.com/default...B;en-us;314546
Thank you for your patience and cooperation. If you have any questions or
concerns, don't hesitate to let me know. We are here to be of assistance!
Sincerely yours,
Mingqing Cheng
Online Partner Support Specialist
Partner Support Group
Microsoft Global Technical Support Center
Introduction to Yukon! - http://www.microsoft.com/sql/yukon
This posting is provided "as is" with no warranties and confers no rights.
Please reply to newsgroups only, many thanks!
|||Hi Barry,
I wanted to post a quick note to see if you would like additional
assistance or information regarding this particular issue. We appreciate
your patience and look forward to hearing from you!
Sincerely yours,
Mingqing Cheng
Online Partner Support Specialist
Partner Support Group
Microsoft Global Technical Support Center
Introduction to Yukon! - http://www.microsoft.com/sql/yukon
This posting is provided "as is" with no warranties and confers no rights.
Please reply to newsgroups only, many thanks!

COpy Database

I ran the copy database wizard to set up a job to copy three dbs from one
server to another. The job copied two of the db's but not the third one.
It is possible that there was an open connection to that db. Will that
prevent a copy from executing? Also, it appears that this process is
accomplished by detaching the dbs as when I came in the two databases that
were copied were not reattached on the main server. Would the failure to
copy the other db prevent the reattach from executing'
Barrylooks like it didn't finishing attaching dbs. copy db wizard does detach and
attach the database. That's why I usually don't like to use it.
<barryfz@.home.com> wrote in message
news:ubR8Y%23zlEHA.396@.tk2msftngp13.phx.gbl...
> I ran the copy database wizard to set up a job to copy three dbs from one
> server to another. The job copied two of the db's but not the third one.
> It is possible that there was an open connection to that db. Will that
> prevent a copy from executing? Also, it appears that this process is
> accomplished by detaching the dbs as when I came in the two databases that
> were copied were not reattached on the main server. Would the failure to
> copy the other db prevent the reattach from executing'
> Barry
>|||Hi Barry,
From your descriptions, I understood that your Copy Database Wizard failed
to transfer the third database while the first two succeed. Have I
understood you? If there is anything I misunderstood, please feel free to
let me know.
Based on my scope, to avoid data loss or inconsistency, you must be sure
there are no active sessions attached to the database being moved or
copied. If there are active sessions, the Copy Database Wizard will not
run. You could also find the descriptions above in BOL, Using the Copy
Database Wizard. Which is to say it is entirely possible the active session
in your third database lead to that copy failure.
Additionaly, here are some documents for you on how to transfer databases
between SQL Servers.
Moving SQL Server databases to a new location with Detach/Attach
http://support.microsoft.com/default.aspx?scid=kb;EN-US;224071
HOW TO: Move Databases Between Computers That Are Running SQL Server
http://support.microsoft.com/default.aspx?scid=KB;en-us;314546
Thank you for your patience and cooperation. If you have any questions or
concerns, don't hesitate to let me know. We are here to be of assistance!
Sincerely yours,
Mingqing Cheng
Online Partner Support Specialist
Partner Support Group
Microsoft Global Technical Support Center
---
Introduction to Yukon! - http://www.microsoft.com/sql/yukon
This posting is provided "as is" with no warranties and confers no rights.
Please reply to newsgroups only, many thanks!|||Hi Barry,
I wanted to post a quick note to see if you would like additional
assistance or information regarding this particular issue. We appreciate
your patience and look forward to hearing from you!
Sincerely yours,
Mingqing Cheng
Online Partner Support Specialist
Partner Support Group
Microsoft Global Technical Support Center
---
Introduction to Yukon! - http://www.microsoft.com/sql/yukon
This posting is provided "as is" with no warranties and confers no rights.
Please reply to newsgroups only, many thanks!

Copied Package ConnectionManager has photographic memory?

I originally made 1 package, got it the way I wanted with configurations,etc, and then made 30 copies of it, renaming, etc.

The original package (and the copies) has 2 connections. Connection A is set at runtime by a configuration from an XML file. Connection B is set from a SQL Server lookup from Connection A.

I'm now trying to run one of those copied packages. As I mentioned, in my package I have 2 connections. I changed one of my connections, save the package, go back and look at the connection, and the initial catalog has changed. Life is good, right? Wrong. I close the package, go back in, and the initial catalog is back to the original. If I look at the package's XML in notepad, I see the correct new connection manager. So where is it picking up this info from?

Interestingly, if I delete the connection, add a new connection, rename it to the original connection I had (so my configuration will still be good), save it, close it, go back in, it still reverts back to that original connection.

Whats the deal? Its almost like I have to name my connections differently across packages?Check if it is configured in the configuration settings
(in this case it is loaded from config provider) or
maybe in the property expressions (in which case it
is calculated).|||wow. I must be burnt out. I see the problem. User error. thanks

Copied database maintains original name in backups

I made a copy of a database "sac_prod" and named the new copy "vgs_prod". Now, when I do a backup of the new database, it still shows the name of the original. Is there any way to change this so it will be the same as the new database name?
Here is the BACKUP script:
BACKUPdatabase vgs_prod TODISK=
'\\sac-srvr1\data$\Technical\Shared\Production\SQLBackup\ LasVegas\vgs_prod_CopyOnly.BAK'
with COPY_ONLY
Here is the messages I received from this BACKUP:
Processed 1752 pages for database 'vgs_prod', file 'sac_prod' on file 1.
Processed 6 pages for database 'vgs_prod', file 'sac_prod_log' on file 1.
BACKUP DATABASE successfully processed 1758 pages in 0.412 seconds (34.955 MB/sec).

I would like to change the file 'sac_prod' to be 'vgs_prod' in lines 1 and 2 just above.

Thanks,it is the logical file name being displayed. it should not create any problem anywhere. still if u want to change

alter database vgs_prod modify file (NAME = 'sac_prod' , NEWNAME = 'vgs_prod')|||Thank you. I will be working with this later today.