| Author |
Topic |
|
nancy_lee
Starting Member
18 Posts |
 Posted - 2002-12-03 : 10:12:47
|
| I would appreciate if someone could give me some information regarding stored procs version control. Something that works like visual sourcsafe. I did not find any articles in Microsoft site which discuss this.Thanks! |
|
|
nr
SQLTeam MVY
12543 Posts |
Posted - 2002-12-03 : 10:16:49
|
| www.nigelrivett.comAdministering SQL Server Release ControlMust complete the new versiopn of this sometime.==========================================Cursors are useful if you don't know sql.DTS can be used in a similar way.Beer is not cold and it isn't fizzy. |
 |
|
|
nancy_lee
Starting Member
18 Posts |
Posted - 2002-12-03 : 10:40:36
|
| Thanks nr.I wonder if there is anything that's built in in the sql server instance so I don't have to go to vss to check out each time I make a change... something like a drop down in vb.thanks again ! |
|
|
|
nr
SQLTeam MVY
12543 Posts |
Posted - 2002-12-03 : 11:29:41
|
| I think interdev may be integrated with sourcesafe - never used it myself, prefer to do things manually.==========================================Cursors are useful if you don't know sql.DTS can be used in a similar way.Beer is not cold and it isn't fizzy. |
|
|
|
nancy_lee
Starting Member
18 Posts |
Posted - 2002-12-03 : 11:41:20
|
| Yes, interdeve is integrated with VSS, but what about SQL server 2000 ? Is there anything in SQL server with the same nature ? |
|
|
|
tool
Starting Member
26 Posts |
Posted - 2002-12-03 : 13:59:45
|
| In his book "The Guru's Guide to SQL Server Stored Procedures, XML, and HTML" Ken Henderson talks about how to integrate VSS and QA through the use of VSS's command line utility. I've never tried it myself but it seemed like a pretty slick setup back when I read about it. |
|
|
|
robvolk
Most Valuable Yak
15732 Posts |
Posted - 2002-12-03 : 15:27:27
|
| Yes, get Ken Henderson'sThe Guru's Guide to SQL Server Stored Procedures, XML, and HTMLNot only does it describe how to integrate VSS into Query Analyzer (so simple you won't believe it, takes you maybe 2 minutes to do) it also has tons of other priceless stuff in it. You can order it through Amazon via the SQL Team Bookstore. |
|
|
|
nancy_lee
Starting Member
18 Posts |
Posted - 2002-12-03 : 16:43:27
|
| thank you all for the recommendation ... I'll go look for it ... |
|
|
|
Sitka
Aged Yak Warrior
571 Posts |
Posted - 2002-12-10 : 13:47:32
|
From Henderson's book..To add an external tool to the Query Analyzer Tools menu, click theTools|Customize menu option....say what, is this not available on SQL7 cause I can't find it? Voted best SQL forum nickname...."Tutorial-D" |
|
|
|
Sitka
Aged Yak Warrior
571 Posts |
Posted - 2002-12-20 : 16:16:57
|
| For sure it is not able to run on SQL 7.But on 2000 it is pretty cool,So for those of you who use the Henderson example do you setup you working folder as a local one or do you use the "near"(once removed from the database) scripts store on your server or network share as your working directory ?(No wait that isn't right. The near scripts storage exists not only as a source for versioning control but also as a means for getting an app back up and running without a restore) It seems with just me here it makes sense to use just the one directory stucture but then you still need to change the working folder often to stick with the project tree structure demoed by Henderson and nr. "Talk to me...like I am a child." Would best sum it up because this is the first time I've started using VSS. Once I saw the split screen view I was sold though and am even more convinced this is the bomb since I spent all of today trying to clean up a proliferation of sprocs that just kind of seem to gather when people start asking "is it done yet" And rather than start a new area of reports for some accounting types right away I figured I'd be saving tons of time if I could reference the progression of edits so easily. ("Mongo forget stuff, bad Mongo")Anyways it is true that the book gets you up and running quick. I would recommend running the command arguements from a prompt to get a better feel for the little chart on page 113.This is one of those times when it sucks to work alone. Because I can see getting a little flow going with VSS and then realizing oops, it should have been over here, and my working directory should have been over there, and the project stucture should nest a documentation folder too, and the VSS install should be on that machine, etc. etc. etc. Anyways.....Voted best SQL forum nickname...."Tutorial-D" |
|
|
|
ValterBorges
Master Smack Fu Yak Hacker
1429 Posts |
Posted - 2002-12-20 : 17:36:50
|
| While were on the topic.Does anyone know what the stored procedureslike dt_addtosourcecontrol are used for.Are they used to implement source control integration via visual studio? |
|
|
|
robvolk
Most Valuable Yak
15732 Posts |
Posted - 2002-12-20 : 18:19:25
|
| Yes. They integrate with VSS and the Visual Studio tools. |
|
|
|
Sitka
Aged Yak Warrior
571 Posts |
Posted - 2003-01-09 : 14:35:54
|
| Well just got to the point where I'm starting to groove with this VSSintegration. Weeeeeeeeeeeeeeeeeeeeeeeee.Pure love when you go back and see the history.Man it rocks.Voted best SQL forum nickname...."Tutorial-D"Edited by - sitka on 01/09/2003 14:36:21 |
|
|
|
setbasedisthetruepath
Used SQL Salesman
992 Posts |
Posted - 2003-01-09 : 14:42:24
|
| The SourceSafe integration with SQL Server is terrible. NOTHING in the current scheme prevents a developer from modifying a stored procedure outside the scope of VSS, which is (of course) entirely what source code control is supposed to prevent. Perhaps Yukon will remedy this ...Jonathan{0} |
|
|
|
tkizer
Almighty SQL Goddess
38200 Posts |
Posted - 2003-01-09 : 14:47:47
|
| What value does it add by adding VSS to the tools menu? It only saves you a few clicks. Is there more to the integration than just adding it to the tools menu?We use VSS here for our database objects. Developers make the changes on SQL Server, then when they are ready to create a build of their application, they check in their code plus any database objects that have changed. I then grab all database objects that have changed since the last build and apply them to whatever environment that is going to receive the build. This works very well for us. |
|
|
|
robvolk
Most Valuable Yak
15732 Posts |
Posted - 2003-01-09 : 14:54:52
|
| NOTHING would stop you from comparing the current version to a previously checked in version either, if you suspect someone tampered with it. IIRC it will set the script files to have a read-only attribute, so whoever modifies it outside VSS would have to manually clear and then reset the attribute when they're done. And this would apply to any source file, not just SQL Server.The best bank vault in the world can't prevent the bank manager from stealing. If you don't trust the developers, get rid of them or enforce a procedure requiring them to behave. |
|
|
|
setbasedisthetruepath
Used SQL Salesman
992 Posts |
Posted - 2003-01-09 : 15:01:26
|
| I've also used VSS in that way; it works well provided each member of the development staff follows the rules. In my experience people rarely do on a consistent basis. The first time your build is buggy b/c you used VSS objects vs. the objects in the database, and a developer made a mistake, is the first time you start rethinking the process.Generally, source code control has little relevance to database objects since there is by nature a central repository where access is serialized. The only need for it is to 1) document a change list for an object (who and when, optionally why) and 2) to understand what has changed since a given date. Using VSS for the latter, what I'll call build control, is little better than typing it into Notepad since with both there's no assurance that developers have in fact done what they claimed to do.My issue with VSS integration isn't so much that it can't work; rather that the fundamental principle of source code control is to be bullet-proof, and VSS <-> SQL Server is not. If a developer can modify a database object without that object being checked out to him, the system is not providing the requisite security. There are no such safeguards currently.Jonathan{0} |
|
|
|
tkizer
Almighty SQL Goddess
38200 Posts |
Posted - 2003-01-09 : 15:13:45
|
quote:
I've also used VSS in that way; it works well provided each member of the development staff follows the rules. In my experience people rarely do on a consistent basis. The first time your build is buggy b/c you used VSS objects vs. the objects in the database, and a developer made a mistake, is the first time you start rethinking the process.
Well when a developer does not create the scripts correctly, which then either causes the build to fail or for the application to not work properly, I just go back to the developer and make them correct it in VSS. The developers do not have enough time to keep correcting the scripts in VSS, so they usually only make the mistake once. I provided instructions to them on how to generate the scripts for their database objects, so all they have to do is follow directions. Occassionally, SQL Server will put an alter statement in the script even though they asked for a drop and create (I thought that the developer made the mistake, but it was SQL Server. They had used EM to generate the scripts and asked for a drop and create, but it put in a drop and alter, which obviously will generate an error when it is run), so this is the only problem that I run into now. |
|
|
|
robvolk
Most Valuable Yak
15732 Posts |
Posted - 2003-01-09 : 15:16:39
|
quote:
If a developer can modify a database object without that object being checked out to him, the system is not providing the requisite security. There are no such safeguards currently.
Sure there are...DON'T GRANT THAT PERSON the permissions to make such changes. You said it yourself: databases are "by nature a central repository where access is serialized". SQL Server is perfectly capable of handling its own security and access. If you're gonna unlock and open its front and back doors it's pretty silly to complain about how the alarm system you bought didn't keep burglars out. Require that a specified point of contact/person/conduit be the only one who can actually deploy changes or modify objects, and make it impossible for others to do it themselves. I think you're trying to cast all the blame on the software's shortcomings when the problem can be easily solved with some simple precautions. |
|
|
|
setbasedisthetruepath
Used SQL Salesman
992 Posts |
Posted - 2003-01-09 : 15:31:39
|
quote:
I think you're trying to cast all the blame on the software's shortcomings when the problem can be easily solved with some simple precautions.
Not at all, the Microsoft development model by and large uses non-DBA's for database object creation, much as I think that is by and large a bad idea. Given that, it's often quite difficult to restrict object creation rights. Damn near impossible in some cases. I appreciate your point of view, and in a vacuum I would agree with it, but politics often negate that approach.Jonathan{0} |
|
|
|
Merkin
Funky Drop Bear Fearing SQL Dude!
4970 Posts |
Posted - 2003-01-09 : 17:05:23
|
Y'all are going to kill me for saying this. I was in the situation where most developers were using VSS, but one had to do some on the fly bug fixing so used Enterprise Manager on the live server.When the next release from VSS was rolled out to the live machine, a whole slew of bugs re-appeared  The solution : Encrypt the stored procs  **OK, it won't stop someone from making a change and not checking it in to source control, but you can rest assured that the live proc hasn't been touched, everything has been done with a script.Also, I have recently moved from VSS to CVS. It takes a little getting used to, but once you have, you will never go back. You realize why Microsoft don't use VSS themselves. Say goodbye to all the things you hate about VSS, corrupted repositries, slow to backup or archive, unusable over a slow network link etc etc etcAlso, there is a really cool tool called Tortoise CVS which integrates CVS with the explorer shell, so you can Right Click -> Get latestorRight Click -> CommitAll good!Damian** N.B. After answering countless posts here about "how do I decrypt my procedure so I can see the source code", I absolutely DO NOT RECOMMEND encrypting stored procs, UNLESS you have a good source control policy and a good backup policy. I have never lost any work due to an encrypted proc, because I am not bone-headed enough to do it without the proper controls in place  Edited by - merkin on 01/09/2003 17:12:34 |
|
|
|
Next Page
|
stored procedures version control