SSDT background themes and configuration manager settings

  • richardmgreen1

    SSCrazy Eights

    Points: 9716

    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.

  • Phil Parkin

    SSC Guru

    Points: 243474

    richardmgreen1 - Thursday, June 28, 2018 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.

    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 the answer to your question can be found with a brief Google search, please perform the search yourself, rather than expecting one of the SSC members to do it for you.

  • richardmgreen1

    SSCrazy Eights

    Points: 9716

    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).

  • Phil Parkin

    SSC Guru

    Points: 243474

    richardmgreen1 - Thursday, June 28, 2018 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).

    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 the answer to your question can be found with a brief Google search, please perform the search yourself, rather than expecting one of the SSC members to do it for you.

  • richardmgreen1

    SSCrazy Eights

    Points: 9716

    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 5 (of 5 total)

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