does visual studio team system for database professionals incude source control
if yes, is the source control at the database level meaning if someone goes into Management Studio will they "see" that a stored procedure is currently checked-out and then they cannot modify that sp.
source control
DotNet_Student
Is this not an issue about proper procedures being put in place to ensure this doesn't happen Tools are all well and good but they have to be used properly. That would be the case with or without DBPro, would it not
Like Sachin said, DBPro is all about controlling the source code for objects, not the objects themselves. That's how I read his post anyway. We are using DBPro in my current project and the developers have free rein to go and create objects in the database and then we use Schema Compare to look at those changes and decide whether to sync them back into the DBPro project. Like I said, its all about procedures, which should define how the tools are used.
Or have I missed the point Apologies if so.
-Jamie
Tammt
Let me offer an alternative to what Sachin told you to do. He recommended all schema editing be done from within Visual Studio. I frankly think this is poor advice. And, in fact, if this is the only alternative we had, I wouldn't even consider using VSTE for DBPro.
Say you wanted to add a table, a couple keys and a couple constraints to your schema. Following Sachin's advice, you would need to create many new files in your DB project and know exactly where to put them, and know the correct syntax to create these objects. Can you imagine how tedious and error prone this would be This is very inefficient and a poor use of time. Here is what I have been doing. I have a local development database I make these types of schema changes in. After the changes are made (using Management Studio), I run the Schema Compare feature of DBPro. The source is my local development database and the target is my project. I then synch my local development database with my project. Viola! My project is has been updated painlessly and I didn't have to write a single T-SQL statement.
Oh, BTW, my DB project is under source control (TFS) and this works great!
Amos.
rwerner
there needs to be something to prevent a dev or dba from going to SSMS. Until then there exists a hole in the source control process in VSTS for database code.
ckob22
i am hoping to hear something that would make me switch to VSTS for source control. not hearing it.
Just so we are on the same page, the process we use is someone goes into VS(not VSTS) database project, checks out an sp, make changes, clicks "run", this deploys the sp to the shared development environment. And many shops out there like ours have a shared development database environment. very common.
Putting a database under source control is exactly what needs to happen to have 100% database source control.
As a starting point when someone goes into a SSMS database thats under VSTS source control, when they modify an sp give them a warning message in SSMS.
"commands completed successfully". "warning database code is under source control".
At least then the developer will be aware at that time and know to take his changes and put back into VSTS. Else his changes will most likely be lost.
or have some way to allow a sp modification in VSTS and not in SSMS.
And this is a developer AND a DBA problem. We have no way to stop a dev or dba from going into SSMS and modifying an object outside source control. And VSTS does nothing to address that. And I don't think procedures is the solution to this. I want VSTS and SSMS to solve this problem for me.
"DBPro is a developer tool - controlling objects in a database is a DBA job in my opinion."
- this makes no sense to me whatsoever. sorry. Modifying stored procedures can be done by a developer, a dba or a database developer. Also source control is a team activity.
Scotty Sparks
Yes, it includes the source control at the solution explorer level.
SSMS (Management studio) is not aware of the source control, and any modification to the database objects is recommended to be done within visual studio.
a_guj
i am looking at it from a full source control solution, for a sql server database, via Visual Studio Team System for Database Pro.
that's was one reason for me looking at this product. But like now, with our team using Visual Studio and VSS, there exists a hole in the source sontrol solution. I cannot guarantee that the most recent version of an sp is in VSS or in the database. And I surely don't want to be doing any compares to find out that.
This must have been talked about within Microsoft. I just want to understand why SSMS is not aware of source control. Something must be possible here. Somehow mark a database as being under source control. Then don't allow a modify via SSMS.
also in the last post, what happens when a dev goes in and modifies an object in SSMS then then next time the dev uses VSTS to modify that same object. Changes will be lost. not good.
JoraPJL
With the arrival of VSTS-Data, we are introducing the paradigm shift in the way database objects are manipulated so far.
It is going to bring more harmony between developers and DBA's. Developers will modify the script and move it to source control.
Database testers will than run tests on the test box to make sure that things are all intact. After that DBA's will pick up the changed scripts from source control and run it against production database.
Devlopers would not have right against production database to manipulate objects there, just as before.
If any one DBA or developer changed anything in the production database without saving it in source control, you are right that it will be lost next time we deploy the script here.
Krutika
Putting databases under source control is a whole different subject. DBPro puts the source code under control, not the objects themselves. If you want to "source control" database objects then that's a whole different subject - you're talking about making changes in SQL Server engine itself, not just in SSMS. Not that there's any need because protecting databsae objects is the responsibility of the DBA. DBPro is a developer tool - controlling objects in a database is a DBA job in my opinion.
I agree. that's a problem. So you need to make sure that those things don't happen. Put procedures in so that problems don't occur. e.g. (a simple example) if somoene makes a change in the project, they have to do it in the dev database as well.
I understand your point, really I do, but I tend to think there's no silver bullet - your development team still have to adhere to development procedures/processes. That was true before DBPro and will be true after it.
I guess we're not going to agree on this though
That's good though, products like this don't progress if everyone agrees.
-Jamie
zion99
First of a small request to bfarr23 - would you please insure there is no white space at the end of your posts. It is quite tiring to read this thread because of excessive white space - Thanks!
Now to the topic -
I think bfarr23 certainly has a point, but it is in the wrong place. VSTS4DBP does NOT have the problem with source control. SQL Server DOES and VS Server Explorer DOES TOO (which however is actually the SQL Server "problem"). This means any solution to this problem has to come from SQL Server side. If there were a SS DB Property indicating the DB is under source control AND there was an extra Role for Users that additionally have the permission to modify schemas under Source Control AND SQL Server knew where the source control is and has access to it, etc...... Then comes the next problem, the SQL Server Schema files would have to be parsed and split identically by SQL Server as is done by the VSTS4DBP - otherwise there can be no comparison / check out / etc..
DataDude can not solve this problem and the scenario they've / we've created is too new that it could be considered in SQL Server now. The solution can only be achieved by the DataDude and SQL Server Teams in concert, and the SQL Team probably has to do alot of aligning up work up front. This is going to take awhile.
I too have found that VSTS4DBP is not the god send solution to all of my hopes and scenarios. What I am finding out, is that through the use of multiple projects in one solution, all with different configurations that all point to the same local development DB I can:1. Have one project that is the "truth" (all objects included and deployable) <projectname_dev>
2. One project where I have excluded some or all constraints / keys so that I can do a simplified data generation without thousands of work arounds. (possible answer to Jamie's question - right click object and "exlcude") <projectname_wo_const>
3. Another project with another configuration. <projectname_whatever>
All projects are consistantly "buildable" and "deployable". Through the use of "deploying" the right configuration I am able to work as I please. As Amos said, I also use SSMS and the VS solution explorer when it seems faster or easier and then import the objects into the project(s) with schema compare if needed. It takes geeting used to at the beginning, but does seem to work well.
At any rate, as I have previously posted and Jamie also pointed out, it would be nice if this could be adressed in future versions of SQL Server but at the moment the only solution is a policy which is used by all developers - work in a sandbox (local with whatever tool) and deploy to the central dev DB with VSTS4DBP which controls the Source Control.
I would think that the other problems, which can not be solved by policies, such as the loading and responsiveness of very large schemas and projects are a higher priority.
Alle
Mark Shvarts
Hi,
I do agree with the above strongly (see one of my previous posts "VSTS4DBP could be dangerous"), but I also feel it's also a question and policy of discipline.
Assuming that no one want's to intentionally damage the DB the point would be to get VS to the status that for development work it is equally good and fast to use as SSMS. With DataDude we've taken a big step and I assume that intellisense / analysizing / etc. will follow relatively shortly.
If someone is being malicious, then at least you've got the sources in VSS and the next compare (which should be the start of the dev session each day ) will show the malicious changes. I mean let's face it, anyone who can use DataDude or VS and has an appropriate login can do what they want anyway to the target DB and then discard the changes instead of checking it in.
I do not see how the DataDude Team can do much to prevent this scenario in real world.
Alle
raq
when will SSMS be aware of the source control
is this the plan
nkahootz
lets talk the development environment for a second.
The dev environment will be under source control. How will source control be enforced there (any dev can backdoor and go into SSMS directly....their changes in dev will be lost the next time someone goes into VSTS and "runs" that sp for example)
SSMS needs to be aware of source control. Else there is a problem.
And to me(and others) its really not paradigm shift. We are already using VS and VSS to source control. But we have the problem.
dalterio
how does a DBA stop a developer from using the database user thats used in VSTS(which has modify sp rights for ex), to be used in SSMS to modify an object at the database level
so sure this is source control as you indicate with VSTS, but its not 100% enforceable right
also in the case above those changes made at the database level will be lost when the object is "run" from VSTS the next time a developer works on that same object.
jhknys
We souce control the filesystem, not exactly the database. In VSTS-Pro database is broken into the Visual studio project which constists of files, which is souce controlled. SSMS is showing the online view of the database, and in my view, has nothing to do with the source control.