Conversion of SSMS projects to SSDT?

Question

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

 

 

Answer 1

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

Answer 2

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

Answer 3

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

Answer 4

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