October 11, 2018 at 9:11 pm
Comments posted to this topic are about the item The Importance of Consistent Server Setup
October 12, 2018 at 12:26 am
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
October 12, 2018 at 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.
...
-- FORTRAN manual for Xerox Computers --
October 12, 2018 at 7:54 am
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.
October 12, 2018 at 8:26 am
jay-h - Friday, October 12, 2018 7:23 AMWe run parallel, but not identical names for the databases, servers and tables
company_Prod_Price_List
company_Dev_Price_listHelps 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 ...
November 21, 2018 at 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.
November 21, 2018 at 5:29 pm
LoriB - Wednesday, November 21, 2018 4:20 PMBane 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
Viewing 7 posts - 1 through 6 (of 6 total)
You must be logged in to reply to this topic. Login to reply