SSMS or SSDT

Question

SSMS or SSDT

Viewing 8 posts - 91 through 97 (of 97 total)

You must be logged in to reply to this topic. Login to reply

Jason- SSCrazy Points: 2795 More actions · Answer 1

Reading the comments, there's been a mixed amount of change since 2015 to today out there. For me, lots of change, in 2015 I was all SSMS all the time and was not familiar at all with SSDT (unless you count BIDS for SSIS and SSRS). My role has shifted from administration and support to include database development, now I use SSMS for administration and building queries that will land in a view or proc. All my SQL dev is in SSDT. We have a rule that no code should ever exist in a shared environment (dev, test, stage, prod etc.) that doesn't exist in version control first and another rule that all code must be independently deployable (and as automatic as possible), SSDT makes this so simple and is getting us ready for full DevOps automation (still have some stragglers in the BI realm to get on board). SSDT eliminated the days of script projects where we created the "Install Schema" script to create the database and empty tables and then series of "Update Schema" scripts to apply changes from a particular version forward. With pre and post scripts, SSDT made our dev cycles so much more efficient and shorter duration and significantly simplified deployments. I highly recommend SSDT for managing all SQL server database objects with one word of advice... When you embrace SSDT, embrace it fully, don't go the route of managing objects on a SQL Server instance then migrating them to the SSDT database project, this is a pain. Instead, build all database objects in the project and deploy to the desired SQL Server instance.

-

Byron SSC-Addicted Points: 470 More actions · Answer 2

SSMS, though I often use a high-end ASCII editor because it's much faster to fire up than an IDE and feels more responsive.

RevOX11 Old Hand Points: 308 More actions · Answer 3

Management Studio here. If it ain't broke, then don't fix it.

dave.farmer SSCrazy Points: 2431 More actions · Answer 4

SSMS all the way... we have Visual Studio and use that for source control (used to be TFS, now git) but I do all the work in SSMS and copy over to VS when I'm done.

Maria Barnes SSC Journeyman Points: 76 More actions · Answer 5

I use almost exclusively SSMS. That said, since I have moved to connect to version 13 it seems buggy. About twice a week I get memory errors and have to start a new instance.

R M Buda SSCrazy Points: 2225 More actions · Answer 6

We mostly use SSMS.

We tried to move to SSDT to assist with source control and deployment, but found this only worked well with small schemas. Our largest database is well over 1000 objects and SSDT is tooo slow..., while SSMS copes fine.

Also SSMS is more lenient about missing or non-compiling objects and SSDT will have no truck with that sort of mess. I know the proper response is that these should not exist, but its a historical thing and I imagine not uncommon.

Having said that, there are some annoying issues with SSMS -

when using multiple screens the login popup is sometime invisible
Encoding of script files is inconsistent (ASCII/Unicode/UTF8) should be a user option

webrunner SSC-Dedicated Points: 31715 More actions · Answer 7

I use both, but honestly, I have found SSDT (well insofar as I need it to make SSIS packages) really annoying to use. So much is embedded in cryptic settings and errors that make configuring and troubleshooting SSIS packages a nightmare.

In particular, if I have drives or shares on a server but not on my local computer, that causes the package not to recognize the locations. That stands to reason, of course, but I wish there were a way to tell my SSDT local copy what the actual server drives will be. Also, determining the exact account that is running the Agent Job or package, and what permissions are needed so that folders can be seen and files dropped or read, is another set of troubleshooting headaches.

I'm sure there is a better way to do this, but I don't know what it is. If anyone can suggest any good SSDT or SSIS development training I would be very grateful.

This reply was modified 4 years, 10 months ago by webrunner.

-------------------
A SQL query walks into a bar and sees two tables. He walks up to them and asks, "Can I join you?"
Ref.: http://tkyte.blogspot.com/2009/02/sql-joke.html

Phil Parkin SSC Guru Points: 246693 More actions · Answer 8

webrunner wrote:

I use both, but honestly, I have found SSDT (well insofar as I need it to make SSIS packages) really annoying to use. So much is embedded in cryptic settings and errors that make configuring and troubleshooting SSIS packages a nightmare. In particular, if I have drives or shares on a server but not on my local computer, that causes the package not to recognize the locations. That stands to reason, of course, but I wish there were a way to tell my SSDT local copy what the actual server drives will be. Also, determining the exact account that is running the Agent Job or package, and what permissions are needed so that folders can be seen and files dropped or read, is another set of troubleshooting headaches. I'm sure there is a better way to do this, but I don't know what it is. If anyone can suggest any good SSDT or SSIS development training I would be very grateful.

The general rules I follow when it comes to items which vary between environments:

Use parameters for all of these items
Set up the default value of the parameters to be valid in your development environment.

When the package gets deployed to QA and Prod, use SSISDB environments to set the value of the parameter to whatever works in that environment.

If you haven't even tried to resolve your issue, please don't expect the hard-working volunteers here to waste their time providing links to answers which you could easily have found yourself.