Red Gate forums :: View topic - SQL Source Control Storing Files for Each User Account
Return to www.red-gate.com RSS Feed Available

Search  | Usergroups |  Profile |  Messages |  Log in  Register 
Go to product documentation
SQL Source Control EAP
SQL Source Control EAP forum

SQL Source Control Storing Files for Each User Account

Search in SQL Source Control EAP forum
This forum is locked: you cannot post, reply to, or edit topics.   This topic is locked: you cannot edit posts or make replies.
Jump to:  
Author Message
jfennell



Joined: 01 Apr 2010
Posts: 32

PostPosted: Wed May 19, 2010 5:10 pm    Post subject: SQL Source Control Storing Files for Each User Account Reply with quote

Hi,

I have a server that multiple developers log into. It seems that each developer needs to link a database to source control separately from their own account, even though they are connecting to the same database on the same SQL server. This doesn't seem to make sense. I would think that once a database is linked to the repository, it should be linked for all users.

This also appears to have caused a situation where when I look at the database with one of my users, a particular change appears on the Get Latest tab as something that needs to be applied to the database from source control, while with another user it appears that the user has modified the database to "un-do" the change that was committed to the repository and that change needs to be committed to the database.

Do you have any thoughts on the possible conflicts that could be caused by multiple users seeing different things when looking at the same database linked to the same repository?

Let me know if it would be easier to discuss over the phone and we can work something out.

Thanks in advance,
_________________
~ Jim Fennell
Back to top
View user's profile Send private message
jfennell



Joined: 01 Apr 2010
Posts: 32

PostPosted: Wed May 19, 2010 8:15 pm    Post subject: Reply with quote

Hi again,

I found and read your "Development and Deployment Recommendations" - http://www.red-gate.com/MessageBoard/viewtopic.php?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...
_________________
~ Jim Fennell
Back to top
View user's profile Send private message
sherr



Joined: 19 Mar 2009
Posts: 125
Location: Cambridge

PostPosted: Wed May 19, 2010 8:39 pm    Post subject: SQL Source Control Storing Files for Each User Account Reply with quote

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 Smile
SQL Source Control - Project Manager
Back to top
View user's profile Send private message
jfennell



Joined: 01 Apr 2010
Posts: 32

PostPosted: Wed May 19, 2010 9:46 pm    Post subject: Reply with quote

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!!
_________________
~ Jim Fennell
Back to top
View user's profile Send private message
jfennell



Joined: 01 Apr 2010
Posts: 32

PostPosted: Wed May 19, 2010 9:54 pm    Post subject: Reply with quote

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. Crying or Very sad

Any idea when that functionality will be added to SQL Compare? I think that would be the best solution for us.
_________________
~ Jim Fennell
Back to top
View user's profile Send private message
David Atkinson



Joined: 05 Dec 2005
Posts: 1113

PostPosted: Wed May 19, 2010 11:07 pm    Post subject: Reply with quote

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
Back to top
View user's profile Send private message Send e-mail
Display posts from previous:   
This topic is locked: you cannot edit posts or make replies. All times are GMT + 1 Hour
Page 1 of 1

 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group