June 17, 2019 at 1:15 pm
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.
-
June 17, 2019 at 1:15 pm
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.
June 17, 2019 at 2:35 pm
Management Studio here. If it ain't broke, then don't fix it.
June 17, 2019 at 3:35 pm
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.
June 17, 2019 at 6:56 pm
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.
June 19, 2019 at 12:23 pm
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 -
June 20, 2019 at 6:07 pm
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.
-------------------
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
June 20, 2019 at 7:21 pm
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:
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.
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
Viewing 8 posts - 91 through 97 (of 97 total)
You must be logged in to reply to this topic. Login to reply