Update new download location is https://visualstudiogallery.msdn.microsoft.com/435e7238-0e64-4667-8980-5… In-line TVF’s are awesome, they are a great way to reuse T-SQL code without the performance penalties of multi line TVF’s or horror of horrors Scalar Functions. Taking select statements and turning them into in-line TVF’s is actually really really simple using the TSql ScriptDom so here is another tool for the SSDT Dev Pack that lets you highlight a select statement in SSDT and generate a TVF and replace the statement with a call to the TVF.

New ScriptDom visualizer now also shows the tokens that are found in a sql script. It also highlights the part of the query that is covered by the token so it is really easy to see where you are in the script. Honestly if you are doing anything with the T-SQL Script Dom this is really useful to help reverse engineer t-sql into ScriptDom objects :) Grab it from: https://github.com/GoEddie/ScriptDomVisualizer/tree/master/release

Update new download location is https://visualstudiogallery.msdn.microsoft.com/435e7238-0e64-4667-8980-5… Bert likes his T-SQL keywords in UPPERCASE, Ernie likes his in lowercase which causes some internal struggle as it is actually one person “Mr Bert Ernie” anyway I digress, whether you are working by yourself or in a team you sometimes want to change the case of all the keywords in some code. If you are using SSDT you can use my new SSDT-DevPack tool to do it for you:

SSDT is great but one thing that is not so great is the performance of the publish. I am not complaining, I understand it does a lot and is well worth the wait when publishing however, when you are writing and testing code having this process really kills productivity: 1. Write code 2. Build projects 3. Publish projects 4. Wait for publish to complete 5. Check publish messages for errors 6.

The ScriptDom is cool, it lets you parse T-SQL, play around with the AST (tree of statements) and then generate T-SQL again (probably in a different format etc). This is really cool but if you round-trip the T-SQL into an AST and back you lose some important information like comments so, if you do something like: var original = @"create procedure [dbo].[get_employee](@employee_id int) as --ssssss select 100; select * from a a1 where a1.

When developing stored procedures in SSDT it is important to know when you have written a query that is potentially slow or has a high IO or CPU cost but there is no real way other than examining the the tables you are querying and understanding the data volumes and indexes whether they could be a problem. The idea of this new tool is to highlight in either yellow or red (yellow is quite expensive, red is really expensive) any statements that have a high cost.

I have released another tool as part of the ssdt dev pack, what this does is create tSQLt classes and stub tests. If you open a stored procedure in ssdt and then do “Tools–> SSDT Dev Pack–> Create tSQLt Class” or you can create a keyboard mapping in “tools->options->keyboard”, what I do on my machine is map “Tools.CreatetSQLtClass” to Ctrl+K Ctrl+S - it will create a schema with the name of your stored procedure and the correct extended property for tSQLt to register it as a test class.

Automatically name primary key constraints There are some things you see when writing t-sql code and schemas that just look sloppy, one of those is unnamed constraints, what you see is: create table t( id int not null primary key ) The problem with this is that the primary key is given an automatic name which will look like “PK__t__3213E83F5F141958” - this means comparing database schemas for differences becomes hard as the constraints have different names.

I have made some changes to the way MergeUi works and also moved it into a new repository (https://github.com/GoEddie/SSDT-DevPack). The way MergeUi used to work was that it enumerated the schemas and tables in a project and let you create a merge statement in the post-deploy script. The problem with that is that you may want to have different versions of the table for different environments or you may want to put the merge in a different script and either reference it using :r imports or not reference it at all.

What is the ScriptDom? The ScriptDom is an api for taking t-sql scripts, converting them into an AST or taking an AST and generating t-sql. What is an AST? Read this: https://en.wikipedia.org/wiki/Abstract_syntax_tree Think about this: select col from tablea select col from tablea select col /*from not_table*/ from tablea select –not_col col from tablea and then something more complicated like: select col from (select a as col from something /*else*/) a