by jfisch
1. October 2010 07:03
Createc Connect Bug for an issue caused by a Visual Studio dialog adding a ASCII 127 character to a database name.
https://connect.microsoft.com/SQLServer/feedback/details/608963/database-names-containing-control-characters
You can't tell the difference between the names within Management Studio.
Vote for it if you like.
by jfisch
7. October 2009 10:28
I've logged a bug against SQL Server 2008 for sp_help throwing errors on columns greater than 106 characters (I know, a bit of a stretch). I was in the middle of writing some code for automating a data pull and ran into this. If you're able, go and add to the repro count for the bug with the script I've attached. It's really simple, it creates a two column table, runs sp_help on it then drops the table.
https://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=496501
Thanks,
Jeff
by jfisch
22. August 2009 19:45
I was just helping a friend figure out his connection issue to SQL Server. He was getting error number 18456 with a severity of 14 and state of 11. He was running this on a recent fresh install of Windows 7. It turns out that he still had UAC enabled on his box and this was the culprit. It was then that I realized that UAC is like a computer prophylactic. As you can surmise, I'm not too fond of UAC, like the rest of the population. Just beware of your prophylactic causing you problems in the event you run into this severity and state.

Either right click SQL Management Studio and "run as administrator" before trying to connect or just disable UAC all together. I prefer the latter.
Jeff
by jfisch
2. June 2009 05:28
Today, while building a procedure that imports data into a database I ran into a pretty significant SQL Server performance problem that I thought I should blog about to get ahead of someone running into the problem in production.
The basics of the solution that I was building are this, I am passing in an input xml file into a procedure (datatype xml) and querying this xml against the data to be updated by this import xml. The query takes data from the xml and does various checks against the database to see where their may be issues with the "to be imported" data. It formulates the results of these checks into a resulting validation xml using FOR XML EXPLICIT. Once verified, the procedure modified the data within the database. The results xml created by the validation was used as an output parameter of the stored procedure.
I found that the compilation of the procedure seemed to take a significant amount of time based on the selection of the nodes method of the xml variable. Upon adding statemetns including @xml.nodes(...) into the stored procedure the compilation of the procedure took drastically longer (1 min 15 seconds per compile to e exact). After compilation the procedure took less than 1 second to execute. I tested the procedure DBCC FREEPROCCACHE to see if it was the procedure cache creation specifically that was slowing the procedure down and sure enough it was. I then tested to see what the effect of adding WITH RECOMPILE to my procedure would be. As I suspected, every execution of the procedure began taking 1 min 15 seconds to execute because of the recompilation of the procedure. The final behavior that I tested was the number of @xml.nodes(...) references within the procedure. It appeared to have a direct correlation between the number of @xml.nodes(...) statements/joins and the length of time it took to create the procedure cache. Of course, after first execution (excluding WITH RECOMPILE) the procedure executed instananeously.
So, my suggestion is to be very weary of procedure recompiles on procedures that require the nodes method. Please be ware! Take a look at the attached script for example purposes. I've duplicated similar, yet more condensed, logic as an example of my efforts and experience.
AdventureWorksSQLXmlProcedurePlan.sql (1.50 kb)
Jeff Fischer
b7614ead-b265-4782-8e4e-fc4c1c1d57ff|0|.0
Tags: sql, t-sql, sql 2005, sql 2008, xml datatype, nodes method, for xml explicit, value method, with recompile, sql xml, sqlpto, performance, download
SQL | Performance
by jfisch
29. May 2009 18:52
I had the pleasure of performing an age-old task within SQL Server this evening, recreating a SQL Server dependency chain. After googling and not coming up with much immediately I went down the path of creating the SQL myself. Actually, I was fixing a bug in a previously failed attempt at creating the dependency chain with a T-SQL statement, but anyways. I created the below T-SQL based on the following assumptions that I had validated within my database.
- That the database contains a currently valid dependency chain. ie. that you have not dropped a "lower level" dependent object and recreated it. If so, you need to recreate the "upward" dependent objects to ensure a valid dependency chain exists within the database.
- That the dependencies are stricly based on views.
- That the procedures are only dependent on views and no cross-procedure dependencies exist.
CREATE VIEW [dbo].