SQL Source Control Storing Files for Each User Account

• 
  Hi again,
  
  I found and read your "Development and Deployment Recommendations" - http://www.red-gate.com/MessageBoard/vi ... hp?t=11130 - after posting my message.
  
  There's some good information in there that applies to this question. I'm still curious what you would think of just having all developers share the same set of "internal working files" with SQL Source Control. I'm not sure if "internal working files" is the right terminology, but I hope you understand what I mean. If that's possible, it may alleviate some or all of the problems with the Shared Model.
  
  Just thinking...

  jfennell May 19, 2010 15:15

  - 0 +
• 
  Hello Jim,
  
  We realize that a lot of users work in a shared database model and hope to offer better support for this model in a future version.
  
  We considered sharing the same set of "internal working files" across all the developers, but this can lead to a few problems because you could actually connect to the database from SSMS on another machine and then you might not have access to these "internal working files."
  
  Another reason is SQL Source Control does not make any changes to the database. Therefore, there's no way for us to know if a different user has linked the database to source control or not.
  
  There are probably some other issues that we'll hit when we start to work on supporting this better.
  
  For now, linking the db is a one time thing, so I hope that is not too hard for each developer to do. If you have SSMS on a laptop and a desktop, you'll have to link each of these seperately because again, the "internal working files" are not shared.
  
  On a shared db model, getting latest doesn't really make sense unless changes are made directly to the source control system or committed externally. In most of these cases, as the development continues, these will disappear from the different lists once everything is in synch. The issues are definitely caused by the "internal working files" being out of synch. The more often users visit the commit tab, the less likely this will happen. For now, I hope you can just ignore some of these descrepancies and just concentrate on committing the objects that you have made changes too.
  
  I'm glad you found our recommendations post. I hope it helped.
  
  Thank you!
  Stephanie M. Herr :-)
  SQL Source Control - Project Manager

  StephanieHerr May 19, 2010 15:39

  - 0 +
• 
  Stephanie,
  
  Thanks for the quick response. The linking isn't a big deal at all, since as you mentioned it is only a one-time thing. It was just a surprise that it didn't show up on all users after one user did it, but now I see how things are working.
  
  We've been using the source control repository as a "go-between" for our integration environment, which is where we're seeing the discrepancies. Here's a description of the lifecycle we're trying to use for both code and SQL database changes:
  
  1) Developer makes a change locally and tests it locally.
  2) Change is committed from developer's local system to SVN repository.
  3) Developer then logs onto the integration server and retrieves changes from the repository using a "Get Latest"
  4) Developer builds the new application with the changes and tests that the changes integrated successfully with all other developers' changes.
  
  I know it's kind of an "unorthodox" way to use the source control repository, but it forces all of our developers to make sure things are in the repository.
  
  It's also given us a VERY smooth way to get database changes applied in our integration environment. Since the environment doesn't allow direct connections to the database server from an external network, passing them through the repository like this works like a charm and for the most part hasn't caused any problems. In fact, the only time I noticed an issue with inconsistencies between users is related to my other post from today (subject: Error Applying Changes from Get Latest).
  
  I'll review the recommendations post and see what else I come up with for solutions too. I know that if all developers logged into the same for committing database changes and performing builds we wouldn't have any "user-specific" discrepancies; that might be an option if it becomes a big problem, but I doubt it will.
  
  And hey, it's only just today released in beta! I'm sure the support for the shared database model will improve!
  
  Thanks again for the great work!!

  jfennell May 19, 2010 16:46

  - 0 +
• 
  Also, it looks like we could follow the suggestions you have written in the "Deploying changes to other environments (Dev > Test > Production)" section of the Development and Deployment Recommendations to synchronize the scripts folder to the database, but we only have SQL Compare, not SQL Compare Pro, so we can't synchronize to a scripts folder.
  
  Any idea when that functionality will be added to SQL Compare? I think that would be the best solution for us.

  jfennell May 19, 2010 16:54

  - 0 +
• 
  The ability to read and write to a set of scripts is one of SQL Compare Pro's differentiating features, so this will remain exclusively in the Pro edition. Our recommendation is that you upgrade to the Pro version. If you own a SQL Comparison Bundle, it might be cost effective to upgrade this to the SQL Developer Bundle, as this will also includes SQL Source Control as well as all the Pro versions of the other SQL developer tools in our suite.
  
  I read your workflow with interest. One thing you might like to consider is automating the deployment of your database to your integration server. You could set up a continuous integration process that does this each time a change is committed to source control. This can be easily achieved using the SQL Compare Pro command line, which is another reason to upgrade to this edition.
  
  Kind regards,
  
  David Atkinson
  Product Manager
  Red Gate Software

  David Atkinson May 19, 2010 18:07

  - 0 +

Add comment

Please sign in to leave a comment.