December 5, 2008 at 3:00 pm
Getting up and running on TFS 2005. I see that SSMS 2005 only hooks into VSS, but everything I read was from 2006 or earlier. Is this still the case? We use VS2005 Team Edition but NOT Database Edition. Any thoughts?
Also, what do folks do for versions of the physical dbs? I know we can version scripts to create/alter objects, but do folks actually keep various branch/main versions of the physical dbs too? Just looking for standard practices. Thanks!
December 6, 2008 at 3:03 pm
I just answered this question yesterday you cannot do database development in VS2005/8 Team edition you need either the database developer and Team Suites with the addin downloaded from the link below. The database versioning you need the database developer edition and team suites or buy Redgate database compare.
Kind regards,
Gift Peddie
December 8, 2008 at 6:50 am
Thanks. And what about the physical tables, sprocs, etc. Do you typically keep completely different physical db's for each version of the app you're supporting, like what's done with programming files in TFS/VSS?
December 8, 2008 at 8:56 am
I am a developer so my experience maybe different we had issues with our Database Server hardware failing many times so we each kept copies of the database and our team lead kept .baks in VSS so we can get up and running like nothing happened because we including the DBA did not have permissions to the SQL Server folder where the .baks are stored.
You could just swap out .baks at the end of the week because if these are new development there will be many changes to the database in one week. One more thing we needed the data architect ok to change DDL but we can create views.
Kind regards,
Gift Peddie
December 8, 2008 at 8:37 pm
Gift Peddie (12/8/2008)
I am a developer so my experience maybe different we had issues with our Database Server hardware failing many times so we each kept copies of the database and our team lead kept .baks in VSS so we can get up and running like nothing happened because we including the DBA did not have permissions to the SQL Server folder where the .baks are stored.
curious to know, you said that DBA did not have permissions to the SQL Server folder where the .baks are stored, then who takes care of backup and restore of database. Does your production server had hardware failure several times :w00t: seems scary.
December 8, 2008 at 8:52 pm
It was a development server not production so we the development team of about ten people take of what the DBA did not want to do because the Windows system admin refused to give him the correct permissions to access everything in the SQL Server folder. But we had hardware failure about three times in two months.
:Whistling:
Kind regards,
Gift Peddie
December 8, 2008 at 9:21 pm
Gift Peddie (12/8/2008)
It was a development server not production so we the development team of about ten people take of what the DBA did not want to do because the Windows system admin refused to give him the correct permissions to access everything in the SQL Server folder. But we had hardware failure about three times in two months.:Whistling:
Makes sense. but in my opinion, DBA should be involved in development environment too, not only to backup and restore but to take care of other administration stuff.
at my previous workplace, we were following similar rules where developers were kings in development environment and can do anything they wanted. They developed an application but when we tried to deploy it for UAT enviornment it didn't work. There were some DB settings which were not correctly set in development database which in turn didn't threw errors at development time. finally we have to ask the client for more time to fix the bugs in application code. i think all these things depend on business to business and above all managers. 🙂
December 8, 2008 at 9:36 pm
We are not king it was the system admin that was king because we cannot change DDL without the client data architect approval but this was a software engineering company so development was their main business but everything was controlled by the client staff on site and our code must deploy to the client remotely.
This was a development with ERD copy on every develper's cube and no changes.
Kind regards,
Gift Peddie
Viewing 8 posts - 1 through 7 (of 7 total)
You must be logged in to reply to this topic. Login to reply