June 28, 2018 at 7:54 am
Hi all
This is an odd one.
We've got 2 servers (DEV and PROD) and we have configuration managers set up in the Visual Studio 2012 and SSDT2017.
We have SQL Prompt (what a time-saver that is!) and have coloured the SSMS tabs depending on the connected server.
Is there any way to do the same in Visual Studio and SSDT?
Any help on this would be greatly appreciated.
June 28, 2018 at 8:30 am
richardmgreen1 - Thursday, June 28, 2018 7:54 AMHi allThis is an odd one.
We've got 2 servers (DEV and PROD) and we have configuration managers set up in the Visual Studio 2012 and SSDT2017.We have SQL Prompt (what a time-saver that is!) and have coloured the SSMS tabs depending on the connected server.
Is there any way to do the same in Visual Studio and SSDT?
Any help on this would be greatly appreciated.
Are you really connecting to Prod using a development tool like SSDT?
Anyway, I don't believe that the VS interface allows Redgate to 'inject' coloured tabs in the same way SSMS does.
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.
June 28, 2018 at 8:35 am
Hi Phil
We use SSDT/Visual Studio to create SSIS packages, stored procedures, etc (so we can use version control) and then we deploy/execute depending on the server name in configuration manager.
That's a shame, I forgot to check which config manager I was pointed to when I tried to execute a package. Thankfully it failed as it was pointed at PROD instead of DEV and the tables don't exist on PROD (yet).
June 28, 2018 at 9:08 am
richardmgreen1 - Thursday, June 28, 2018 8:35 AMHi PhilWe use SSDT/Visual Studio to create SSIS packages, stored procedures, etc (so we can use version control) and then we deploy/execute depending on the server name in configuration manager.
That's a shame, I forgot to check which config manager I was pointed to when I tried to execute a package. Thankfully it failed as it was pointed at PROD instead of DEV and the tables don't exist on PROD (yet).
One day, that is going to trip you up, and the process of recovering won't be a happy one.
I'd urge you to review the way that changes get deployed to Prod (at the click of a button, using a CI tool, from the Prod branch of your VCS of choice is the sort of thing I'm thinking of).
If your Prod databases are important to the business, this should be a separate process and not one which developers routinely undertake.
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.
June 28, 2018 at 9:13 am
We're trying to change the way we do deployments (and get databases, etc. into source control) but it's slow going.
As for deployments, there's only us lowly developers to do it (this place doesn't have a DBA which is driving me nuts but the managers have decided a DBA isn't necessary even though there are around 80 SQL instances on the go).
Viewing 5 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply