This must be a beginners question.
I created a database project with source control on my VS client.
Then my colleague opened the project from source control.
On my VS client I added a new view and checked it in. I shows up in Team Explorer.
When my colleague gets the latest version, the new view does not show up in her VS client.
In this case we know she is missing a specific view, but in the future that problem will not be obvious.
What are we doing wrong Help would be greatly appreciated.
This is how i do this....
Once a get latest is performed and verified that you can 'see' the view in the project you will need to do one of two things to get the view to show up in a database...
1 While in the database project is selected, select the menu Database->Schema Compare... This can set up a Sync Script between a Local database and the Database project....
Or
2. Perform a Deploy of the database project by right clicking the database project and running the deploy, (you might want to check properties on the project to verify each workspaces settings ....etc)
What it sounds like you have happening is the "text file' of the view is successfully moving over via the Get latest and the database project , but you now get to deturmine which local"developer" database this file gets converted into a View by executing it.
Let me know if you have any more questions....
cra451
Thanks, cra451.
We managed to get this view by setting 'show all files' on.
You are right, the text file moved over.
Then we did an 'include in project' and the view was OK.
However, I am concerned. In this case, we were doing a test.
In real life, I have 20 developers and if one of them adds one or more objects, it should go to the others through the source control.
It should not need a separate manual action that requires the others to already be aware of any new objects.
How can I set it up so that we do not have a missing object problem on our hands in the future
well...
Im happy that you found the missing object. im not sure that this was a missing object i would suspect that it was either not checked in , not refreshed , some other wierdness , but i think this might be process driven... and since ths is an experiment , and if you dont mind i can outline how we are actually using this wth developers and dba's. We have been doing this project since last summer and data dude since October. So we have some of the isuses worked out.
I can not say that this is the best way but it is working for us quite nicely. (THANKS MSFT)
Lets look at how our team systems works for c# code and see if 'normal' or 'standard' practaces can illistrate some procedures for Datadude.
When the developer arrives in the am (or im the pm for the really good programmers) , this person opens up team system and probably opens up a common solution with all if not most of the Projects in it. Personally i right click on the solution and do a GetLatest (or get all) for the project.
While this is churning away i get outlook open and see if the email from the build last night was a success of failure. (some offices make the developer who breaks the build do some thing silly for breaking the build. i have heard of wearing a tuto or having to buy the team lunch the friday after payday. use you own judgement here but this is a developers job to try to keep from breaking the build)
If the build succeeded i sigh and relax.
by the time i finish reading the email i know two things ..... Where im gong to lunch friday and by then the getall has had enough time to complete. .... and then I do a local build from the solution ....(right click on solution) now to be clear this is not a Data dude deploy that is in a second.....
if everythng is working I have a stable starting point to start the day. this is important for developers and data people also. ifnot i can start tosee what happened to break this...
the get all and sync will insure all objects (C# and Tsql) are 'moved' to the local machine for dev. but in the case of c# there eally isnt any great use in executing a c# file you generally need to execute a Dll or EXE . thier creation is handled in the build process. but these file are in your source tree the are not on a test server or database. to get these 'compiled' objects (aka targets, websites databases etc) to thier usefull locations is generally done with a deploy step.
this kinda makes sense when you think about it.... if im sending a web site update to the web server id want to get all the changes together in one batch and then send them to the test server all at once.... then take that same set of changes to PreProd then finally to Production.
so for review the Deploy has a payload and the build a smaller process to assemble and verify that this payload works ( or a payload) is complete and repeatable. NOTE i did not say Tested...... i just said assembled and Works....
Now for me personally since im a dba im going to go ahead and deploy my database projects locally and run their db unit test and populate with some safe test data.
C# C++ C , vb etc have been using this process for years (if not decades)
We try to go in a 4 hour block of time ill try to set up a task that takes 4 hours to complete and check that in .
So from here lets assume that 3.5 hours have passed and this is what im going to do next.
so far i have successfully created local database objects (views, sp, fn, etc) and i have written sql tests and am satisfied that my task is done....
so what do i do ...
I open up team systems... ( what when did i close it... )
yep thats right i actually do my dev work in my favorate tools.... im not tied to TFS for accomplishing work... just orginazing and scheduling and communicating... (YEA no more status reports...another rant)
I do most of my work in SQl server managemnt studio for SQl 2005 ...
So im back in tfs...
Well since im checking in code the first thing i do is open up the solution that has all of our projects... and right clickon the databases and do a get latest (since im THE DBA there should not be anything there i dont know already about... but i can check on it before proceding..)
once the get is done (99% of the time there isnt any changes ) i do build and then a database schem compair between the project and my local database... Yep that is right....
this will check all the differences not just the ones that i remeber. and really now i dont have to because its chceking my local database against the Checked in database.
this creates two things the diff screen that shows me what is changed and the complete delta script.
I can tell it what gets checked in and what doesnt from this screen ...... in my humble opinion this is so much better than trying to edit the objects in tfs... (although the refactoring is really cool, although some things it doesnt do as well and that is being worked on in this next release)
When i am satisfied with what im turning in, i select the Write updates button. this updates all the sql files in the database project that need to be changed. But these files are not back in the tfs server yet. and that is a good thing.
Do you remeber that part about breaking the build... if the changes went directly into tfs you dont really know if you selected everything right...Right the program told you bit you just over-rode its sugestions....
so i recommend doing a build and Deploy to a localtestdatabase.. and rerunning your database test scripts, then checking both the database test scripts and the database projects back into the tfs server.
Also in this check in, i update my task as complete.
At this point and only at this point can a developer get this code for thier use.... (not counting shelving....another topic)
this eliminates the oops factor on both sides and leaves a nice audit .... and the database and 'data' is in version control and can be rebuilt+Deployed and set up in minutes for any and many task(s).
Did i mention it can be deployed anywhere that you can set up a sql2005 connection to. (nice for one off situations that the developer may need )
By the way the process of sync build checking takes me about 3 minutes to do. but it documents this task item is complete, it also associates this code to this task, these tests to this code and my status is now updated. (this is also called a changeset)
My worse case is if things dont go right (i forgot something , the code doesnt compile etc ) is no more than 15 minutes but this saves someone else from having to deal with this not working. and also mostly elimines the quick fixed that are needed all the time... these quick fixes are more controled and eventually more rare... and if needed 3-15 minutes on my side and 3 minutes on the developers side if needed.
Now for the build ... its later that night and we have a Database build and Deploy to a dev server set up and all my changes will be built and deployed to the dev server that night..(actually we backup and delete dev once a week) and our build sets up the database, permissions , and standard starting test data.
when the build/deploy is complete we execute the db tests against this database that way the Developers that use it know its right everytime its built.
If the build succeeds then the builds deploys and the application tests execute and we get a full regression testing every night. (at the database and at the application) we actually have 5 apps and 2 databases in our contract with the client.
I realize that this answer is a bit long but there are alot of controls that are in place and i think they are wisely thought out. We have a small tight team of 2 devs 1 dba and one 1Project manager/Tester. and we learned and did this mostly in the last 6 months. so you can too , its hard to do the initial climb but the view is great once you get here.....(MSFT no vista jokes please GRIN/groan)
And i really hope i filled some possible cracks. please post back with more questions...... we are all here to help
Cra451
Cra,
Thank you very much for your detailed reply!
I am going to read it again and think it over very carefully. It is clear that there are multiple ways of going about this.
Yours makes sense, but is a bit different from what I was thinking (working more directly with VS and TFS)
We are trying to set this up for our team of 20. We have a dozen applications and maybe 75 databases.
These are in production at about 15 large companies.
Thanks again,
Marianf
I am so glad that this may help.
I¡¯m going to assume that the applications and databases can be assembled together into Solutions... and that you could have a solution for each client. (Also you might want to have the same application in several solutions. this can be done to keep everything up to date.) So basically you could have 15 solutions... one for each customer that could cover all the code that you want to cover for that customer. (and this is just one way)
There is also merging and branching that can be handled for your common projects, that way you can keep different common objects ...(I¡¯m going to guess that each customer is not absolutely using the same version of the common code )
But basically once everything is connected, an update in solution may or may not propagate to all other solutions depending on what you want or need. This is possible by linking projects instead of "copy".
Remember that in this case your project (target) files and the Solutions are now in version control also... So you also get the ability to Version control / Audit / Update your project and Solutions files. This can be VERRY powerful as you achieve further integration.
I hope this further helps
Cra451
Usually if the file was downloaded to the new machine, but does not show up in the project, it means that for some reason you did not get an updated copy of the project file. Now there could be a couple of possibilities for that:
1. When you checked in the view, you did not check in the project file. You can verify this by looking at the project where the view was created, if the project file is still checked out it needs to be checked in.
2. When the second user synced the view was picked directly from the source control explorer(TFS) or something similar for other source control soultions. Though it sounds like you did a get latest version so this probably isnt the issue.
Im pretty sure the first scenario is likley your issue. I find that the easiest way to get around this issue is to check in at the solution level, thus everything checked out below it will be included in the check in.
Hope that this helps.
Christian
Your previous and this post were very helpful!
I will certainly have multiple projects in my solution. Not per customer, because we try to give all our customers the same code base.
Customizations for customers are handled separately.
Maybe my solution will have at least two projects for each module (web application files, database schema).
Or maybe I will create a separate solution for each module.
Then I would like to think about branching for major versions.
I expect we will have to live a long time with these decisions made in the beginning and that is why I am so happy that you told me how you approach it in a real live situation.
I have already learned from that that a daily build with centralized updates from source control to development environment may be the best way to go.
My next hurdle will be processes around data...
That is a good point. I did not pay attention to the project file, only to the database object file.
Wow that was a great and obvious point MSFT. Your all are the bomb!
cra451
I'm not talking about a new item (view, table, procedure) added, I'm speaking about one element that was checked out, modified, and checked in.
The project file is only modified if a new item is added or removed. This is not changed after simply altering a previously added file. We are seeing an issue where between four developers working on the database project, when we get latest, there are times when the items are not refreshing. The only solution we have found that works consistently is to:
One feature we use consistently is the Schema Compare, when doing code migrations. If your local source code is not 100% synched with what is in the code repository (Team System), then we end up with problems. That schema compare can do a "project" to target "database" compare and generate a script to synchronize them. It works -- it's lovely.
The problem is that the "project" it is comparing is not the one in VSTE, it is what you have locally loaded. So if your get latest is not properly synchronized with what is inside Team System (after a "get latest"), then you'll have issues you don't even know about until after deployment and testing (if caught).
Why does this occur
The odd part is that if we open each procedure that was modified inside VSTE, then we are shown the newest version and the compare works great. If we do not, then we are left with previous versions even though the newest exists on-disc after get latest.
Bug I think so.
Fix Unknown.