March 27, 2015 at 5:00 am
I am using both SSDT and SSMS. I am doing database maintenance and development.
Since a few years I started to use the Data Dude components for all our projects. In case a change had to be done in relation to a database, it was only allowed by using a database project. Takes some time to "reverse engineer/import" a database into a database project, but at the end it is worth it. We use Team Foundation Server, for, among others, our source control, so all our database are now under source control.
We also have (semi-)automated build and deploy configured. That results in the fact that I don't have to manually touch the database in order to deploy a change, and so resulting in less mistake.
It was scary in the beginning to let an application (SQLCMD) make changes to a database, but once I got over it, I am very happy with it.
One thing to note about the deployment with SQLCMD, is that this might not be the best solution if you need to make a change to not only the structure of a database, but also to the data in there. Those changes might be better handled via scripts you create by hand.
March 27, 2015 at 5:02 am
SSMS with Red Gate Source Control for anything but necessary SSIS packages.
As my work is pulling and pushing data from one place to another this is all I need.
March 27, 2015 at 5:14 am
I use both.
I have SSMS open constantly for ad-hoc queries and research.
Most of my development is done inside SSDT however.
March 27, 2015 at 5:32 am
SSMS, along with Redgate tools.
Adam
March 27, 2015 at 5:33 am
SSMS. SSDT seems a bit clunky to me.
March 27, 2015 at 5:48 am
SSMS. Sometimes Visual Studio with BIDS Helper.
March 27, 2015 at 5:53 am
SSMS!
March 27, 2015 at 5:53 am
I'm almost always using SSMS, but it is nice to jump into SSDT and compare object between a two version of a database to see if what may have changed.
March 27, 2015 at 6:08 am
Pretty much live in SSMS and code T-SQL in my sleep. However if writing a .NET app, I'd be curious why the discussion is SSDT versus using the Entity Framework which seems to be the way to go for data persistence strategies in the current ORM world? Personally, I prefer the Grails Framework for doing ORM-based applications, but I digress.
March 27, 2015 at 6:10 am
I use both, SSMS is open all day and used for data reporting, where SSDT is used for alot of ETL activities.
March 27, 2015 at 6:19 am
SSMS with ApexSQL Developer Bundle for source control management.
I prefer SSDT for new databases but the team hasn't moved over there yet.
March 27, 2015 at 6:21 am
SSMS mostly; haven't even tried SSDT.
March 27, 2015 at 6:27 am
I use both, SSMS for administration and SSDT for development
March 27, 2015 at 6:32 am
SSMS
March 27, 2015 at 6:56 am
Preferably SSMS as pretty much used to it.SSDT not extensively tried yet.
Viewing 15 posts - 16 through 30 (of 97 total)
You must be logged in to reply to this topic. Login to reply