22 comments

Add a comment…

Sign in

prestine

Your email address

Check!

invalid email

(thinking…)

Reset

or sign in with

• 
• 

UserVoice password

Forgot password?

Create a password

Your name

I agree to the terms of service

You'll receive a confirmation email with a link to create a password (optional).

Signed in as (Sign out)

Close

Close

Post comment Submitting...

• Brad commented  ·  February 03, 2012 07:14  ·  Flag as inappropriate  ·  Delete

  This will be a great feature and a deal clincher with management to purchase this product. Trying to resolve conflicts and merge changes of parallel development has wasted too much time in the past and it would be far nicer, safer and simpler if changes were done exclusively. If that's not possible, then even a notification that someone else has made changes that haven't been committed yet would be a good start.

• David Feiler commented  ·  January 04, 2012 10:25  ·  Flag as inappropriate  ·  Delete

  I agree; we need this lock functionality, or we won't really be able to use the integration. We rely on this to avoid conflicts

• zacuke commented  ·  September 08, 2011 17:24  ·  Flag as inappropriate  ·  Delete

  We are considering using SVN-Lock to prevent multiple people from editing one object in a shared database environment.

• Alex commented  ·  June 22, 2011 07:58  ·  Flag as inappropriate  ·  Delete

  I also vote fore Check-In/Check-Out option.

• AdminDavid Atkinson (Admin, Red Gate) commented  ·  June 20, 2011 13:49  ·  Flag as inappropriate  ·  Delete

  @Seth - which is more important, preventing another user from modifying an object you're working on, or letting them know that you're working on it, so they work on it at their own risk?

• Seth commented  ·  June 20, 2011 13:40  ·  Flag as inappropriate  ·  Delete

  I too vote for this. Being able to lock an object you are working on so that other developers know that you are working on it is a must. We still use the product and like it a lot, but this would be a great feature to have.

• AdminDavid Atkinson (Admin, Red Gate) commented  ·  May 31, 2011 16:16  ·  Flag as inappropriate  ·  Delete

  @Craig - are you all sharing a database, or do all developers have their own? What problems would you anticipate without this feature?

• Craig commented  ·  May 31, 2011 16:00  ·  Flag as inappropriate  ·  Delete

  I too would like to vote for this feature.. It seems fundamental to us for a multi-developer environment.
  This is an issue that is stopping us from implementing redgates SQL Source Control into our development processes.

• Will commented  ·  May 20, 2011 07:53  ·  Flag as inappropriate  ·  Delete

  I am going to vote for this. I'm having a hard time convincing my developers to use SQL Source Control due to this feature (and tagging as well, but that's another story). It's been my experience that most developers working on SQL Server "grew up" with Source Safe, in which exclusive checkout/SVN lock is the default behavior. I've worked extended periods of time in a non-Microsoft shop, so copy-modify-merge doesn't bother me. However, I am the exception.

• Ben commented  ·  March 16, 2011 15:22  ·  Flag as inappropriate  ·  Delete

  Well it would obviously prevent concurrency issues where if two of our developers were working on say the same stored procedure - the 2nd person in to execute their alter script would over-write the other person's changes, possibly without them even knowing. The same problem occurs when it comes time to check-in (or 'committ' as used in your software) the changes into your source control system.

  I guess one big thing to note is that i'm coming from an application development environment where we have a SQL DB backend, as opposed to just being dedicated DB developers. The standard model for app source control, as you're no doubt aware, is check-out the file (for simplicity we only allow single concurrent check outs) and obtain a lock on the file, perform your changes and check it back in. We're using TFS to do this. So it would be best if we can apply the same processes to managing the source for DB development.

  Now while your product appears unique (at least as opposed to using say a VS2010 DB project) in that it will detect changes in the DB automatically, (which is really, really nice) it just doesn't quite fit our preferred development process. But if you add DB object locking we'd have to versy seriously consider using your product. But at the moment, it looks like we'll probably start using VS2010 DB projects and perform all of our DB development from VS, rather than SMSS.

• AdminDavid Atkinson (Admin, Red Gate) commented  ·  March 16, 2011 11:22  ·  Flag as inappropriate  ·  Delete

  @Ben - could you let us know what is the primary reason that exclusive locking is important for you? In other words, what existing problem would the introduction of this feature solve for you?

• Ben commented  ·  March 15, 2011 15:47  ·  Flag as inappropriate  ·  Delete

  An option for exclusive lock out is a must. The SSMS add-in should handle checking objects out both in the source control software (eg TFS) and within SSMS. That SQL Source Control does not currently do this is pretty much the only reason we won't be using it in our development environment

• Ed M commented  ·  February 03, 2011 06:13  ·  Flag as inappropriate  ·  Delete

  I'm not necessarily sure I object to multiple people checking out the same object, but being able to see who already has it checked out would help inform the decision to work on it / consult colleague or not.

• Eric Wahner commented  ·  January 31, 2011 12:41  ·  Flag as inappropriate  ·  Delete

  I think this has to be included in the software to have a real acceptance. Far too many times developers will be working on complex queries and to not understand that someone else is already working on that object can be a huge time sink.

• Phoebe commented  ·  January 19, 2011 17:40  ·  Flag as inappropriate  ·  Delete

  We would definately use this feature (automatically lock object), it provides a level of safety when having multiple developers working in the same database. We would require it to work with SVN.

• Tom Graham commented  ·  January 12, 2011 12:56  ·  Flag as inappropriate  ·  Delete

  We need the ability to set up an entire repository with "only allow exclusively checked out source to be checked in" function, as well a "check out exclusively" function.
  Other people could still look at the source, copy the source, do whatever with the source, but only the person who got the exclusive check out can check their source back in. Or they can cancel the exclusive check out.
  Please give me this!!!

• Dat commented  ·  December 29, 2010 10:00  ·  Flag as inappropriate  ·  Delete

  + 1 on the lock option.

• Mike Fulkerson commented  ·  December 07, 2010 10:51  ·  Flag as inappropriate  ·  Delete

  Definitely would love to see a lock option.

• FunkyDexter commented  ·  October 14, 2010 02:40  ·  Flag as inappropriate  ·  Delete

  We'd really want this before we took up the product. Knowing you're working on the latest version of the code and that nobody else is putting your changes in jeapordy seems fundamental. I've never liked the merge model because it's too easy for a careless developer to muck up another's work.

• AdminStephanie (Admin, Red Gate) commented  ·  September 17, 2010 03:21  ·  Flag as inappropriate  ·  Delete

  Would you also want an option to do this automatically? If so, vote/comment at http://redgate.uservoice.com/forums/39019-sql-source-control/suggestions/1016301-auto-checkout-from-tfs-on-modify-of-sql-object-an.