SQL Clone
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 


The Importance of Consistent Server Setup


The Importance of Consistent Server Setup

Author
Message
bkubicek
bkubicek
SSChampion
SSChampion (10K reputation)SSChampion (10K reputation)SSChampion (10K reputation)SSChampion (10K reputation)SSChampion (10K reputation)SSChampion (10K reputation)SSChampion (10K reputation)SSChampion (10K reputation)

Group: General Forum Members
Points: 10326 Visits: 1099
Comments posted to this topic are about the item The Importance of Consistent Server Setup
henrik staun poulsen
henrik staun poulsen
SSCertifiable
SSCertifiable (5.8K reputation)SSCertifiable (5.8K reputation)SSCertifiable (5.8K reputation)SSCertifiable (5.8K reputation)SSCertifiable (5.8K reputation)SSCertifiable (5.8K reputation)SSCertifiable (5.8K reputation)SSCertifiable (5.8K reputation)

Group: General Forum Members
Points: 5808 Visits: 1353
Hi Ben,

When I see code that hard-code a database name, I shudder. It must be really old code, because today I prefer to create an abstraction layer, ie. a view that references that table in the other database.
Then I have a sproc that re-creates all those views, whenever the database name changes.

I agree that it is a good idea to have similar environments, so that dev., test and production servers look and feel the same.

Best regards
Henrik



jay-h
jay-h
SSCoach
SSCoach (18K reputation)SSCoach (18K reputation)SSCoach (18K reputation)SSCoach (18K reputation)SSCoach (18K reputation)SSCoach (18K reputation)SSCoach (18K reputation)SSCoach (18K reputation)

Group: General Forum Members
Points: 18331 Visits: 2846
We run parallel, but not identical names for the databases, servers and tables
company_Prod_Price_List
company_Dev_Price_list

Helps keep people straight as to where they're working and avoids accidently running a script on the wrong db.

...

-- FORTRAN manual for Xerox Computers --
RonKyle
RonKyle
SSC-Dedicated
SSC-Dedicated (30K reputation)SSC-Dedicated (30K reputation)SSC-Dedicated (30K reputation)SSC-Dedicated (30K reputation)SSC-Dedicated (30K reputation)SSC-Dedicated (30K reputation)SSC-Dedicated (30K reputation)SSC-Dedicated (30K reputation)

Group: General Forum Members
Points: 30320 Visits: 4659
Different clients have different setups. But one for which I do the most development set up a very consistent Dev and Prod environment and it makes things so much easier. At the last place I was an employee, we had a very consistent setup for DEV, TEST, and PROD. Again made things so much easier.



IowaDave
IowaDave
SSCommitted
SSCommitted (1.5K reputation)SSCommitted (1.5K reputation)SSCommitted (1.5K reputation)SSCommitted (1.5K reputation)SSCommitted (1.5K reputation)SSCommitted (1.5K reputation)SSCommitted (1.5K reputation)SSCommitted (1.5K reputation)

Group: General Forum Members
Points: 1524 Visits: 670
jay-h - Friday, October 12, 2018 7:23 AM
We run parallel, but not identical names for the databases, servers and tables
company_Prod_Price_List
company_Dev_Price_list

Helps keep people straight as to where they're working and avoids accidently running a script on the wrong db.


We do as well. In fact, I just assumed everyone did it that way. Ben's editorial gave me food for thought ...
LoriB
LoriB
SSC-Enthusiastic
SSC-Enthusiastic (113 reputation)SSC-Enthusiastic (113 reputation)SSC-Enthusiastic (113 reputation)SSC-Enthusiastic (113 reputation)SSC-Enthusiastic (113 reputation)SSC-Enthusiastic (113 reputation)SSC-Enthusiastic (113 reputation)SSC-Enthusiastic (113 reputation)

Group: General Forum Members
Points: 113 Visits: 318
Bane of my current job: not only are dev, test\QA and production database names different, the schemas within each are different as well. So inside the dev database I have devschema.table, inside QA it is qaschema.table, and in production it is prodschema.table. I have yet to find a code compare tool that can handle this issue. Sure, I can ignore schema on object existence, but the code within the stored procedures? If you know of one, please do share. We do not have any sort of source control in our shop, I worked with a TFS expert at Microsoft, and he pretty much threw in the towel after a few hours. It's on my to-do list for the next year, to implement some sort of source control on database objects. I'm afraid I'm going to have to invent my own at this point. No one to blame for this head-shaker except the vendor who designed the application this way.
bkubicek
bkubicek
SSChampion
SSChampion (10K reputation)SSChampion (10K reputation)SSChampion (10K reputation)SSChampion (10K reputation)SSChampion (10K reputation)SSChampion (10K reputation)SSChampion (10K reputation)SSChampion (10K reputation)

Group: General Forum Members
Points: 10326 Visits: 1099
LoriB - Wednesday, November 21, 2018 4:20 PM
Bane of my current job: not only are dev, test\QA and production database names different, the schemas within each are different as well. So inside the dev database I have devschema.table, inside QA it is qaschema.table, and in production it is prodschema.table. I have yet to find a code compare tool that can handle this issue. Sure, I can ignore schema on object existence, but the code within the stored procedures? If you know of one, please do share. We do not have any sort of source control in our shop, I worked with a TFS expert at Microsoft, and he pretty much threw in the towel after a few hours. It's on my to-do list for the next year, to implement some sort of source control on database objects. I'm afraid I'm going to have to invent my own at this point. No one to blame for this head-shaker except the vendor who designed the application this way.


This is just an idea, so I am not totally sure it will work since I haven't experienced your situation. Still, what if you use synonyms? This way you could obscure the underlying dev/qa/prod schema issues. Then at least your stored procs could be the same on all of the databases. I am not sure if redgate sql data compare works on synonyms or not. Anyway, it is an idea, perhaps it will work for you.
Ben
Go


Permissions

You can't post new topics.
You can't post topic replies.
You can't post new polls.
You can't post replies to polls.
You can't edit your own topics.
You can't delete your own topics.
You can't edit other topics.
You can't delete other topics.
You can't edit your own posts.
You can't edit other posts.
You can't delete your own posts.
You can't delete other posts.
You can't post events.
You can't edit your own events.
You can't edit other events.
You can't delete your own events.
You can't delete other events.
You can't send private messages.
You can't send emails.
You can read topics.
You can't vote in polls.
You can't upload attachments.
You can download attachments.
You can't post HTML code.
You can't edit HTML code.
You can't post IFCode.
You can't post JavaScript.
You can post emoticons.
You can't post or upload images.

Select a forum









































































































































































SQLServerCentral


Search