March 27, 2015 at 7:02 am
Since I'm old school I do prefer working in SSMS, but am working to get all our databases into SSDT Database projects to get them into TFS. I'm essentially trying to advocate for the distributed development model at my shop where we'd do the actual database development locally, then put the changes into the database project and check them into TFS, then have a build out to our development integration server. Not there yet.
The tie into SSMS is the one thing SQL Source Control has over SSDT database projects.
Jack Corbett
Consultant - Straight Path Solutions
Check out these links on how to get faster and more accurate answers:
Forum Etiquette: How to post data/code on a forum to get the best help
Need an Answer? Actually, No ... You Need a Question
March 27, 2015 at 7:02 am
SSMS exclusively
March 27, 2015 at 7:08 am
SSMS about 95% of the time. I find it easier to use. I wish that SSDT was more similar to SSMS because it makes sense to use it there since I almost always have to have both SSMS and Visual studio open.
March 27, 2015 at 7:11 am
SSMS for the win.
March 27, 2015 at 7:26 am
Jack Corbett (3/27/2015)
Since I'm old school I do prefer working in SSMS, but am working to get all our databases into SSDT Database projects to get them into TFS. I'm essentially trying to advocate for the distributed development model at my shop where we'd do the actual database development locally, then put the changes into the database project and check them into TFS, then have a build out to our development integration server. Not there yet.The tie into SSMS is the one thing SQL Source Control has over SSDT database projects.
This is the way to go, good luck.
SQL Source Control is made redundant by SSDT, in my opinion.
(Now that's not going to please the forum owners :-))
The absence of evidence is not evidence of absence
- Martin Rees
The absence of consumable DDL, sample data and desired results is, however, evidence of the absence of my response
- Phil Parkin
March 27, 2015 at 7:27 am
I use
SSMS 🙂
March 27, 2015 at 7:27 am
SSMS
March 27, 2015 at 7:31 am
Both!
SSMS -- Day to day scripting and tasks. Need a backup before a change? Need to prototype something in test real quick? SSMS.
SSDT (in Visual Studio) -- Develop the schema and have everything in a nice package + deployment. Saves me a lot of time. Yeah I could do this in SSMS, but I started using SSDT and never went back.
March 27, 2015 at 7:40 am
I like Visual Studio a lot, and use it (VS 2012) for SSIS work, but I use SSMS for my SQL development work, primarily because I'm used to it.
March 27, 2015 at 7:48 am
Both! We use SSMS for developing/testing. When a project is ready to go into UAT, the changes from development are put into the project in Visual Studio so that they can be checked into TFS and an implementation script is generated from the Visual Studio project.
March 27, 2015 at 7:50 am
We are a Microsoft shop, and our developers live in Visual Studio. They also do a lot of DB development. This happens in Visual Studio SSDT. We tie it to TFS for source control and also use it for automated deployments. Prod DBAs heavily use SSMS for administration and management. Us Dev DBAs live in both tools/worlds. I'm a big fan SSMS.
As an aside, now SSMS really is a Visual Studio IDE/extension/development/tool/thingy, so if you work in SSMS you are indirectly working in Visual Studio.
Hakim Ali
www.sqlzen.com
March 27, 2015 at 7:51 am
I am new to SSRS. The way our system is configured I have SSMS but can not connect to the db. I am actually extracting data from an oracle db via SSRS. I use SSDT when developing SSRS reports.
March 27, 2015 at 8:03 am
SSMS - main tool as I do a lot of ad-hoc queries
SSDT - main dev tool. Everything that we push to our servers has to be in an SQL Project or it doesn't go. Our devs have been doing local development for some time and having the ability to quickly update their local DBs from source control is part of being successful for that.
(We did use SQL Data Compare to get a scaled down data set for testing from our shared/dev server.)
In regards to SSDT vs. SQL Source Control - they're both good, if slightly different in their approaches. SQL Source Control at least attempted to write to SSDT Projects at one point, but I don't know how far that went. I'll admit to leaning more towards SSDT, but I'd use either over most of the competing ideas.
Edit:
I've written up our experiences/process for SSDT here if anyone is interested: http://schottsql.blogspot.com/2013/10/all-ssdt-articles.html
I'd also highly recommend Jamie Thomson's posts on SSDT and related here: http://sqlblog.com/blogs/jamie_thomson/archive/tags/SSDT/default.aspx
March 27, 2015 at 8:05 am
SSMS. I only use SSDT for SSIS and SSAS. I tried doing DB work in SSDT a few times but found it to be too clunky.
March 27, 2015 at 8:07 am
Ditto to shillbot: "I'm primarily a C# developer (with a heavy DB focus), and I spend most of my time in Visual Studio, but I find SSMS more comfortable for DB work"
Viewing 15 posts - 31 through 45 (of 97 total)
You must be logged in to reply to this topic. Login to reply