Migrate SQLPrompt Snippets to VSCode

-
 I love snippets; love em. And I have a whole bunch in RedGate SQL Prompt. Now I want to be able to use those in VSCode as well, but boy do I dread having to retype all of them. Solution? Python! First arg is the path where your SQLPrompt snippets are Second arg is the directory where you want it to spit out a "sql.json" file with all your snippets. """ A script to translate sqlprompt snippet files to vscode formatted snippets """ import os import json import glob import io import argparse class SQLPromptPlaceholder :     """Represents the values of a SQLPrompt placeholder"""     def __init__ ( self , name , default_value ):         self . name = name         self . default_value = default_value class SQLPromptSnippet :     """Represents the content of a SQLPrompt snippet"""     @ staticmethod     def from_file ( filename ):         """Generates an instance fr...
Post a Comment

SqlXP

-

I think SQL Extended Properties are awesome. In a nutshell, they allow you to attach arbitrary key-value pairs to SQL objects of almost any kind. I've used them for things like simple documentation, to enabling special functionality for maintenance procs, or marking all tables serving a particular function in a system. They're just cool. The biggest pain in the butt IMHO is just managing them; creating them, updating them, and to a lesser extent, viewing them.

The biggest problem is scripting them. SQL gives three procs for managing extended properties:

Each of those does exactly what it says on the tin. The pain is that they will fail if you start in the wrong state. I.e. 

  • Add will fail if the property already exists
  • Update will fail if the property does not already exist
  • Drop will fail if the property does not already exist
Which means if you want to add XP management to any re-runnable script, you have to bake in if-then-else logic for every call.

I created a github repo for a project I created called SqlXP which adds some utilities to make this process less painful. It centers around a new marked system object called sp_setextendedproperty which basically allows you to use whichever of the official procs is appropriate based on the inputs. You can tell it do drop stuff, add if not exists, or upsert (add if not exists, and update if different).

The rest of the objects are basically quality of life improvements. For example, 99% of the time when I'm adding an XP, it's to a schema object (db.schema.myObject). Which makes a bunch of the parameters to the official procs repetitive (e.g. level0type = 'SCHEMA', level0name = 'dbo', level1type = 'Table'...etc).

I've made helper procs which can just figure out the types for most of the common object types, including going down to the "minor type" level (i.e. parameter or column). 

Anyway, check it out, and let me know what you think.

Comments

Post a Comment

Popular posts from this blog

Migrate SQLPrompt Snippets to VSCode

-
 I love snippets; love em. And I have a whole bunch in RedGate SQL Prompt. Now I want to be able to use those in VSCode as well, but boy do I dread having to retype all of them. Solution? Python! First arg is the path where your SQLPrompt snippets are Second arg is the directory where you want it to spit out a "sql.json" file with all your snippets. """ A script to translate sqlprompt snippet files to vscode formatted snippets """ import os import json import glob import io import argparse class SQLPromptPlaceholder :     """Represents the values of a SQLPrompt placeholder"""     def __init__ ( self , name , default_value ):         self . name = name         self . default_value = default_value class SQLPromptSnippet :     """Represents the content of a SQLPrompt snippet"""     @ staticmethod     def from_file ( filename ):         """Generates an instance fr...
Read more

JOINs Using Playing Cards

-
Image
A few co-workers asked me to explain some of the nuances of different join types (outer joins in particular). I've always reached for Venn diagrams in the past, but I was trying to think of a better way to get the information across. Whether or not I succeeded, I'll let you be the judge. I'm not going to do much in the way of explaining each of the diagrams, but I will label each diagram. I also included a diagram at the end of a common trick for inserting only rows which don't already exist in the target table (using a left outer join, and checking where the right values are null). Please feel free to use this code and the diagrams if you think they're useful. If you do, it would be nice to credit me with them, but I'm hardly going to get mad if you don't. I'd much rather there just be good training materials out there. The Code if object_id('tempdb.dbo.#Cards') is not null drop table #Cards create table #Cards ( NumericValue tinyint n...
Read more

View Default Constraints

-
A co-worker today couldn't figure out how a column, ostensibly being set to null held a value of 0 instead of null. I looked at the populating code and couldn't find anywhere a null was being replaced with a value of zero, so the most likely candidate was a default constraint on the column. Turned out he wasn't sure how to find default constraints on columns. The easiest way is to use the sp_help function on the table name, or highlight the table name and hit alt-f1. exec sp_help myTable At the bottom, you'll find all the constraints on the table, including default constraints. If however your table is not part of the dbo schema (as the Aventureworks sample database is fond of doing) you won't be able to use those methods on the table as it assumes the object exists in the 'dbo' schema. Instead, you can access the data via the Dynamic Management Views (DMVs) like this: select TableName = object_name(c.object_id), DefaultConstraintName = d...
Read more