SQL Server Blog

The debate about INSERT INTO vs SELECT INTO can be quite long and get people quite heated and therefore I’m not going to go into the entire thing right now, but what I did want to mention was something that I encountered the other day and which could be worth considering next time you’re deciding which approach to take.

I’ve done a couple of posts about RAISERROR, but if you’re using SQL Server 2012 and above then there’s a new syntax also available which I think is a little better. That syntax is THROW.



This does a very similar job to RAISERROR but has a couple of advantages that I want to highlight.

Now we’ve used RAISERROR (as per my previous post) we need to address a specific issue which RAISERROR has and which we need to overcome in order to make this more useful. That would be that issue that SQL Server doesn’t show messages until the very end of execution. This will fix that issue.



Basically the NO WAIT extension will cause SQL Server to output the message to the window immediately and not wait until the end of execution.

Have you ever written code and you want custom error messages to be returned as you go? Or to stop execution where YOU define an error has occurred even when it’s not a real error? You can use raiserror to achieve this. This is simple syntax and quite powerful.

This is a quick and dirty bit of code which I’ve used on occasion when trying to put a database which is in single user mode back into multi user mode but which is accessed so frequently that all you receive is an error message stating you are the deadlock victim.

This is a direct follow up to my previous post on Tracer Tokens and Replication Latency.



This post will include some simple code to check for excessive latency in your replication and, if appropriate, send out an email informing you of the problem.

After my last post surrounding Tracer Tokens I was told by a friend that it was a little harsh to simply end saying that you can just join to a few system tables and make something meaningful. Therefore I’ve given in and this post will show you how you can use tracer token and system data to your advantage.

If you’re using Transactional Replication then these can be invaluable to you. These are incredibly lightweight, easy to use, and they will help you with all manner of reporting and troubleshooting within your replicated environment.



Effectively a Tracer Token is a marker placed in the transaction log of your database that is meaningless to all of SQL Server except your Log Reader which sees it and replicates it through to your subscriber, tracking it at every step of the way.

This is a handy hint as to how to access a network drive from within SQL Server. It just happened to be something that I was using in some code and was asked what the code was doing.



As a rule, SQL Server cannot see anything but attached drives. Therefore even though you can log onto the server yourself and map a network drive, SQL Server will likely not be able to see it, ruining the plans you’d just come up with. Well there are ways around this.