Is there a way that I can keep the program from checking out everything that I just want to see the definition on?

For instance if I just want to use a script or see a procedure definition there isn't any reason to check the object out.

I like the way that visual studio will let you look at the file but it won't check it out until you make a change to it. That makes would work for database objects but when you are using a saved script lots of times you don't want to save any change you may have made. Say that I have a script "look at all customer history". I open it up and change it just enough to run for the new client. I don't want to save the changes or un-do the check out.

Thanks!

By default an object is opened in Edit Mode (i.e. checked out) when you double-click on it.  You can You can change this default behavior in Tools > Options, under the Summary tab, un-check the option "Double-Click Opens in Edit Mode".

Thereafter, if you make a change in the script/object it is automatically checked out as in visual studio.

 

---

SQLDBcontrol Support

support@sqldbcontrol.com

This is a good behavior for most cases. What I would like to be able to do is open and run a script, possibly even edit it, without having to check it out. I can see why you would want the db objects to be checked out as soon as you started to edit them but for me and the two other users here we would like it if in the future you could open and run a script without having to check it out. Thanks!

Also, my buddy has a script checked out and I cannot run it. That would work for most DB objects but not really for the way we use the scripts object. You can create a new script but if you were not required to check out the script to run it then this would not be a problem. Thanks!

It shouldn't be a problem to modify the code to enable you to execute a script in the way you suggest but we'd limit that behavior to just scripts rather than objects like procedures, views, etc.

 

---

SQLDBcontrol Support

support@sqldbcontrol.com

Actually,

it turns out that this is the current behaviour.  If you open up a script for viewing only you can still execute the script or parts of it by selecting the individual statements you want to execute.

If you're unable to do so let me know because that would be a bug if that's the case.

We've made the necessary changes that allow you to edit scripts even if they are checked out by other users.  However, as you'd expect, you won't be able to save an edited script until you're able to check out the script yourself.

---

SQLDBcontrol Support

support@sqldbcontrol.com

I appreciate you getting back with me so quick on all of the things I have posted about. To test this I opened up a script without checking it out. I then highlighted a block of code and the execute arrow did not turn green and F5 didn't do anything. I am on version 2.1.000.40 Is there an option that I need to set to get this? Thanks!

That is strange.  There is no option to turn this feature on/off and it's been implemented for quite a while.

I've just checked and I've noticed that when working on a script that is associated with a database this isn't working as expected.  However, if you're working on a script within the T-SQL Script Explorer the Execute buttons (and F5) should be enabled from the moment the editor is opened.

Can you confirm whether you're testing this on a script within the T-SQL script explorer?

We'll fix the issue for scripts associated with databases.

If you still can't execute within a script then perhaps the best thing is for me to direct you to one of our more recent, stable, builds.  Or if you have a test environment (in reality you only need to create a copy of the source control database for testing) then we can give you the latest build that includes some the other changes we've recently made.

---

SQLDBcontrol Support

support@sqldbcontrol.com

We generally use the scripts under the database rather than the script explorer. Having two places to save scripts was a little confusing when we first started. We just settled on using the one below the database rather than the script explorer. When we use it, the explorer is for private scripts only pretty much.

We've fixed the issue so that the behavior is the same for scripts under the databases.

The truth is we initially set off on having scripts under each database.  And then users pointed out that this wasn't ideal because their scripts weren't database specific and they could be run against many different databases.

So based on that we created the script explorer, which probably has a bit more flexibility in terms of managing and grouping scripts.

At that point, the problem was that some users quite liked having scripts associated with their databases so we kept the original implementation in place.  The only thing to bear in mind with scripts under databases is that if you remove the database the scripts go as well.  And if you wanted to you can copy/move these scripts (by dragging and dropping) into folders in the T-SQL Script Explorer. 

---

SQLDBcontrol Support

support@sqldbcontrol.com

Did you know that if you double click on a script under the script explorer it will check it out?

If you double click on it under the summary window it works according to the setting under the options panel.

It seems to me that it should behave the same way, both according to the option setting.

Thanks!

That's a bug and, as you pointed out, it should behave according to the option setting.

Thanks for spotting this.

---

SQLDBcontrol Support

support@sqldbcontrol.com