July 29, 2009 at 12:29 am
Comments posted to this topic are about the item Trouble printing out long VARCHAR(MAX) strings?
July 29, 2009 at 3:05 am
I had exactly this problem with a script I wrote that would print out any stored procedures and functions that were created or modified between 2 dates. We use it for deployment scripts but when we have very large SPs they get truncated, this script of yours will be fantastic.
P.S. I tried to vote for this but the voting control will not move from 1 vote
July 29, 2009 at 3:14 am
July 29, 2009 at 5:54 am
Thanks very much for this very timely article. We just ran into this problem a few weeks ago and it was just great timing that your elegant solution was presented.
Very helpful, and very much appreciated!
July 29, 2009 at 7:01 am
Nice post.
Just out of curiosity/ignorance/inexperience, may I ask you where are we likely to write 50000-100000 lines of Dynamic SQL. I only have ~2 yrs of exp with SQL, that justifies the question.
July 29, 2009 at 7:16 am
When writing SQL code generators it is very likely that you will exceed this limit.
July 29, 2009 at 7:28 am
Had the same issue with a column into which I was stuffing large XML strings. A simpler workaround, if your string happens to be XML, is to type the column as XML--there appears to be no size restriction on the output of the XML data type. select convert(xml,DATACOLUMN) as "DataXML"
July 29, 2009 at 8:23 am
I had worse issues when I tried to run the SQL through OSQL.EXE ... it seemed to like to (almost randomly) truncate strings to be even smaller.
I ended up writing code that would parse the string line by line, and PRINT out each line in its own print statement. That was the only thing that seemed to work, ugly as it was.
These limitations really are ridiculous.
July 29, 2009 at 8:48 am
I'm not sure this constitutes much of an issue, and probably not a bug in any case. This is a limitation with the print statement itself and has nothing to do with the (n)varchar(max) data type. I have run in to this very problem outside of the (max) type when concatenating strings together.
My work around was to actually SELECT the column of data I needed and work with the object that way. I was curious if this would work, so I just tested on SQL 2005 x64 Standard (no service packs). My table is a single field called MyString of type varchar(max). I inserted a string of Lorem Ipsum that was a bit over 11,000 characters. As the article stated, printed the string truncated at character 8000. SELECTing the field did no truncation.
July 29, 2009 at 8:57 am
Here's a funny hack. Knowing that XML data doesn't have the limitation, I ran this query on a non-XML column [Note: can't get this to appear right--there's a CDATA node inside the x tag, and concatenated inside the CDATA is your column]: SELECT CONVERT(xml, '') AS DataXML FROM MyTable. It spit everything out despite the length exceeding the max for a string. Just have to strip off the containing XML tag, and you've got your string.
July 29, 2009 at 8:58 am
I voted. Thanks for pointing this out.
I haven't run into this myself, but it seems like a basic need.
Thanks for sharing.
July 29, 2009 at 9:23 am
A solution I've found for this issue of SQL Server truncating the VARCHAR(MAX) value is to right click the table I want in the Object Explorer and "Open Table". This view doesn't truncate the values within each field.
If it's a small table, you're done, and you can copy the entire VARCHAR value out of the field from this view.
If it's a big table, you can stop the query, click the "Show SQL Pane" icon that shows up in your toolbar, and write or copy/paste your query in the window that appears. The editor is akin to Access's Query Editor, which means it sucks, but this is the fastest, most fool proof way I've found to quickly get the entire string in a table.
July 29, 2009 at 9:44 am
In my project I was not using tables to hold the string...just variables. I tried building a variable with the very long string and then just doing a SELECT @VariableName but it only printed out 8,192 characters.
BTW, this is all on the 32-bit version of SQL Server.
SB
July 29, 2009 at 10:08 am
This is in the 32-bit version of SQL Server as well. In my experience, it's usually good practice to store the generated dynamic SQL in a log table for easy debugging later on. Not exactly related to this post, but something to consider.
July 29, 2009 at 10:51 am
We had the same issue.
We have a dynamically assigned security model that allows different levels of heirarchy in an organization to view data by creating where clauses which include or don't include data contained in our dashboard pivot grids / graphs. Basically with any field that we supply in our dashboard queries, we allow the end users to limit data that is then viewable by subordinates in an organization (a CFO can limit a regional manager's access to the exact same financial query by say division, the regional manager can then limit a branch manager's access by branch etc...). As the where clause is generated further down the list getting more and more specific, often times our where clause has exceeded 8000 characters. Our solution was pretty simple, we'd use a temp table with one text field, build our where clause into that field and then at the end of the where clause generator, simply perform a select on the text field of the temporary table... this is then added to the query inside c# code that generates the dataset.
Viewing 15 posts - 1 through 15 (of 39 total)
You must be logged in to reply to this topic. Login to reply