Monday, May 23, 2011 6:46 PM
I just witnessed a presentation and demo from a Microsoft person and it dawned on me that
- Schema View
- Dependency Viewer
- Data Compare
- Database Unit Testing
- Data Generation
- Data Compare
- Extensibility in general
Are all missing. Is this the state in which it will ship? How are we supposed to upgrade from VS2010 to Junea? Will VS2010 continue to elvolve.
Milo A. Hoffman
Tuesday, May 24, 2011 1:20 AM
A very thorough list for the CTP gap compared to TSData, though I'd also hasten to add the number of features that Juneau currently provides that TSData does not, such as Power Buffer, Server Explorer integration for declarative work, Find All References/Goto def, and Table Designer.
In the coming weeks and months we'll have more announcements over our offerings, projected timeframes, and plans for the future. All of the features you mention are on our minds.
Thank you again for your input. It is valued.
Tuesday, May 24, 2011 2:38 AM
It feels like 1 step forward, 2 steps backwards.
Guess I will have to wait for what the coming weeks/months will bring ;:)
I did not learn anything new about Juneau at TechEd last week, which was disappointing. People I asked at the SQL Server booth were avoiding these apparently hard questions and had nothing to add in terms of answers around future and functionality.
Somebody did show me SQL-CLR integration, nice but we do not use that at all as we also need to deploy to SQL Azure. I would rather have seen improvements over the core database projects functionality instead of re-write. Also I do not get the Power Buffer thing, seems like an other editior geek feature, a co-worker suggested this is some EMacs left over from Don Box, but I do not get it, not even after a 10 min demo? To me it seems to blur the line between connected and disconnected usage.
I was very happy about that Database Projects were enforcing this line crisply, eventhough this led to maybe unexpected usage behavior for those database developers that do everything in SSMS and can not repeat there deployments afterwards. We went all the way to source based schema development, integration in to TFS, source code control, work item tracking, continous integration with testing, static code analysis, we wrote 30+ rules, all hard work, painful but it paidoff big time .
Now I am afraid I will have to tell my management that this is all a waste. VS2010 does not seem to support SQL Azure, Juneau does not support half of what we were using day-in-day-out. This puts me in a bad position explaning why we had to buy VS Ultimate instead of Professional and have to do all the work again or why we cannot support SQL Azure today.
Milo A. Hoffman
Tuesday, May 24, 2011 3:20 AM
+1 to what has been said by Milo.
Find All References/Goto definition are very good but some things that VSDDT currently does are absolutely necessary.
Schema View allows the developer to concentrate on the structure of the database rather than the file structure of the artefacts in source control. Even an ER Diagramming tool would not replace Schema View in my opinion. GoTo Definition, whilst extremely helpful, does not provide the same functionality.
Dependency Viewer goes one step further than the extra information in the Table Designer and provides an easily digestible hierarchical view of dependencies, including procedures and functions, that is not available from the Find All References output.
Extensibility is required as it has allowed us to build an add-in for VS 2010 database projects which saves our DBAs a great deal of time when validating very complex, multi-project deployments.
"CTP"? Is there going to be a CTP soon?
Friday, May 27, 2011 12:52 AM
What is your view on our SQL Azure capabilities, in general? We believe that it will be very compelling to customers to have an offline SQL Azure development experience with the benefits of project-based declarative development.
Power Buffer is not really meant to blur the lines between connected and project-based development but rather to bring the benefits of declarative development and deployment to connected tasks that customers have told us that they still must do during the DB development lifecycle. That being said, I believe I understand your viewpoint.
As for the feature gaps in VS2010 and Juneau, you are correct that TSData 2010 does not support declarative Azure development. Juneau does, but currently has the gaps you called out earlier. It is our desire to close those gaps so that you will have the holistic experience you seek.
Friday, May 27, 2011 1:01 AM
I'm interested in your comment about ER Diagramming not replacing Schema View. I see functionality that it would and would not replace, but I wonder if you might bullet list the gap you see there.
Your feedback and vote noted on the Dependency Viewer. DV is interesting as the importance of the feature seems to vary rather wildly from customer to customer where some other features are more universally loved. I infer your primary motivator for the feature to be visualization, is that accurate?
Watch for a CTP coming. You'll note I'm not stating a date; sorry, I don't want to get slapped ;)
- Edited by Jeff Welton MSFTMicrosoft Employee Tuesday, May 31, 2011 4:10 PM spelling/grammar
Friday, May 27, 2011 6:45 AM
Schema View, as it is currently implemented in VS 2010, offers the hierarchical view over database objects (not file objects) where I can easily drill-down to the level of detail that I want. It lets me drag objects into the code window and do all that right-click-refactor goodness. I can't imagine the same functionality in so small a space using object diagrams a la most ER Diagramming tools. I'm don't mean that ERD would not be useful, quite the contrary, just given the choice of one over the other I'd take Schema View first thank you.
Dependency viewer, as it is currently implemented in VS 2010, is still a bit clunky. You are correct that it is the visualisation that is most helpful. Having it as an extra virtual node in the schema view would be helpful but the never-ending drill-down that the current implementation has gets me a bit lost sometimes.
Don't forget extensibility, extensibility is very important.
Sunday, May 29, 2011 11:42 PM
Diagramming is great but a real-eastate hog and not enough detailed information, besides that most diagram solutions I have seen only support tables, I need to navigate all related object types inside SQL Server. Based on the fact we only gain a table designer amd now INDEX, VIEW, PROC, FUNCTION, TRIGGER etc. designers I am skeptical that a diagramming surface will actually be able to replace a simply tool like Dependency Viewer and offer the same amount of information in real-estate used.
With regards to Power Buffer I must be missing something key here. The way I see the feature is that I can make changes in-the-buffer and then apply them, like a instant deploy. That does smell like a connected scenario to me. I would applaude the ability to use more tight edit-deploy-debug loops, as deploy is pretty time consuming having to build the target comparison schema and then build a deployment plan for each time you invoke, if you make that faster that would be awesome and highly appreciated as it helps the overall experience.
I also feel that power buffer comes with many restrictions, I got the feeling I can only use this on a subset of objects, effectively those that the table designer manipulate, seems there is some "backdoor" deployment going on from table designer, which makes me wonder about the integrity of the model.
Would Juneau allow integrating and using NUnit as our testing environment environment instead, will that degree of extensibility be available? So I need to be able to navigate the model to code gen some tests harness using NUnit instead of MSTest, which is fine with me, I prefer NUnit over MSTest my self.
Milo A. Hoffman
Friday, January 06, 2012 1:53 AM
Thank you Jeff, but I would really like to know what we're supposed to do for data generation if we want to use SSDT SQLPROJ and support automated Azure deployment. Unfortunately, it seems like we're stuck in no-man's land. While I love what is being done with SSDT, I can't understand why critical functionality like Data Generation would be dropped completely.
Is our only option to revert back to a DBPROJ until SSDT is fully baked?
You mentioned "In the coming weeks and months we'll have more announcements over our offerings, projected timeframes, and plans for the future." Where can we find those announcements?
Monday, January 09, 2012 5:40 AMModerator
The Data Comparison, Database Unit Testing and Data Generation functionality will be added to SSDT post Visual Studio 11 RTM + 3 months.
-GertD @ www.sqlproj.com
Tuesday, February 14, 2012 2:41 PM
Glad to hear that Data Comparison, Database Unit test, and Data Generation will be added, but what about the Schema View and Dependency Viewer? To me one of the nice things about VS2010 was how it tried to differenatiate between logic (schema view) and physical (solution view). I personally really liked how all the table subobjects (indexes, keys, etc) were seperated into different folders/files. Where is the best place to make these suggestions?
Tuesday, February 14, 2012 2:49 PM
Where is the best place to make these suggestions?
Tuesday, February 14, 2012 4:18 PM
You should feel encouraged to use the connect link that Jamie points out to add weight to the discussion on Schema View and Dependency Viewer. Rest assured, though, that these features have not been forgotten on our side. We have had and continue to have discussions about how, when, and in what form these features might be integrated to SSDT. We're aware of and sypathetic to strong stated customer desire to see their functionality in SSDT.
Friday, March 16, 2012 6:06 PM
We went all the way to source based schema development, integration in to TFS, source code control, work item tracking, continous integration with testing, static code analysis, we wrote 30+ rules, all hard work, painful but it paidoff big time.
Milo A. Hoffman
I would be appreciate seeing some samples of the 30+ rules that you created.