none
Conversion of SSMS projects to SSDT?

    שאלה

  • Let's just suppose that I'm a user who's been using SSMS since it's
    inception. Have lots of SSMS projects (suffix .ssmssln) that are series of
    "disembodied scripts" referring to many different databases. I want to start
    using SSDT; what's the best way to convert the scripts/projects?
     
    I see that "connected mode" (AKA SSDT SQL Server Object Explorer mode) lets
    me open and save individual .sql files; anything better than that for
    conversion/SSMS compatibility purposes? I do want to have series/projects of
    (somehow) associated scripts at the end. And I don't want to necessarily use
    disconnected and have these be converted to .sqlx.
     
    Cheers, Bob
     
     
    יום שלישי 06 דצמבר 2011 20:11

תשובות

  • Hi Gert,
     
    I was thinking this would be a way to ease developers that are currently using SSMS into SSDT. Then, over time, they could take advantage of the SSDT-specific additional functionality. I’ll try your “add existing item”.
     
    Cheers, Bob
     
     
    "Gert Drapers" wrote in message news:53e8c796-df4b-40da-b0b2-0a277a576e88...

    Hi Bob,

    What is the underlying goal? Create a database project? Which means changing from impartive to declarative? In that case you can create a project and using Import Script, select all the files and it will extract all the DDL statements and move the statements which are not understoood/supported in to the ScriptsIgnored.sql file. The statements/blocks most of the time end up in a post deployment script.

    If you just are looking for a container for script files, you can do that, however I would argue there is no real additional value. But if you want. Create a project, add the script using Add Exitsing Item and change the Bauild Action property to be Not In Build. Now your project file is nothing more then a container for script files which does not remember connections.

     


    -GertD @ www.sqlproj.com
    יום רביעי 07 דצמבר 2011 21:10

כל התגובות

  • Hi Bob,

    What is the underlying goal? Create a database project? Which means changing from impartive to declarative? In that case you can create a project and using Import Script, select all the files and it will extract all the DDL statements and move the statements which are not understoood/supported in to the ScriptsIgnored.sql file. The statements/blocks most of the time end up in a post deployment script.

    If you just are looking for a container for script files, you can do that, however I would argue there is no real additional value. But if you want. Create a project, add the script using Add Exitsing Item and change the Bauild Action property to be Not In Build. Now your project file is nothing more then a container for script files which does not remember connections.

     


    -GertD @ www.sqlproj.com
    יום רביעי 07 דצמבר 2011 07:40
  • Hi Gert,
     
    I was thinking this would be a way to ease developers that are currently using SSMS into SSDT. Then, over time, they could take advantage of the SSDT-specific additional functionality. I’ll try your “add existing item”.
     
    Cheers, Bob
     
     
    "Gert Drapers" wrote in message news:53e8c796-df4b-40da-b0b2-0a277a576e88...

    Hi Bob,

    What is the underlying goal? Create a database project? Which means changing from impartive to declarative? In that case you can create a project and using Import Script, select all the files and it will extract all the DDL statements and move the statements which are not understoood/supported in to the ScriptsIgnored.sql file. The statements/blocks most of the time end up in a post deployment script.

    If you just are looking for a container for script files, you can do that, however I would argue there is no real additional value. But if you want. Create a project, add the script using Add Exitsing Item and change the Bauild Action property to be Not In Build. Now your project file is nothing more then a container for script files which does not remember connections.

     


    -GertD @ www.sqlproj.com
    יום רביעי 07 דצמבר 2011 21:10
  • So you just want a script container? It is very trivial create an add-in which does this either way, but I want to understand what the end-result is expected to look like.


    -GertD @ www.sqlproj.com
    יום רביעי 07 דצמבר 2011 22:42
  • Hi Bob,

    Have your conversions been successful so far?  Are you using database projects merely as "script containers" as discussed above, or are you utilizing them as declarative representation of the database?

    Very interested to hear how the conversion went for you and what your current use cases in SSDT are.

    Thanks,

    Janet Yeilding

    יום רביעי 29 פברואר 2012 05:37