SIMPLE T-SQL to generate create table scripts

just run this in the database you want to script out --- use "Results to Text" mode: EXEC sp_msforeachtable 'SELECT ''Create table ? ('' UNION ALL SELECT CASE WHEN rn > 1 THEN '' ,'' ELSE '' '' END + x FROM (SELECT TOP 100 percent ''[''+COLUMN_NAME + ''] '' + DATA_TYPE + CASE WHEN DATA_TYPE IN (''varchar'',''char'') THEN ''('' + CAST(CHARACTER_MAXIMUM_LENGTH as varchar) + '')'' ELSE '''' END + '' ''+ case when IS_NULLABLE = ''YES'' THEN ''NULL'' ELSE ''NOT NULL'' END x ,ROW_NUMBER() OVER(ORDER BY COLUMNS.ORDINAL_POSITION) rn FROM INFORMATION_SCHEMA.columns WHERE COLUMNS.TABLE_NAME = replace(replace(''?'',''[dbo].['',''''),'']'','''') ) x UNION ALL SELECT '')'' ' outputs runnable create table script

turn any list of text into a table

If you're like me and you regularly get people emailing you long lists of .. whatever.. zip codes, addresses, VIN numbers, etc .. and they want you to do something with each item in the list, but the lists are always inconsistent and you spend a lot of time just cleaning up the list so you can move forward with the task, here's a handy quick cleaner upper I made. it will turn this:

lkfdjhhdf 2356345 dfsdsf dfds df fd dsffd sad,dsa,,DS,F,,FSADFSDF, DF

into a nice table:

first of all, you need this function. Split parameter string from comma seperator in SQL IN clause then we do this:

DECLARE @item_list VARCHAR(4000)
SET @item_list = 
'
lkfdjhhdf
2356345

dfsdsf

dfds

df
fd

dsffd
sad,dsa,,DS,F,,FSADFSDF,
DF
'

DECLARE @c VARCHAR(4000) = REPLACE(REPLACE(REPLACE(REPLACE(@item_list,CHAR(13)+CHAR(10),','),',,',','),',,',','),',,',',')
IF RIGHT(@c,1) = ',' SET @c = LEFT(@c,LEN(@c)-1)
IF LEFT(@c,1) = ',' SET @c = RIGHT(@c,LEN(@c)-1)

IF RIGHT(@c,1) = ',' SET @c = LEFT(@c,LEN(@c)-1)
IF LEFT(@c,1) = ',' SET @c = RIGHT(@c,LEN(@c)-1)

set nocount on
DECLARE @list AS TABLE (item VARCHAR(100))

INSERT @list
SELECT [sID] FROM redbumperdb.dbo.UF_CSVToTable(@c)

SELECT * FROM @list AS l

Set Based way to order items with SQL

so you have a list of rules or something and you want your users to be able to change the processing order

DECLARE @new_item_priority INT = 1
DECLARE @reorder_priority AS TABLE (item_id INT, item_priority INT )

INSERT @reorder_priority 
SELECT item_id, ROW_NUMBER() OVER(ORDER BY rn) AS item_priority
FROM  (
    SELECT item_id, 
    CASE 
    WHEN item_id = @p_item_id AND @new_item_priority < item_priority THEN CAST(@new_item_priority AS FLOAT) -.1
    WHEN item_id = @p_item_id AND @new_item_priority > item_priority THEN CAST(@new_item_priority AS FLOAT) +.1
    ELSE item_priority
    END rn
    FROM dbo.items
    -- WHERE clause if needed..
) x
ORDER BY rn


UPDATE i
    SET item_priority = rp.item_priority
FROM dbo.items i
JOIN @reorder_priority rp ON rp.item_id = i.item_id

SQL Agent Job Logging To Job History Using TSQL

Simple! Use a print statement! Try it! In SQL Server Management Studio (SSMS), in Object Explorer, right click the JOBS folder and click NEW JOB name it TEST click STEPS on the left hand pane click the NEW button name the step TEST STEP make sure the type is Transact-SQL script(TSQL) database can be anything, master is fine. in the big COMMAND box type: Print 'test test test' click OK twice and run the job Right click the job and click VIEW HISTORY click the + to open the list of steps, click on step on and look in the grey pane at the bottom for the details. It will look something like this:

Message Executed as user: sqluser. test test test [SQLSTATE 01000] (Message 0). The step succeeded.

that bolded text is your message! ta da!

eShop WordPress plugin - fix when Shipping Rates aka Shipping Class disappears

It's just a setting, no big deal. Go to SETTINGS >> eSHOP Scroll all the way down to the bottom of the page. --in the section CHECKOUT OPTIONS there are four drop-downs The drop-down labelled "Minimal checkout form. (this also disables shipping costs)" needs to be set to "NO". If you set this option to "yes" is takes the Shipping Rates selector off of the page and post edit screens

Decisions decisions..

So I inherited some SSRS reports that need some updating - mostly appearance stuff.. the boss wants the reports to all have a similar look and feel.. BUT yesterday in the staff meeting it turns out he also wants me to convert the PROC datasources all into table valued functions.. because they're cooler.. (which, well, they are, but anyway..) So I open up the source of the proc and inside I find a whole bunch of #temp tables. The original author filled a series of #temp tables and them hooked them all together with unions at the end. So I am now faced with a decision - do I convert these #temp tables into: - table variables - views or - subqueries Table variables - I like doing this because it's the most similar. I don't like doing this because I have to figure out what the column datatypes all are in order to declare the table variable, and that's just tedious. Views - These are nicely reusable! BUT I highly doubt they will ever get reused, and it creates a bunch of otherwise useless objects cluttering up the list of views. Subqueries - grab the query and stick it in parenthesis where the #temp table is currently called. Gets the job done, no risk of changing the results, quick and easy, I like it. Downside is .. well, it feels kinda cheesy, plus there's a chance that one of the #temp tables may be called more than once, and a there's a few of them. I'm not an "elegant code" kind of guy, I prefer to get the job done as quickly as possible and move on. Variables have the lowest impact with the fewest chance of the unexpected. Subqueries are risky but super quick implementation if everything goes right. Views would be quick too.. probably the quickest. Clutter is less of a concern to me personally than time is, but there are other DBA's and developers here and I don't have the slightest idea how someone else might react.. making objects in a database feels like bumping somebody's shoulder in a hallway on accident. Overall though, I think views is the way to go. They're super quick both to create and to implement into the rest of the new table function, PLUS I may end up being able to reuse one later, which would be a great bonus. Views it is

Here's some SQL code to change any date into the date for a particular day of that week. I'm making a report in which the business wants to see values aggregated by week-ending date (aka Friday). So all the dates have to be change dinto the friday of that week. The DATEADD formula below will do that.

DECLARE @sunday AS SMALLDATETIME
 SET @sunday = '8/26/2012'
DECLARE @friday AS SMALLDATETIME
 SET @friday = '8/31/2012'
DECLARE @saturday AS SMALLDATETIME
 SET @saturday = '9/1/2012'

SELECT 
 DATEADD(day, (DATEPART(dw, @sunday)-6)*-1, @sunday),
 DATEADD(day, (DATEPART(dw, @friday)-6)*-1, @friday),
 DATEADD(day, (DATEPART(dw, @saturday)-6)*-1, @saturday)