Difference Between Production & Development

Hi
Heard a lot of people talk abt production & development environment
what all do they mean ....
Does supporting a production environment mean that its only
administration of the box
& does Development mean codint the T SQL statments
Someone please help & clarify this doubt...
ThanksNot a formal definition but just to give you an idea :-)
A development environment is where software and database developers write
and test their applications. When these applications are tested and complete
d
they are moved to the production environment.
A production environment is the live environment where final users enter
their data, query information and run their reports.
Ben Nevarez, MCDBA, OCP
Database Administrator
"Double_B" wrote:

> Hi
> Heard a lot of people talk abt production & development environment
> what all do they mean ....
> Does supporting a production environment mean that its only
> administration of the box
> & does Development mean codint the T SQL statments
> Someone please help & clarify this doubt...
>
> Thanks
>|||"Ben Nevarez" <BenNevarez@.discussions.microsoft.com> wrote in message
news:ACE47A28-2432-46D2-AE96-8E8ADE2356A4@.microsoft.com...
> Not a formal definition but just to give you an idea :-)
> A development environment is where software and database developers write
> and test their applications. When these applications are tested and
completed
> they are moved to the production environment.
> A production environment is the live environment where final users enter
> their data, query information and run their reports.
>
To further expand...
Some possible differences. In my development environment typically I'll
have databases set to simple recovery only as it doesn't matter if I lose
data. And this makes my disaster recovery model much more simple.
On the other hand for production, I use a full recovery model.
In development, the developers can "do what they want, when they want"
pretty much. If they lock up the database with a bad query, I don't care.
With production, I'm typically the only one making schema changes or doing
ad-hoc queries.
My Dev environment may or may not have RAID, UPS, etc. (typically it does
just because it's cheap enough).
My prod environment definitely has stuff like that.
[vbcol=seagreen]
> Ben Nevarez, MCDBA, OCP
> Database Administrator
>
> "Double_B" wrote:
>

Difference Between Production & Development

Hi
Heard a lot of people talk abt production & development environment
what all do they mean ....
Does supporting a production environment mean that its only
administration of the box
& does Development mean codint the T SQL statments
Someone please help & clarify this doubt...
ThanksNot a formal definition but just to give you an idea :-)
A development environment is where software and database developers write
and test their applications. When these applications are tested and completed
they are moved to the production environment.
A production environment is the live environment where final users enter
their data, query information and run their reports.
Ben Nevarez, MCDBA, OCP
Database Administrator
"Double_B" wrote:
> Hi
> Heard a lot of people talk abt production & development environment
> what all do they mean ....
> Does supporting a production environment mean that its only
> administration of the box
> & does Development mean codint the T SQL statments
> Someone please help & clarify this doubt...
>
> Thanks
>|||"Ben Nevarez" <BenNevarez@.discussions.microsoft.com> wrote in message
news:ACE47A28-2432-46D2-AE96-8E8ADE2356A4@.microsoft.com...
> Not a formal definition but just to give you an idea :-)
> A development environment is where software and database developers write
> and test their applications. When these applications are tested and
completed
> they are moved to the production environment.
> A production environment is the live environment where final users enter
> their data, query information and run their reports.
>
To further expand...
Some possible differences. In my development environment typically I'll
have databases set to simple recovery only as it doesn't matter if I lose
data. And this makes my disaster recovery model much more simple.
On the other hand for production, I use a full recovery model.
In development, the developers can "do what they want, when they want"
pretty much. If they lock up the database with a bad query, I don't care.
With production, I'm typically the only one making schema changes or doing
ad-hoc queries.
My Dev environment may or may not have RAID, UPS, etc. (typically it does
just because it's cheap enough).
My prod environment definitely has stuff like that.
> Ben Nevarez, MCDBA, OCP
> Database Administrator
>
> "Double_B" wrote:
> > Hi
> >
> > Heard a lot of people talk abt production & development environment
> > what all do they mean ....
> >
> > Does supporting a production environment mean that its only
> > administration of the box
> >
> > & does Development mean codint the T SQL statments
> >
> > Someone please help & clarify this doubt...
> >
> >
> > Thanks
> >
> >

Diff b/w executing as Stored Procedure and Script

Hi All,
I have a peculiar problem with SQL2000. When i execute a Stored procedure in Demo & Production i get different outputs. But i copied the business logistics from the Sp and executed as a script in both the servers. Now Both the records are same.

I WANT TO KNOW " WHETHER THERE IS ANY DIFFERENCE IN EXECUTION METHODOLOGY BETWEEN STORED PROCEDURE AND QUERY".

NOTE: My stored procedure has 14 executable scripts. Upto 10 scripts no date comparisons were made. But at the 11th script the records differ.

I DOUBT WHETHER THERE WILL BE ANY DATE RELATED ISSUE WHEN EXECUTING AS STORED PROCEDURE AND SCRIPT

Hi,

There is no date related issue for a stored procedure to execute as for as I know. the diffrence between the stored proceudre and the script is the execution plan and the compiling time. remember some time in stored procedure might return the cached data. If possible try to start and stop the DB and then try to execute in both they day.

Might be some thing wrong in the quries in SP and the script which youa re running.

Take a look.

Mohan

|||

Hi Mohan,

Thanks for your reply. There is no chance for error in the script. How i say this bcoz " When i am running the script and the queries in the demo server i get the same result. So only i am very sure about that. Anyway you have given me a new Information. I shall take the necessary steps.

The DIFFERENCE occurs only in PRODUCTION server.

Device holding MASTER, MODEL, MSDB, and TempDB FULL

I have other drives that are quite large that I could move any one of these
to. Not sure how to do the move...this is a production server and down
time needs to be almost non-existent.
TempDB is taking up 1 gig, if there was a way to move it without bringing
down the server, that would be great (like adding a file to new drive, then
shrinking with EMPTY_FILE on old drive.....can this be done during
production or would it cause slowness or locking, etc.?)What version of SQL Server are you using ...?
Have you tried Shrinking it. DBCC SHRINKFILE
HTH
Ryan Waight, MCDBA, MCSE
"John Hamilton" <jhamil@.nowhere.com> wrote in message
news:ODt9rtJnDHA.2528@.TK2MSFTNGP12.phx.gbl...
> I have other drives that are quite large that I could move any one of
these
> to. Not sure how to do the move...this is a production server and down
> time needs to be almost non-existent.
> TempDB is taking up 1 gig, if there was a way to move it without bringing
> down the server, that would be great (like adding a file to new drive,
then
> shrinking with EMPTY_FILE on old drive.....can this be done during
> production or would it cause slowness or locking, etc.?)
>|||I'm using 2000, and I tried DBCC SHRINKFILE, it didn't change the size.
"Ryan Waight" <Ryan_Waight@.nospam.hotmail.com> wrote in message
news:eWnaIzJnDHA.2012@.TK2MSFTNGP12.phx.gbl...
> What version of SQL Server are you using ...?
> Have you tried Shrinking it. DBCC SHRINKFILE
>
> --
> HTH
> Ryan Waight, MCDBA, MCSE
> "John Hamilton" <jhamil@.nowhere.com> wrote in message
> news:ODt9rtJnDHA.2528@.TK2MSFTNGP12.phx.gbl...
> > I have other drives that are quite large that I could move any one of
> these
> > to. Not sure how to do the move...this is a production server and down
> > time needs to be almost non-existent.
> >
> > TempDB is taking up 1 gig, if there was a way to move it without
bringing
> > down the server, that would be great (like adding a file to new drive,
> then
> > shrinking with EMPTY_FILE on old drive.....can this be done during
> > production or would it cause slowness or locking, etc.?)
> >
> >
>|||Tried SHRINKFILE again and it worked this time....'?
"Ryan Waight" <Ryan_Waight@.nospam.hotmail.com> wrote in message
news:eWnaIzJnDHA.2012@.TK2MSFTNGP12.phx.gbl...
> What version of SQL Server are you using ...?
> Have you tried Shrinking it. DBCC SHRINKFILE
>
> --
> HTH
> Ryan Waight, MCDBA, MCSE
> "John Hamilton" <jhamil@.nowhere.com> wrote in message
> news:ODt9rtJnDHA.2528@.TK2MSFTNGP12.phx.gbl...
> > I have other drives that are quite large that I could move any one of
> these
> > to. Not sure how to do the move...this is a production server and down
> > time needs to be almost non-existent.
> >
> > TempDB is taking up 1 gig, if there was a way to move it without
bringing
> > down the server, that would be great (like adding a file to new drive,
> then
> > shrinking with EMPTY_FILE on old drive.....can this be done during
> > production or would it cause slowness or locking, etc.?)
> >
> >
>|||Have a look at this :- http://www.aspfaq.com/show.asp?id=2446
good for future reference..
--
HTH
Ryan Waight, MCDBA, MCSE
"John Hamilton" <jhamil@.nowhere.com> wrote in message
news:%234Iku4JnDHA.2080@.TK2MSFTNGP10.phx.gbl...
> Tried SHRINKFILE again and it worked this time....'?
>
> "Ryan Waight" <Ryan_Waight@.nospam.hotmail.com> wrote in message
> news:eWnaIzJnDHA.2012@.TK2MSFTNGP12.phx.gbl...
> > What version of SQL Server are you using ...?
> >
> > Have you tried Shrinking it. DBCC SHRINKFILE
> >
> >
> >
> > --
> > HTH
> > Ryan Waight, MCDBA, MCSE
> >
> > "John Hamilton" <jhamil@.nowhere.com> wrote in message
> > news:ODt9rtJnDHA.2528@.TK2MSFTNGP12.phx.gbl...
> > > I have other drives that are quite large that I could move any one of
> > these
> > > to. Not sure how to do the move...this is a production server and
down
> > > time needs to be almost non-existent.
> > >
> > > TempDB is taking up 1 gig, if there was a way to move it without
> bringing
> > > down the server, that would be great (like adding a file to new drive,
> > then
> > > shrinking with EMPTY_FILE on old drive.....can this be done during
> > > production or would it cause slowness or locking, etc.?)
> > >
> > >
> >
> >
>|||This would indicate an open transaction was preventing the shrink. DBCC
OPENTRAN shows any open transcations
--
HTH
Ryan Waight, MCDBA, MCSE
"John Hamilton" <jhamil@.nowhere.com> wrote in message
news:%234Iku4JnDHA.2080@.TK2MSFTNGP10.phx.gbl...
> Tried SHRINKFILE again and it worked this time....'?
>
> "Ryan Waight" <Ryan_Waight@.nospam.hotmail.com> wrote in message
> news:eWnaIzJnDHA.2012@.TK2MSFTNGP12.phx.gbl...
> > What version of SQL Server are you using ...?
> >
> > Have you tried Shrinking it. DBCC SHRINKFILE
> >
> >
> >
> > --
> > HTH
> > Ryan Waight, MCDBA, MCSE
> >
> > "John Hamilton" <jhamil@.nowhere.com> wrote in message
> > news:ODt9rtJnDHA.2528@.TK2MSFTNGP12.phx.gbl...
> > > I have other drives that are quite large that I could move any one of
> > these
> > > to. Not sure how to do the move...this is a production server and
down
> > > time needs to be almost non-existent.
> > >
> > > TempDB is taking up 1 gig, if there was a way to move it without
> bringing
> > > down the server, that would be great (like adding a file to new drive,
> > then
> > > shrinking with EMPTY_FILE on old drive.....can this be done during
> > > production or would it cause slowness or locking, etc.?)
> > >
> > >
> >
> >
>

Development/Production Environment with Visual Source Safe

Am new to RS. Installed it on test server and was quickly able to
generate a report with multiple datasources and even write some code to
render it directly to a PDF file. Quite a useful and efficient tool.
Now, we want to bring RS into our development environment. We have
multiple developers working on an internal web app in VS.NET that we
want to incorporate reports into. Developers use Visual Source Safe to
bring project files from the development server to their own machines
to do development and then check changes back into the development
server. Periodically, our app is release from development to
production. Pretty straightforward.
What I'm curious about is:
(1) Does SourceSafe version control the report definitions? They look
like files in VS .NET but they reside in the RS database, so I'm
uncertain.
(2) Can developers install RS on their machines for developing reports
under VS.NET while using the RS server/database on the development
server for previewing?
Thanks.
JeffAnswers to your questions:
1. You can (and should) check reports, report projects, report
solutions--however you want to organize it--into VSS. But it is a separate
process that you have to enforce with policy and procedure as VSS will not
reach into the report catalog (database) and handle versioning there.
2. Yes. If your developers have VS.NET 2003, then just install any version
of Reporting Services on their workstations, just unselect and server
components if they are offered in the setup.
--
Douglas McDowell douglas@.nospam.solidqualitylearning.com
"JeffW" <jwilson@.telnetww.com> wrote in message
news:1110499289.694022.73370@.g14g2000cwa.googlegroups.com...
> Am new to RS. Installed it on test server and was quickly able to
> generate a report with multiple datasources and even write some code to
> render it directly to a PDF file. Quite a useful and efficient tool.
> Now, we want to bring RS into our development environment. We have
> multiple developers working on an internal web app in VS.NET that we
> want to incorporate reports into. Developers use Visual Source Safe to
> bring project files from the development server to their own machines
> to do development and then check changes back into the development
> server. Periodically, our app is release from development to
> production. Pretty straightforward.
> What I'm curious about is:
> (1) Does SourceSafe version control the report definitions? They look
> like files in VS .NET but they reside in the RS database, so I'm
> uncertain.
> (2) Can developers install RS on their machines for developing reports
> under VS.NET while using the RS server/database on the development
> server for previewing?
> Thanks.
> Jeff
>

Development, Staging, Production - best practice

Hi,
I would appreciate your advice in deploying enterprise BI solution. The task
at hand is this: I need to get the data from DW (SQL 2005), process into SSAS
and present with SSRS. I may also need to offer a third party OLAP browser as
a part this of solution. My initial thoughts about the setup for this are:
- SRV1: Development server, with all SQL 2005 components, IIS, and any third
party OLAP tools that we might pick.
-SRV2: Staging/Processing. Schedule and run SSIS to get data from DW, and
refresh and process SSAS cubes.
-SRV3: Production Reporting/Web server: This server would hold processed
cubes from SRV2 (archived and restored on SRV3), SSRS, IIS any any third
party OLAP browser that we may pick.
Initially there will be 2-3 developers, 15-20 cubes and 30-40 reports. We
are targeting to server 20-30 Report users.
Does the above setup make sense? Do I need dedicated web server with or
without SSRS? Please share thoughts or advise of any best practice articles.
Thank you.
ZoranHello Zoran,
The server setup need to be decide with that how large your cube is and how
many data your cube stored.
Yes, you need to seperate a stand alone server to process all the Cube data
and use the Reporting Services as the Front End Server.
I don't think you need to dedicate the web server with Reporting Services
because the Reporting Services is also a web application in the web front
end. Also, considering your report users, your report web quest will not at
a high level.
Hope this helps.
Sincerely,
Wei Lu
Microsoft Online Community Support
==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================This posting is provided "AS IS" with no warranties, and confers no rights.|||Thank you Wei,
Currently all our cubes are MOLAP, with database sizes ranging from 30 MB to
300 MB. I read that one of the most efficient ways to move from Staging to
Production is backup and retore. But, is it good practice to keep production
cubes on the same server as SSRS? Technically, there would be no processing
on that server, cubes would only sit there for user's queries...
Zoran
"Wei Lu [MSFT]" wrote:
> Hello Zoran,
> The server setup need to be decide with that how large your cube is and how
> many data your cube stored.
> Yes, you need to seperate a stand alone server to process all the Cube data
> and use the Reporting Services as the Front End Server.
> I don't think you need to dedicate the web server with Reporting Services
> because the Reporting Services is also a web application in the web front
> end. Also, considering your report users, your report web quest will not at
> a high level.
> Hope this helps.
> Sincerely,
> Wei Lu
> Microsoft Online Community Support
> ==================================================> When responding to posts, please "Reply to Group" via your newsreader so
> that others may learn and benefit from your issue.
> ==================================================> This posting is provided "AS IS" with no warranties, and confers no rights.
>|||Hello Zoran,
Whether putting the SSRS together with the Cube depends on the size and how
system resource used by the SSAS.
In your scenario, I think it is OK for you to put the SSRS on the same
server at this time. But if your cube grows, you may need to seperate the
SSAS with SSRS.
Sincerely,
Wei Lu
Microsoft Online Community Support
==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================This posting is provided "AS IS" with no warranties, and confers no rights.|||Hi ,
How is everything going? Please feel free to let me know if you need any
assistance.
Sincerely,
Wei Lu
Microsoft Online Community Support
==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================This posting is provided "AS IS" with no warranties, and confers no rights.|||Thank you Wei.
In your previous post you you mentioned "depends how system resources
(are)used by SSAS". In my scenario, they would be used for user queries
(direct and via SSRS). There would be no processing done on this server.
I can certainly see the number of cubes grow in near future. Is one server
for SSRS and SSAS going to work, or am I setting myself up for upgrade in
near future?
Regards,
Zoran Knezic
"Wei Lu [MSFT]" wrote:
> Hi ,
> How is everything going? Please feel free to let me know if you need any
> assistance.
> Sincerely,
> Wei Lu
> Microsoft Online Community Support
> ==================================================> When responding to posts, please "Reply to Group" via your newsreader so
> that others may learn and benefit from your issue.
> ==================================================> This posting is provided "AS IS" with no warranties, and confers no rights.
>|||RS 2005 does all rendering in RAM. As long as you have enough RAM I think
you will be OK. I would suggest starting off on one server. Perhaps let
management know that you will need to monitor the usage and there is a
chance they will need to be split onto separate servers. RS 2008 is going to
be much smarter and with how it renders.
You said the following: Initially there will be 2-3 developers, 15-20 cubes
and 30-40 reports. We
are targeting to server 20-30 Report users.
This is not that many users. I do not have cubes but I have a datamart which
includes a table with 150 million rows (small rows admittedly) plus several
tables that have several million rows. RS 2005 and the datamart are on the
same server without difficulty. Similar number of users (more reports). My
server is old (4 years old) and ready for replacement. I have 4
processors(2.4 GHz), 4 Gigs of Ram (so this is not a huge powerful box by
any means). Performance is very very good for me. Running SQL 2005 Standard
edition.
Since you are just getting started. If you are able to plan on using RS 2008
I would do so. RS 2008 should be able to use a SQL 2005 db for its
metadata/object caching so it is a licensing issue.
Bruce Loehle-Conger
MVP SQL Server Reporting Services
"zk_" <zk_@.newsgroup.nospam> wrote in message
news:EB03F7C3-13D3-40D2-8991-7FAF755EEFCE@.microsoft.com...
> Thank you Wei.
> In your previous post you you mentioned "depends how system resources
> (are)used by SSAS". In my scenario, they would be used for user queries
> (direct and via SSRS). There would be no processing done on this server.
> I can certainly see the number of cubes grow in near future. Is one server
> for SSRS and SSAS going to work, or am I setting myself up for upgrade in
> near future?
> Regards,
> Zoran Knezic
> "Wei Lu [MSFT]" wrote:
>> Hi ,
>> How is everything going? Please feel free to let me know if you need any
>> assistance.
>> Sincerely,
>> Wei Lu
>> Microsoft Online Community Support
>> ==================================================>> When responding to posts, please "Reply to Group" via your newsreader so
>> that others may learn and benefit from your issue.
>> ==================================================>> This posting is provided "AS IS" with no warranties, and confers no
>> rights.
>>|||Thank you Bruce.
It is good to hear a first hand experience with DB and SSRS on the same
server.
I am sure that SSAS creates bigger overhead then DB, but judging by your
experience, I might be OK.
My IMIT colleagues came up with 2x 2.8 GHz server, with 16 Gb of RAM.
Alternatively I might be able to suggest two servers, 2x2.8 GHz 8GB of RAM
each.
Once again, thank you for your time.
Zoran Knezic
"Bruce L-C [MVP]" wrote:
> RS 2005 does all rendering in RAM. As long as you have enough RAM I think
> you will be OK. I would suggest starting off on one server. Perhaps let
> management know that you will need to monitor the usage and there is a
> chance they will need to be split onto separate servers. RS 2008 is going to
> be much smarter and with how it renders.
> You said the following: Initially there will be 2-3 developers, 15-20 cubes
> and 30-40 reports. We
> are targeting to server 20-30 Report users.
> This is not that many users. I do not have cubes but I have a datamart which
> includes a table with 150 million rows (small rows admittedly) plus several
> tables that have several million rows. RS 2005 and the datamart are on the
> same server without difficulty. Similar number of users (more reports). My
> server is old (4 years old) and ready for replacement. I have 4
> processors(2.4 GHz), 4 Gigs of Ram (so this is not a huge powerful box by
> any means). Performance is very very good for me. Running SQL 2005 Standard
> edition.
> Since you are just getting started. If you are able to plan on using RS 2008
> I would do so. RS 2008 should be able to use a SQL 2005 db for its
> metadata/object caching so it is a licensing issue.
>
> --
> Bruce Loehle-Conger
> MVP SQL Server Reporting Services
>
> "zk_" <zk_@.newsgroup.nospam> wrote in message
> news:EB03F7C3-13D3-40D2-8991-7FAF755EEFCE@.microsoft.com...
> > Thank you Wei.
> > In your previous post you you mentioned "depends how system resources
> > (are)used by SSAS". In my scenario, they would be used for user queries
> > (direct and via SSRS). There would be no processing done on this server.
> > I can certainly see the number of cubes grow in near future. Is one server
> > for SSRS and SSAS going to work, or am I setting myself up for upgrade in
> > near future?
> >
> > Regards,
> > Zoran Knezic
> >
> > "Wei Lu [MSFT]" wrote:
> >
> >> Hi ,
> >>
> >> How is everything going? Please feel free to let me know if you need any
> >> assistance.
> >>
> >> Sincerely,
> >>
> >> Wei Lu
> >> Microsoft Online Community Support
> >>
> >> ==================================================> >>
> >> When responding to posts, please "Reply to Group" via your newsreader so
> >> that others may learn and benefit from your issue.
> >>
> >> ==================================================> >> This posting is provided "AS IS" with no warranties, and confers no
> >> rights.
> >>
> >>
>
>

Development server database refresh from production server

Hi
Can we use BCP AND/OR BULK INSERT to do development server databse refresh from production server . I have to do this by following the rules below:

- no truncation of source table
- update of changed or new records only.

I know we can use replication, dts and other methods for this but I need information about this one.

ThanksUsing BCP and/or Bulk insert to update a development server is possible, but would get complicated if you only want to update the changed records in the production server. If you want to only update the changed records you will need to somehow keep track of the records which changed in the production db, and this could lead to expanding your production db by adding extra columns or tables, which is probably not wanted. Overall I would not recommned this procedure.

Something like log shipping in SQL 2000 might be a better solution.

Good luck
Hope this helped

Development Push to UAT Push to Production

We need to configure a way to publish from development to testing and from testing to production. An easy, automated process would be best.

You might want to review some of the documentation to help you plan for replication solution.

http://msdn2.microsoft.com/en-us/library/ms146892.aspx

You'll need to establish the following:

Whether or not replicated data needs to be updated, and by whom.
Your data distribution needs regarding consistency, autonomy, and latency.
The replication environment, including business users, technical infrastructure, network and security, and data characteristics.
The types of replication and replication options.
The replication topologies and how they align with the types of replication.

Development DB to Production DB

take a look at www.dbghost.com for a full development
process...

>--Original Message--
>We have a development SQL server and a production SQL
server. Is there
>anyway to replicate what we create on the Dev box over
to production box
>when we are finished our testing?
>Thanks.
>Tom
>
>.
>Thanks Everyone.
Tom
"mark baekdal" <anonymous@.discussions.microsoft.com> wrote in message
news:dce901c40eb8$6d54ecb0$a601280a@.phx.gbl...
> take a look at www.dbghost.com for a full development
> process...
>
> server. Is there
> to production box

Development DB to Production DB

We have a development SQL server and a production SQL server. Is there
anyway to replicate what we create on the Dev box over to production box
when we are finished our testing?
Thanks.
TomHi,
DId you meant to replicate database in development to Production, if that
is the case you can go for any of the below options,
1. Detach the database in development and attach it in production
2. Backup the development database and Restore in production
Thanks
Hari
MCDBA
"Tom Pennington" <NONEt2pennington@.comcast.net> wrote in message
news:OKUPhQdDEHA.2768@.tk2msftngp13.phx.gbl...
> We have a development SQL server and a production SQL server. Is there
> anyway to replicate what we create on the Dev box over to production box
> when we are finished our testing?
> Thanks.
> Tom
>|||Backup and restore, detach/attach/Alter scripts, update/insert queries...
Depending on exactly what you want to Move (anywhere from entire database
with data to one stored procedure) there a number of ways to accomplish
this.
Kevin Hill
President
3NF Consulting
www.3nf-inc.com/NewsGroups.htm
"Tom Pennington" <NONEt2pennington@.comcast.net> wrote in message
news:OKUPhQdDEHA.2768@.tk2msftngp13.phx.gbl...
> We have a development SQL server and a production SQL server. Is there
> anyway to replicate what we create on the Dev box over to production box
> when we are finished our testing?
> Thanks.
> Tom
>|||We use ErWin To make changes to Dev.
Then we Point ErWin to QA, Etc and have it generate "Diff Scripts" for us.
The scripts are included with our Roll to Production plan.
Just another way to do the same thing
ErWin is Not "CHEAP" but I think it is a very powerful, valuable tool.
It's primary competitor is ER-Studio which I think is a little better.
Cheers
Greg Jackson
PDX, Oregon

development and implementation procedures....

Hello everyone,

I am looking for some help.

I am responsible for five SQL2000 database servers. One is production, two for development, one for testing and one for development and testing of a sub-product. We also use Source safe. Although sometimes, depending on the activity going on on each of the servers, the roles of development and testing servers get interchanged.

The problem I face as a DBA is to co-ordinate with all the developers and the people testing the applications and databases. Stored procedures, triggers and schema changes are not consistent across the same database on different servers. Multiple copies of databases get created on the same server. This happens primarily because, once development has been completed, the database is moved to the testing servers. As the testing progresses and issues are resolved, the scripts are changed, etc. As there are many developers and people testing, it is just impossible to keep track of who is doing what and where the latest source code is. And especially creates a problem during implementation. Some of you may relate to this problem.

I am new in this position and would like to put a process in place where things are better organized.

If some amongst you would like to share your thoughts and experiences or what you have done at your place of work to make your life easier, I would highly appreciate it. Also, you could direct me to places where I can get some information on this subject.

Thanks in advance and apologies for this rather lengthy question.I would say make sure you are the only admin or dbcreator on the testing server (and naturally the production server).

Once you are assured of your Oz-like powers, declare that the testing server is going to be made in the image of the production server. Ideally this should happen when no one is actually testing anything.

Once you have done this, demand of the programmers that they submit scripts for their changes. These will normally consist of a few alter or create table statements, and alter/create procedure statements. It is very rare to see a large number of tables being dropped with short shrift in the course of an internal development project.

The testing server databases can be replaced by copies of the production server at any time (in some places quarterly, but more usually by request before testing a major update). Datebases are never moved from testing to production.

Only after the testing is complete, and you are assured the upgrade can be done with no errors on production, then you can run those same scripts you ran on testing before on production.

Any old-hand programmers will probably take some offense at losing privileges on testing or production, but the benefits should outweigh the complaints. Hope this helps.

Development - Test Environment Questions

Hi,
I've been given the task of creating a dev/test environment. Currently we
have several production applications using databases on a common SQL Server.
If changes are required, the developers are performing the changes on the
production system - yea I know BAD,BAD,BAD - but I didn't set this up but
instead inherited it. I'd like to configure a dev/test environment to move
the devs off of the production system and to faciliate their development of
future projects coming up soon.
How is your dev/test environment configured? I'm looking for a few examples
here that I can work with to implement our dev/test based on our budget and
system capabilities.
I.e., Each dev has their own sandbox or each dev shares a common dev env -
then changes are implemented to test env (and by who - dev or dba - and
how - scripts) etc... then scripted to deploy on prod systems etc... also
we image/ghost systems or use VMs and also we use Visual SourceSafe to...
Trying to come up with a solid game plan here.
Thanks for any input.
Jerry
Jerry Spivey wrote:
> Hi,
> I've been given the task of creating a dev/test environment. Currently
> we have several production applications using databases on
> a common SQL Server. If changes are required, the developers are
> performing the changes on the production system - yea I know
> BAD,BAD,BAD - but I didn't set this up but instead inherited it. I'd
> like to configure a dev/test environment to move the devs off of the
> production system and to faciliate their development of future
> projects coming up soon.
> How is your dev/test environment configured? I'm looking for a few
> examples here that I can work with to implement our dev/test based on
> our budget and system capabilities.
> I.e., Each dev has their own sandbox or each dev shares a common dev
> env - then changes are implemented to test env (and by who - dev or
> dba - and how - scripts) etc... then scripted to deploy on prod
> systems etc... also we image/ghost systems or use VMs and also we use
> Visual
> SourceSafe to...
> Trying to come up with a solid game plan here.
> Thanks for any input.
> Jerry
At most companies where I've worked in the past, we had development
servers that were used strictly for development. They generally
contained stripped down data from the production databases with any
customer sensitive data masked. Lead developers generally had dbo rights
and may even have admin rights depending on the size of the company.
Version control software was used for all object changes. Initial
application testing was done on the dev servers.
QA/Test servers were not managed by development. They were usually owned
by QA group. We would provide detailed scripts to update QA servers with
the necessary changes. Users would test the applications on QA servers.
QA servers have data that more closely mimics production in terms of
data value distribution and quantity and may even be created from
production backups. Sensitive data was not masked back then, as I
recall, but it may have to be today. QA has the ability to reload the
database in case the migration to QA fails. It's important to be able to
always start from an exact copy of the production database schema.
These days, you can use multiple SQL Server Instances to save hardware
(assuming you have the necessary memory). VMs, while convenient, are
probably not ideal for performance testing. But I'm not well informed
about the capabilites of the server VM products.
If everything tested ok, the updates were escalated to production.
David Gugick
Quest Software
www.imceda.com
www.quest.com
|||Thanks David.
Looking into using named instances with EE to help control costs. Will be
looking into implementing Visual SourceSafe as well.
I noticed you work for Quest. I have a few questions about the Quest
Central if you're open to them. Please email me if so.
Thanks
Jerry
"David Gugick" <david.gugick-nospam@.quest.com> wrote in message
news:%23YygmKIaFHA.1044@.TK2MSFTNGP10.phx.gbl...
> Jerry Spivey wrote:
> At most companies where I've worked in the past, we had development
> servers that were used strictly for development. They generally contained
> stripped down data from the production databases with any customer
> sensitive data masked. Lead developers generally had dbo rights and may
> even have admin rights depending on the size of the company. Version
> control software was used for all object changes. Initial application
> testing was done on the dev servers.
> QA/Test servers were not managed by development. They were usually owned
> by QA group. We would provide detailed scripts to update QA servers with
> the necessary changes. Users would test the applications on QA servers. QA
> servers have data that more closely mimics production in terms of data
> value distribution and quantity and may even be created from production
> backups. Sensitive data was not masked back then, as I recall, but it may
> have to be today. QA has the ability to reload the database in case the
> migration to QA fails. It's important to be able to always start from an
> exact copy of the production database schema.
> These days, you can use multiple SQL Server Instances to save hardware
> (assuming you have the necessary memory). VMs, while convenient, are
> probably not ideal for performance testing. But I'm not well informed
> about the capabilites of the server VM products.
> If everything tested ok, the updates were escalated to production.
> --
> David Gugick
> Quest Software
> www.imceda.com
> www.quest.com
|||Jerry Spivey wrote:
> Thanks David.
> Looking into using named instances with EE to help control costs. Will
> be looking into implementing Visual SourceSafe as well.
> I noticed you work for Quest. I have a few questions about the Quest
> Central if you're open to them. Please email me if so.
> Thanks
> Jerry
>
The best way for you to get information and help with the Quest product
line is to contact sales. Our offices and numbers are located here:
http://www.quest.com/company/us_offices.asp
David Gugick
Quest Software
www.imceda.com
www.quest.com
|||Change management is the term.
http://www.innovartis.co.uk/pdf/Inno...ange_Mgt. pdf
This is a white paper on the subject using Source Control (Visual Source
Safe) as the back bone of the approach. The application DB Ghost
(www.dbghost.com) was built using this methodology.
regards,
Mark Baekdal
http://www.dbghost.com
http://www.innovartis.co.uk
+44 (0)208 241 1762
Build, Comparison and Synchronization from Source Control = Database change
management for SQL Server
"Jerry Spivey" wrote:

> Hi,
> I've been given the task of creating a dev/test environment. Currently we
> have several production applications using databases on a common SQL Server.
> If changes are required, the developers are performing the changes on the
> production system - yea I know BAD,BAD,BAD - but I didn't set this up but
> instead inherited it. I'd like to configure a dev/test environment to move
> the devs off of the production system and to faciliate their development of
> future projects coming up soon.
>
> How is your dev/test environment configured? I'm looking for a few examples
> here that I can work with to implement our dev/test based on our budget and
> system capabilities.
> I.e., Each dev has their own sandbox or each dev shares a common dev env -
> then changes are implemented to test env (and by who - dev or dba - and
> how - scripts) etc... then scripted to deploy on prod systems etc... also
> we image/ghost systems or use VMs and also we use Visual SourceSafe to...
> Trying to come up with a solid game plan here.
> Thanks for any input.
> Jerry
>
>

Development - Test Environment Questions

Hi,
I've been given the task of creating a dev/test environment. Currently we
have several production applications using databases on a common SQL Server.
If changes are required, the developers are performing the changes on the
production system - yea I know BAD,BAD,BAD - but I didn't set this up but
instead inherited it. I'd like to configure a dev/test environment to move
the devs off of the production system and to faciliate their development of
future projects coming up soon.
How is your dev/test environment configured? I'm looking for a few examples
here that I can work with to implement our dev/test based on our budget and
system capabilities.
I.e., Each dev has their own sandbox or each dev shares a common dev env -
then changes are implemented to test env (and by who - dev or dba - and
how - scripts) etc... then scripted to deploy on prod systems etc... also
we image/ghost systems or use VMs and also we use Visual SourceSafe to...
Trying to come up with a solid game plan here.
Thanks for any input.
JerryJerry Spivey wrote:
> Hi,
> I've been given the task of creating a dev/test environment. Currently
> we have several production applications using databases on
> a common SQL Server. If changes are required, the developers are
> performing the changes on the production system - yea I know
> BAD,BAD,BAD - but I didn't set this up but instead inherited it. I'd
> like to configure a dev/test environment to move the devs off of the
> production system and to faciliate their development of future
> projects coming up soon.
> How is your dev/test environment configured? I'm looking for a few
> examples here that I can work with to implement our dev/test based on
> our budget and system capabilities.
> I.e., Each dev has their own sandbox or each dev shares a common dev
> env - then changes are implemented to test env (and by who - dev or
> dba - and how - scripts) etc... then scripted to deploy on prod
> systems etc... also we image/ghost systems or use VMs and also we use
> Visual
> SourceSafe to...
> Trying to come up with a solid game plan here.
> Thanks for any input.
> Jerry
At most companies where I've worked in the past, we had development
servers that were used strictly for development. They generally
contained stripped down data from the production databases with any
customer sensitive data masked. Lead developers generally had dbo rights
and may even have admin rights depending on the size of the company.
Version control software was used for all object changes. Initial
application testing was done on the dev servers.
QA/Test servers were not managed by development. They were usually owned
by QA group. We would provide detailed scripts to update QA servers with
the necessary changes. Users would test the applications on QA servers.
QA servers have data that more closely mimics production in terms of
data value distribution and quantity and may even be created from
production backups. Sensitive data was not masked back then, as I
recall, but it may have to be today. QA has the ability to reload the
database in case the migration to QA fails. It's important to be able to
always start from an exact copy of the production database schema.
These days, you can use multiple SQL Server Instances to save hardware
(assuming you have the necessary memory). VMs, while convenient, are
probably not ideal for performance testing. But I'm not well informed
about the capabilites of the server VM products.
If everything tested ok, the updates were escalated to production.
--
David Gugick
Quest Software
www.imceda.com
www.quest.com|||Thanks David.
Looking into using named instances with EE to help control costs. Will be
looking into implementing Visual SourceSafe as well.
I noticed you work for Quest. I have a few questions about the Quest
Central if you're open to them. Please email me if so.
Thanks
Jerry
"David Gugick" <david.gugick-nospam@.quest.com> wrote in message
news:%23YygmKIaFHA.1044@.TK2MSFTNGP10.phx.gbl...
> Jerry Spivey wrote:
>> Hi,
>> I've been given the task of creating a dev/test environment. Currently we
>> have several production applications using databases on
>> a common SQL Server. If changes are required, the developers are
>> performing the changes on the production system - yea I know
>> BAD,BAD,BAD - but I didn't set this up but instead inherited it. I'd
>> like to configure a dev/test environment to move the devs off of the
>> production system and to faciliate their development of future
>> projects coming up soon.
>> How is your dev/test environment configured? I'm looking for a few
>> examples here that I can work with to implement our dev/test based on
>> our budget and system capabilities.
>> I.e., Each dev has their own sandbox or each dev shares a common dev
>> env - then changes are implemented to test env (and by who - dev or
>> dba - and how - scripts) etc... then scripted to deploy on prod systems
>> etc... also we image/ghost systems or use VMs and also we use Visual
>> SourceSafe to...
>> Trying to come up with a solid game plan here.
>> Thanks for any input.
>> Jerry
> At most companies where I've worked in the past, we had development
> servers that were used strictly for development. They generally contained
> stripped down data from the production databases with any customer
> sensitive data masked. Lead developers generally had dbo rights and may
> even have admin rights depending on the size of the company. Version
> control software was used for all object changes. Initial application
> testing was done on the dev servers.
> QA/Test servers were not managed by development. They were usually owned
> by QA group. We would provide detailed scripts to update QA servers with
> the necessary changes. Users would test the applications on QA servers. QA
> servers have data that more closely mimics production in terms of data
> value distribution and quantity and may even be created from production
> backups. Sensitive data was not masked back then, as I recall, but it may
> have to be today. QA has the ability to reload the database in case the
> migration to QA fails. It's important to be able to always start from an
> exact copy of the production database schema.
> These days, you can use multiple SQL Server Instances to save hardware
> (assuming you have the necessary memory). VMs, while convenient, are
> probably not ideal for performance testing. But I'm not well informed
> about the capabilites of the server VM products.
> If everything tested ok, the updates were escalated to production.
> --
> David Gugick
> Quest Software
> www.imceda.com
> www.quest.com|||Jerry Spivey wrote:
> Thanks David.
> Looking into using named instances with EE to help control costs. Will
> be looking into implementing Visual SourceSafe as well.
> I noticed you work for Quest. I have a few questions about the Quest
> Central if you're open to them. Please email me if so.
> Thanks
> Jerry
>
The best way for you to get information and help with the Quest product
line is to contact sales. Our offices and numbers are located here:
http://www.quest.com/company/us_offices.asp
--
David Gugick
Quest Software
www.imceda.com
www.quest.com|||Change management is the term.
http://www.innovartis.co.uk/pdf/Innovartis_An_Automated_Approach_To_Do_Change_Mgt.pdf
This is a white paper on the subject using Source Control (Visual Source
Safe) as the back bone of the approach. The application DB Ghost
(www.dbghost.com) was built using this methodology.
regards,
Mark Baekdal
http://www.dbghost.com
http://www.innovartis.co.uk
+44 (0)208 241 1762
Build, Comparison and Synchronization from Source Control = Database change
management for SQL Server
"Jerry Spivey" wrote:
> Hi,
> I've been given the task of creating a dev/test environment. Currently we
> have several production applications using databases on a common SQL Server.
> If changes are required, the developers are performing the changes on the
> production system - yea I know BAD,BAD,BAD - but I didn't set this up but
> instead inherited it. I'd like to configure a dev/test environment to move
> the devs off of the production system and to faciliate their development of
> future projects coming up soon.
>
> How is your dev/test environment configured? I'm looking for a few examples
> here that I can work with to implement our dev/test based on our budget and
> system capabilities.
> I.e., Each dev has their own sandbox or each dev shares a common dev env -
> then changes are implemented to test env (and by who - dev or dba - and
> how - scripts) etc... then scripted to deploy on prod systems etc... also
> we image/ghost systems or use VMs and also we use Visual SourceSafe to...
> Trying to come up with a solid game plan here.
> Thanks for any input.
> Jerry
>
>

Development - Test Environment Questions

Hi,
I've been given the task of creating a dev/test environment. Currently we
have several production applications using databases on a common SQL Server.
If changes are required, the developers are performing the changes on the
production system - yea I know BAD,BAD,BAD - but I didn't set this up but
instead inherited it. I'd like to configure a dev/test environment to move
the devs off of the production system and to faciliate their development of
future projects coming up soon.
How is your dev/test environment configured? I'm looking for a few examples
here that I can work with to implement our dev/test based on our budget and
system capabilities.
I.e., Each dev has their own sandbox or each dev shares a common dev env -
then changes are implemented to test env (and by who - dev or dba - and
how - scripts) etc... then scripted to deploy on prod systems etc... also
we image/ghost systems or use VMs and also we use Visual SourceSafe to...
Trying to come up with a solid game plan here.
Thanks for any input.
JerryJerry Spivey wrote:
> Hi,
> I've been given the task of creating a dev/test environment. Currently
> we have several production applications using databases on
> a common SQL Server. If changes are required, the developers are
> performing the changes on the production system - yea I know
> BAD,BAD,BAD - but I didn't set this up but instead inherited it. I'd
> like to configure a dev/test environment to move the devs off of the
> production system and to faciliate their development of future
> projects coming up soon.
> How is your dev/test environment configured? I'm looking for a few
> examples here that I can work with to implement our dev/test based on
> our budget and system capabilities.
> I.e., Each dev has their own sandbox or each dev shares a common dev
> env - then changes are implemented to test env (and by who - dev or
> dba - and how - scripts) etc... then scripted to deploy on prod
> systems etc... also we image/ghost systems or use VMs and also we use
> Visual
> SourceSafe to...
> Trying to come up with a solid game plan here.
> Thanks for any input.
> Jerry
At most companies where I've worked in the past, we had development
servers that were used strictly for development. They generally
contained stripped down data from the production databases with any
customer sensitive data masked. Lead developers generally had dbo rights
and may even have admin rights depending on the size of the company.
Version control software was used for all object changes. Initial
application testing was done on the dev servers.
QA/Test servers were not managed by development. They were usually owned
by QA group. We would provide detailed scripts to update QA servers with
the necessary changes. Users would test the applications on QA servers.
QA servers have data that more closely mimics production in terms of
data value distribution and quantity and may even be created from
production backups. Sensitive data was not masked back then, as I
recall, but it may have to be today. QA has the ability to reload the
database in case the migration to QA fails. It's important to be able to
always start from an exact copy of the production database schema.
These days, you can use multiple SQL Server Instances to save hardware
(assuming you have the necessary memory). VMs, while convenient, are
probably not ideal for performance testing. But I'm not well informed
about the capabilites of the server VM products.
If everything tested ok, the updates were escalated to production.
David Gugick
Quest Software
www.imceda.com
www.quest.com|||Thanks David.
Looking into using named instances with EE to help control costs. Will be
looking into implementing Visual SourceSafe as well.
I noticed you work for Quest. I have a few questions about the Quest
Central if you're open to them. Please email me if so.
Thanks
Jerry
"David Gugick" <david.gugick-nospam@.quest.com> wrote in message
news:%23YygmKIaFHA.1044@.TK2MSFTNGP10.phx.gbl...
> Jerry Spivey wrote:
> At most companies where I've worked in the past, we had development
> servers that were used strictly for development. They generally contained
> stripped down data from the production databases with any customer
> sensitive data masked. Lead developers generally had dbo rights and may
> even have admin rights depending on the size of the company. Version
> control software was used for all object changes. Initial application
> testing was done on the dev servers.
> QA/Test servers were not managed by development. They were usually owned
> by QA group. We would provide detailed scripts to update QA servers with
> the necessary changes. Users would test the applications on QA servers. QA
> servers have data that more closely mimics production in terms of data
> value distribution and quantity and may even be created from production
> backups. Sensitive data was not masked back then, as I recall, but it may
> have to be today. QA has the ability to reload the database in case the
> migration to QA fails. It's important to be able to always start from an
> exact copy of the production database schema.
> These days, you can use multiple SQL Server Instances to save hardware
> (assuming you have the necessary memory). VMs, while convenient, are
> probably not ideal for performance testing. But I'm not well informed
> about the capabilites of the server VM products.
> If everything tested ok, the updates were escalated to production.
> --
> David Gugick
> Quest Software
> www.imceda.com
> www.quest.com|||Jerry Spivey wrote:
> Thanks David.
> Looking into using named instances with EE to help control costs. Will
> be looking into implementing Visual SourceSafe as well.
> I noticed you work for Quest. I have a few questions about the Quest
> Central if you're open to them. Please email me if so.
> Thanks
> Jerry
>
The best way for you to get information and help with the Quest product
line is to contact sales. Our offices and numbers are located here:
http://www.quest.com/company/us_offices.asp
David Gugick
Quest Software
www.imceda.com
www.quest.com|||Change management is the term.
hange_Mgt.
pdf" target="_blank">http://www.innovartis.co.uk/pdf/ In...Mgt.
pdf
This is a white paper on the subject using Source Control (Visual Source
Safe) as the back bone of the approach. The application DB Ghost
(www.dbghost.com) was built using this methodology.
regards,
Mark Baekdal
http://www.dbghost.com
http://www.innovartis.co.uk
+44 (0)208 241 1762
Build, Comparison and Synchronization from Source Control = Database change
management for SQL Server
"Jerry Spivey" wrote:

> Hi,
> I've been given the task of creating a dev/test environment. Currently we
> have several production applications using databases on a common SQL Serve
r.
> If changes are required, the developers are performing the changes on the
> production system - yea I know BAD,BAD,BAD - but I didn't set this up but
> instead inherited it. I'd like to configure a dev/test environment to mov
e
> the devs off of the production system and to faciliate their development o
f
> future projects coming up soon.
>
> How is your dev/test environment configured? I'm looking for a few exampl
es
> here that I can work with to implement our dev/test based on our budget an
d
> system capabilities.
> I.e., Each dev has their own sandbox or each dev shares a common dev env -
> then changes are implemented to test env (and by who - dev or dba - and
> how - scripts) etc... then scripted to deploy on prod systems etc... also
> we image/ghost systems or use VMs and also we use Visual SourceSafe to...
> Trying to come up with a solid game plan here.
> Thanks for any input.
> Jerry
>
>

Development - Production Data Access

Hello All,
I have been searching for a published document for Best Practices
concerning access levels based on roles. Should developers have more
than (if at all) select level access to production data? If I
understand (from multiple postings) that it is best to have:
1. Development (developers have extensive access levels)
2. Test (developers have restriced access levels)
and
3. Production (developers have none or select level access)
Our environment and budget only allows for items 1 and 3.
If any body could point me to a document from a 'reputable' source, I
would greatly appreciate it.

TIA
BillI don't have a reputable source for you, only some more opinions.

Practices obviously vary from place to place and will depend partly on
the size and complexity of your dev operation, your toolset, and on how
much support your developers need to do. If your developers have to
support systems in production then they may need some extra level of
access to the production environment.

One thing I would not want to compromise on: do not test only in a dev
environment. That's because it's important to have a separate a
deployment process for testing that mirrors the way you will deploy
changes to production. In my opinion that's the best way to ensure that
you only release to production exactly what is tested. That doesn't
necessarily mean you need physically separate servers - whether that's
necessary depends on what components are under test. In the case of SQL
Server it does mean you ought to at least have separate instances for
development and testing.

--
David Portas
SQL Server MVP
--|||Bill Willyerd (bwillyerd@.dshs.wa.gov) writes:
> I have been searching for a published document for Best Practices
> concerning access levels based on roles. Should developers have more
> than (if at all) select level access to production data? If I
> understand (from multiple postings) that it is best to have:
> 1. Development (developers have extensive access levels)
> 2. Test (developers have restriced access levels)
> and
> 3. Production (developers have none or select level access)
> Our environment and budget only allows for items 1 and 3.
> If any body could point me to a document from a 'reputable' source, I
> would greatly appreciate it.

I think it's difficult to come with a best practice here, because it
is likely to business-dependent.

If developers have full access to the production database, this means
that they address critical issues directly, and don't have to spend
half a day to get some sort of access.

On the the other hand, this also means that developers are able to
all sorts of silly stuff in production, and also get access to data
that is sensitive.

So here is obviously a trade-off. The more availability you need, the
more in security you need to sacrifice - or invest in procedures so
that when a developer needs to debug in production, he can get access
easily by some sort of approval procedure.

I fully agree with David's view that you need a test environment
separate from development. I'll chime in here and add that the
process of transferring code from different environments should
be performed through version control, and the source-countrol system
is the master for all code to test and production environments. (As
well as to development environment to some extent as well.)

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

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techin.../2000/books.asp|||"Bill Willyerd" <bwillyerd@.dshs.wa.gov> wrote in message
news:1123690516.767246.211860@.o13g2000cwo.googlegr oups.com...
> Hello All,
> I have been searching for a published document for Best Practices
> concerning access levels based on roles. Should developers have more
> than (if at all) select level access to production data? If I
> understand (from multiple postings) that it is best to have:
> 1. Development (developers have extensive access levels)
> 2. Test (developers have restriced access levels)
> and
> 3. Production (developers have none or select level access)
> Our environment and budget only allows for items 1 and 3.
> If any body could point me to a document from a 'reputable' source, I
> would greatly appreciate it.
> TIA
> Bill

In addition to David and Erlands' comments, you might want to consider
Sarbanes-Oxley compliance. As a general comment, SOX compliance requires a
separation of duties (and therefore permissions) between development and
production. As a result, it's often not even an option to allow to
developers change access in the production environment.

But as I understand it, what you have to do to comply with SOX is negotiated
with your external auditors, and it depends heavily on your internal
environment. So you may want to investigate what (if any) legal obligations
you have to consider, and what the precise implementation details are for
your situation. For what it's worth, in my environment developers have no
change access to UAT or production (db_datareader only), so all code and
scripts are deployed via an Operations team - this is great for SOX
purposes, but obviously it adds both cost and time.

Simon

Developer to Standard

We just finished development of a set of databases with Dev Edition and want
to move them into production. We'd like to use the same machine for the
production databases. We'd also like to uninstall Dev Edition and install
Standard.
What is the best way to move all of the databases from the old (Dev)
instance to the new (Standard) instance. We're not using any of the
'features' unique to Dev/Enterprise. Pretty basic stuff.
Thanks.
Mike Murphy
I would do a sp_detach_db to unattach your database (or you can do the same
for Enterprise Manager). Uninstall dev. Install Standard. Then do an
sp_attach_db (or the same from Enterprise Manager) to attach your database
files back to SQL Server.
"Mike Murphy" wrote:

> We just finished development of a set of databases with Dev Edition and want
> to move them into production. We'd like to use the same machine for the
> production databases. We'd also like to uninstall Dev Edition and install
> Standard.
> What is the best way to move all of the databases from the old (Dev)
> instance to the new (Standard) instance. We're not using any of the
> 'features' unique to Dev/Enterprise. Pretty basic stuff.
> Thanks.
> --
> Mike Murphy
|||Before you do anything to your configuration, get a good backup. Then you
can uninstall Dev, install standard and either restore from backup or
sp_attachdb to re-attach your database files.
But get that backup first.
"Mike Murphy" <MikeMurphy@.discussions.microsoft.com> wrote in message
news:9AD45589-7D05-4B5A-88BB-DE850C577F94@.microsoft.com...
> We just finished development of a set of databases with Dev Edition and
> want
> to move them into production. We'd like to use the same machine for the
> production databases. We'd also like to uninstall Dev Edition and install
> Standard.
> What is the best way to move all of the databases from the old (Dev)
> instance to the new (Standard) instance. We're not using any of the
> 'features' unique to Dev/Enterprise. Pretty basic stuff.
> Thanks.
> --
> Mike Murphy
|||Won't you want both development and live environments once you go into
production?
One point in addition to the other responses. Dev Ed is equivalent to
Enterprise Ed not Standard. As the feature set is slightly different I
suggest you test on a Standard Ed installation before you go into
production. Of course that should happen anyway. Never test only in the Dev
environment.
David Portas
SQL Server MVP

Developer to Standard

We just finished development of a set of databases with Dev Edition and want
to move them into production. We'd like to use the same machine for the
production databases. We'd also like to uninstall Dev Edition and install
Standard.
What is the best way to move all of the databases from the old (Dev)
instance to the new (Standard) instance. We're not using any of the
'features' unique to Dev/Enterprise. Pretty basic stuff.
Thanks.
--
Mike MurphyI would do a sp_detach_db to unattach your database (or you can do the same
for Enterprise Manager). Uninstall dev. Install Standard. Then do an
sp_attach_db (or the same from Enterprise Manager) to attach your database
files back to SQL Server.
"Mike Murphy" wrote:
> We just finished development of a set of databases with Dev Edition and want
> to move them into production. We'd like to use the same machine for the
> production databases. We'd also like to uninstall Dev Edition and install
> Standard.
> What is the best way to move all of the databases from the old (Dev)
> instance to the new (Standard) instance. We're not using any of the
> 'features' unique to Dev/Enterprise. Pretty basic stuff.
> Thanks.
> --
> Mike Murphy|||Before you do anything to your configuration, get a good backup. Then you
can uninstall Dev, install standard and either restore from backup or
sp_attachdb to re-attach your database files.
But get that backup first.
"Mike Murphy" <MikeMurphy@.discussions.microsoft.com> wrote in message
news:9AD45589-7D05-4B5A-88BB-DE850C577F94@.microsoft.com...
> We just finished development of a set of databases with Dev Edition and
> want
> to move them into production. We'd like to use the same machine for the
> production databases. We'd also like to uninstall Dev Edition and install
> Standard.
> What is the best way to move all of the databases from the old (Dev)
> instance to the new (Standard) instance. We're not using any of the
> 'features' unique to Dev/Enterprise. Pretty basic stuff.
> Thanks.
> --
> Mike Murphy|||Won't you want both development and live environments once you go into
production?
One point in addition to the other responses. Dev Ed is equivalent to
Enterprise Ed not Standard. As the feature set is slightly different I
suggest you test on a Standard Ed installation before you go into
production. Of course that should happen anyway. Never test only in the Dev
environment.
--
David Portas
SQL Server MVP
--

Developer to Standard

We just finished development of a set of databases with Dev Edition and want
to move them into production. We'd like to use the same machine for the
production databases. We'd also like to uninstall Dev Edition and install
Standard.
What is the best way to move all of the databases from the old (Dev)
instance to the new (Standard) instance. We're not using any of the
'features' unique to Dev/Enterprise. Pretty basic stuff.
Thanks.
--
Mike MurphyI would do a sp_detach_db to unattach your database (or you can do the same
for Enterprise Manager). Uninstall dev. Install Standard. Then do an
sp_attach_db (or the same from Enterprise Manager) to attach your database
files back to SQL Server.
"Mike Murphy" wrote:

> We just finished development of a set of databases with Dev Edition and wa
nt
> to move them into production. We'd like to use the same machine for the
> production databases. We'd also like to uninstall Dev Edition and install
> Standard.
> What is the best way to move all of the databases from the old (Dev)
> instance to the new (Standard) instance. We're not using any of the
> 'features' unique to Dev/Enterprise. Pretty basic stuff.
> Thanks.
> --
> Mike Murphy|||Before you do anything to your configuration, get a good backup. Then you
can uninstall Dev, install standard and either restore from backup or
sp_attachdb to re-attach your database files.
But get that backup first.
"Mike Murphy" <MikeMurphy@.discussions.microsoft.com> wrote in message
news:9AD45589-7D05-4B5A-88BB-DE850C577F94@.microsoft.com...
> We just finished development of a set of databases with Dev Edition and
> want
> to move them into production. We'd like to use the same machine for the
> production databases. We'd also like to uninstall Dev Edition and install
> Standard.
> What is the best way to move all of the databases from the old (Dev)
> instance to the new (Standard) instance. We're not using any of the
> 'features' unique to Dev/Enterprise. Pretty basic stuff.
> Thanks.
> --
> Mike Murphy|||Won't you want both development and live environments once you go into
production?
One point in addition to the other responses. Dev Ed is equivalent to
Enterprise Ed not Standard. As the feature set is slightly different I
suggest you test on a Standard Ed installation before you go into
production. Of course that should happen anyway. Never test only in the Dev
environment.
David Portas
SQL Server MVP
--

Developer edition performance

Hi,
Is the developer edition of SQL Server 2000 *exactly* the same as the
enterprise edition - just without the production license?
It is mainly the performance aspect I am interested in. Standard edition is
limited to a low number of concurrent users & worker processes - is this
true with the deve edition.
Thanks in advance,
Stu> Is the developer edition of SQL Server 2000 *exactly* the same as the
> enterprise edition - just without the production license?
Yes.

> Standard edition is
> limited to a low number of concurrent users & worker processes
Who told you that? SE is not limited in concurrent users etc, it lacks a few
features that EE has,
like failover clustering, using lots of memory, some parallelization etc.
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Stu Lock" <s.lock@.cergis.com> wrote in message news:evIfU7AYEHA.3536@.TK2MSFTNGP11.phx.gbl..
.
> Hi,
> Is the developer edition of SQL Server 2000 *exactly* the same as the
> enterprise edition - just without the production license?
> It is mainly the performance aspect I am interested in. Standard edition i
s
> limited to a low number of concurrent users & worker processes - is this
> true with the deve edition.
> Thanks in advance,
> Stu
>|||It is the developer edition and personal edition which have some
limitations, not the standard edition... The limitation is not the number of
concurrent users, but limited in the number of worker threads. This prevents
you from using the dev or personal edition as a ig production server,
because performance will not be acceptable...
Wayne Snyder, MCDBA, SQL Server MVP
Mariner, Charlotte, NC
www.mariner-usa.com
(Please respond only to the newsgroups.)
I support the Professional Association of SQL Server (PASS) and it's
community of SQL Server professionals.
www.sqlpass.org
"Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote in
message news:eRaAFYBYEHA.2364@.TK2MSFTNGP12.phx.gbl...
> Yes.
>
> Who told you that? SE is not limited in concurrent users etc, it lacks a
few features that EE has,
> like failover clustering, using lots of memory, some parallelization etc.
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
> http://www.solidqualitylearning.com/
>
> "Stu Lock" <s.lock@.cergis.com> wrote in message
news:evIfU7AYEHA.3536@.TK2MSFTNGP11.phx.gbl...
is[vbcol=seagreen]
>

Developer edition performance

Hi,
Is the developer edition of SQL Server 2000 *exactly* the same as the
enterprise edition - just without the production license?
It is mainly the performance aspect I am interested in. Standard edition is
limited to a low number of concurrent users & worker processes - is this
true with the deve edition.
Thanks in advance,
Stu
> Is the developer edition of SQL Server 2000 *exactly* the same as the
> enterprise edition - just without the production license?
Yes.

> Standard edition is
> limited to a low number of concurrent users & worker processes
Who told you that? SE is not limited in concurrent users etc, it lacks a few features that EE has,
like failover clustering, using lots of memory, some parallelization etc.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Stu Lock" <s.lock@.cergis.com> wrote in message news:evIfU7AYEHA.3536@.TK2MSFTNGP11.phx.gbl...
> Hi,
> Is the developer edition of SQL Server 2000 *exactly* the same as the
> enterprise edition - just without the production license?
> It is mainly the performance aspect I am interested in. Standard edition is
> limited to a low number of concurrent users & worker processes - is this
> true with the deve edition.
> Thanks in advance,
> Stu
>
|||It is the developer edition and personal edition which have some
limitations, not the standard edition... The limitation is not the number of
concurrent users, but limited in the number of worker threads. This prevents
you from using the dev or personal edition as a ig production server,
because performance will not be acceptable...
Wayne Snyder, MCDBA, SQL Server MVP
Mariner, Charlotte, NC
www.mariner-usa.com
(Please respond only to the newsgroups.)
I support the Professional Association of SQL Server (PASS) and it's
community of SQL Server professionals.
www.sqlpass.org
"Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote in
message news:eRaAFYBYEHA.2364@.TK2MSFTNGP12.phx.gbl...
> Yes.
>
> Who told you that? SE is not limited in concurrent users etc, it lacks a
few features that EE has,
> like failover clustering, using lots of memory, some parallelization etc.
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
> http://www.solidqualitylearning.com/
>
> "Stu Lock" <s.lock@.cergis.com> wrote in message
news:evIfU7AYEHA.3536@.TK2MSFTNGP11.phx.gbl...[vbcol=seagreen]
is
>