I have a remote SQL Server that I can connect to using a local instance of SSMS.

When raising errors, we use

RAISERROR( 'This works', 16, -1 )

Remotely, this works fine if it's all uppercase, or even if any one letter is uppercase.

raiserRor( 'Still works', 16, -1 )

If I try to run it using all lowercase though, it does not work

raiserror( 'Error', 16, -1 )

It returns the error message

Msg 121, Level 20, State 0, Line 3
A transport-level error has occurred when receiving results from the server. (provider: TCP Provider, error: 0 - The semaphore timeout period has expired.)

Even if I comment out the lowercase raiserror statement it still fails with the same error message.

If I log on to the server and execute these statements, they all work. It only seems to be when I connect remotely that this is an issue.

Why can't RAISERROR be completely lowercase? Even if commented?

The server is an install of SQL Server 2012 Developer edition on Windows Server 2012.

Microsoft SQL Server 2012 - 11.0.5058.0 (X64)
May 14 2014 18:34:29
Copyright (c) Microsoft Corporation Developer Edition (64-bit) on Windows NT 6.2 (Build 9200: ) (Hypervisor)

I've used local installs of SQL Server Management Studio 2012 and 2014 and tested against databases with 2005 and 2012 compatibility levels and the same behavior occurs.

I tested on other machines and the same results occurred. I don't currently have a machine to test outside of our companies network though.

  • I can't reproduce this problem - keywords in SQL Server are not case sensitive. Can you provide some more details, including @@version for your remote server, whether it's Azure or on Amazon or in your data center, version in Help > About for SSMS, and whether you can reproduce this on any other local machine connecting to the remote server. Feb 12, 2016 at 18:04
  • why do you mean by "I connect remotely"? Can you explain what you do and how you do it? Feb 12, 2016 at 18:05
  • @AaronBertrand, updated my question.
    – Brandon
    Feb 12, 2016 at 18:34
  • Is it possible your network is just flaky and the same thing would happen even if you never issued explicit raiserror calls in upper or lower case? Feb 12, 2016 at 18:47
  • @AaronBertrand, I don't believe that to be the case. This is really the only issue we've had, and I can reproduce it on multiple machines consistently.
    – Brandon
    Feb 12, 2016 at 18:53

1 Answer 1


This issue may actually be related to a very old bug with SQL Server, but not directly caused by SQL Server itself.

I found this MSDN thread which describes the exact same behavior

Please note the strangeness of this: RAISERROR won't compile (connection time out), even if it is in a comment!

This was the accepted answer

It turns out that the network that our SQL Server is on has an intrusion prevention system. In that system there is a filter with the following description:

This filter detects access to the raiserror procedure on port 1433. The raiserror procedure in a Microsoft SQL Server contains a buffer overflow vulnerability, which can be remotely exploited to execute arbitrary computer code on the affected system, thus allowing an attacker to gain complete control of the server. The procedures known to be vulnerable are: xp_sprintf, raiseerror() and formatmessage(). If the overruns are exploited, the code runs in the context of a local administrator account.

There is an old MS Security Bulletin for this bug and a more recent TechNet thread describing the same issue.

It's possible there is something on our network that I am not aware of that is filtering out anything with the text raiserror in it (but doing a poor job of it since the check is case sensitive). Not that it matters since the bug was fixed.

Since this isn't recognized behavior of SQL Server then it could likely be a network configuration issue.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.