I have a dev tier and q tier of servers.  Is there a way to automate it
so I can have a specific database ("mydb") copied (i assume a detach is
required) from my dev tier server to a q tier server?   I need whatever
users to be reinstated for the db using "SA" authentication.

Fun huh !!

(bringmewa***@gmail.com) writes:
That sounds flat wrong to me. The proper way to build the databases on the
test/QA tier, should be to build them from the version control system.
Development databases can include all sorts of junk that does not
belong on a QA server.

If you are using SQL 2005, you can use the Copy Database Wizard and
use the Detach method to copy servers. There are options to set this
up as a job. I believe SQL 2000 has similar stuff, but I have not looked
at it.

bringmewa***@gmail.com wrote:
The proper way to move objects from development to QA is by running in
QA the same DDL scripts that you ran in development.  To create a new
table in dev, you write a script that uses the CREATE TABLE command,
defining the table structure, constraints, indexes, etc..  This script
is checked into version control along with any other scripts related to
the enhancement.  When ready for QA, the new table script and those
related to it are then run in QA.  You should never transfer an entire
database from Dev to QA to Prod.

"You should never transfer an entire
database from Dev to QA to Prod. "

Why?  We've been doing it for years and it works for us.

bringmewa***@gmail.com wrote:
Imagine you have a group of 100 developers, all who have virtually full
access to your development database.  They can create/modify tables,
procs, triggers, etc., no restrictions.  You have multiple development
projects (Projects A, B, and C) under way, some related, most not.  Each
project involves tables and procs that are unrelated to the other
projects.  When Project A is ready to move to QA, how does it get there?
  Your developers don't have access to the QA environment, only the
DBA's, QA staff, your Change Management staff, and a few development
leads do.

Project A gets to QA by checking out the required scripts from version
control, and deploying them to the QA environment.  If something isn't
scripted and archived, it doesn't get deployed, period.  Your QA
environment stays clean, without all of the development artifacts.
Finally, when Project A has been approved by QA, how does it get to
production?  NONE of the developers have access to production, only the
DBA's and Change Management do.

Project A gets deployed to production during a planned outage, by
checking out the required scripts from version control, and deploying
them to production.  Your production environment stays clean, running
only tested, stable code, with no risk of developers getting to data
they should not have access to.

Your way may work for you, but it would never fly in a large operation.

extracting data
Trying to match lowercase
too long...
datetime between problem
SQL Join question - getting most recent value in a history table