I have been doing SQL for a while and I've always been satisfied to use the Results to Grid found in SSMS.
Now I have a series of queries that I am running and I would like to have some very simple formatting of the results. Currently neither the Results to Grid nor the Results to Text do quite what I would like to do.
A few things I would like to do so it is easier for me to read is
Remove the text that says '# row(s) affected' (found in the Results to Text)
Make the columns not so wide in the column aligned Output Format (part of the problem is that the Maximum Number of Characters does not appear to go below 30 - is this my data that forces this?)
If I cannot format the output (even to a text file) what other options do I have ?
I spent some time looking at SQL Server -> PHP -> HTML as well as SQL Server -> Reporting Services -> MS Report Builder but quite frankly it seems like overkill to put a few spacers and pretty up the headings a bit.
I feel like I am missing something here ... I would rather not go through the hassle of all that installation of PHP and what not just to be able to look at my data a little bit prettier.
Remove the text that says '# row(s) affected' (found in the Results to Text)
Put this SET NOCOUNT ON at the top of your sql
Make the columns not so wide in the column aligned Output Format (part
of the problem is that the Maximum Number of Characters does not
appear to go below 30 - is this my data that forces this?)
Yes its the size of the field that does this. You can cast it cast(field as varchar(20)to make it smaller if you know you won't lose data.
It all depends on what you want to do with the formatted results.
For quickly reading / formatting a result that isn't great when viewed directly in Management Studio, I use Results to Grid, select all with headers (by right-clicking on the upper-left corner of the grid), and copy/paste into Excel. From there it's easy to do basic tinkering with column widths and formatting. The biggest downside for me is dates are never quite right out-of-the-box, but it's always a quick fix.
Excel also makes a good interim stop for basic formatting when I'm pasting query results into an email.
It might be overkill in some cases, but I suspect much less so than using PHP -> HTML or Reporting Services -> MS Report Builder.
Related
A lot of the front end user's don't give a rat's ass about data input quality. My SSMS query retrieves the data beautifully with the correct number of rows output, as expected.
On pasting into Excel you get a different number of rows and the set needs playing around with. I believe it's because the data input in that field is weird / non-standard.
Is the only way to fix this editing the source data or making a big exception clause? I don't want to go via csv and text to columns either.
Can anybody tell me what the N is at the beginning of value in WHERE clause from Crystal Reports show SQL Query is doing (example below)? When I plug in as is into Sql Server, the query returns much slower because it appears to be initially going through way more records than it needs. When I removed the N, I get much faster results, and it doesn't seem to be hitting as many records. Is there a way to prevent Crystal from adding this when running reports? Any help would be greatly appreciated.
Example: ...WHERE "usr_MasterBill"."car_move_id"=N'M090036749'
It uses 16 bytes for each character, allowing unicode strings to be created. This kind of string should be assigned to nvarchar, nchar, ntext etc. data types.
https://dba.stackexchange.com/questions/36081/write-differences-between-varchar-and-nvarchar
The problem is not the N in the query, but how CR works, in some cases the CR Core decides that is better retrieves all registers and filter on presentation load.
Verify the "Select expert" for additional filters, or in change group options "Specified Order". You need check to the formulas fields
I have dozens of SSRS Reports and the corresponding stored procedures that I am slowly cleaning up and optimizing, I am finding a number of data sets that have extra fields that are not used in the actual report, they are usually the result of a SELECT * that is slowing down the SP end of things significantly in a few places.
I am wondering if there is a quicker way to see which fields from the datasets are used/unused to more efficiently clean up the stored procedures. It seems like clicking through to each <<expr>> and checking them off is a ridiculous way to go about this.
I'll tell you, I wish I knew a tool that simplifies this for you.
And I don't off the top of my head.
But for sure I know you can search the text of the rdl and find these details.
I do this often when troubleshooting problems with existing reports (or SSIS packages).
The .rdl files are human-readable xml.
You can open any one file in a text editor and search the text - even Visual Studio if you "Open File" rather than use the Report project.
Given that, of course you can write a routine in your preferred programming language that
finds the query or proc in the data source of the Report
runs it (as metadata only) to get all the columns
search for each one in the text of the rdl
you can be more specific if you use xml queries to limit
the search to more realistic targets like display box Data Sources
Sorry I don't have a more convenient answer like an existing tool.
If I remember, I may look for one because this is a big problem for "corporate coders" like us.
If I can't find one, maybe I'll write the script in .net and come back and post it :)
Yes you can ! Use the following steps
right click the rdl file and
click the View Code . This will be an XML format
CTR + F to get a search text box
Enter the name of any field in the text box.
Use the Forward Arrow icon to see the number of occurrence of the searched field name
If the text field is in the dataset and Tablixcell value, then it shows it's being used in the report
If the text field is only in the dataset and not any tablixcell value, then it's not being used in the report.
Ok I'm using SQL Server 2008 and have a table field of type VARCHAR(MAX). Problem is that when saving information using Hibernate, the contents of VARCHAR(MAX) field is getting truncated. I don't see any error messages on either the app server or database server.
The content of this field is just a plain text file. The size of this text file is 383KB.
This is what I have done so far to troubleshoot this problem:
Changed the database field from VARCHAR(MAX) to TEXT and same
problem occurs.
Used the SQL Server Profiler and I noticed that the full text
content is being
received by the database server, but for some reason the profiler freezes when trying
to view the SQL with the truncation problem. Like I said, just before it freezes, I
did noticed that the full text file content (383KB) are being received, so it seems
that it might be the database problem.
Has anyone encountered this problem before? Any ideas what causes this truncation?
NOTE: just want to mention that I'm just going into SQL Studio and just copying the TEXT field content and pasting it to Textpad. That's how I noticed it's getting truncated.
Thanks in advance.
Your problem is that you think Management Studio is going to present you with all of the data. It doesn't. Go to Tools > Options > Query Results > SQL Server. If you are using Results to Grid, change "Maximum Characters Retrieved" for "Non XML data" (just note that Results to Grid will eliminate any CR/LF). If you are using Results to Text, change "Maximum number of characters displayed in each column."
You may be tempted to enter more, but the maximum you can return within Management Studio is:
65535 for Results to Grid
8192 for Results to Text
If you really want to see all the data in Management Studio, you can try converting it to XML, but this has issues also. First set Results To Grid > XML data to 5 MB or unlimited, then do:
SELECT CONVERT(XML, column) FROM dbo.table WHERE...
Now this will produce a grid result where the link is actually clickable. This will open a new editor window (it won't be a query window, so won't have execute buttons, IntelliSense, etc.) with your data converted to XML. This means it will replace > with > etc. Here's a quick example:
SELECT CONVERT(XML, 'bob > sally');
Result:
When you click on the grid, you get this new window:
(It does kind of have IntelliSense, validating XML format, which is why you see the squigglies.)
BACK AT THE RANCH
If you just want to sanity check and don't really want to copy all 383K elsewhere, then don't! Just check using:
SELECT DATALENGTH(column) FROM dbo.table WHERE...
This should show you that your data was captured by the database, and the problem is the tool and your method of verification.
(I've since written a tip about this here.)
try using SELECT * FROM dbo.table for XML PATH
I had a similar situation. I have an excel sheet. A couple of columns in the sheet may have more than 255 chars, sometimes even 500. A simple way was to sort the rows of data, placing the rows with the most characters up on top. You actually need just one row. When SQL imports the data, it recognizes the field being more than 255 characters and imports the entire data :)
Otherwise, they suggested using regedit to change a specific value. Didn't want to do that.
Hope this helps
I'm converting a client's SSIS packages from DTS to SSIS. In one of their packages they have an execute SQL task that has a query similar to this:
SELECT * FROM [SOME_TABLE] AS ReturnValues
ORDER BY IDNumber
FOR XML AUTO, ELEMENTS
This query seems to return in a decent amount of time on the old system but on the new box it takes up to 18 minutes to run the query in SSMS. Sometimes if I run it it will generate an XML link and if I click on it to view the XML its throwing a 'System.OutOfMemoryException' and suggests increasing the number of characters retrieved from the server for XML data. I increased the option to unlimited and still getting error.
The table itself contains 220,500 rows but the query rows returned is showing 129,810 before query stops. Is this simply a matter of not having enough memory available to the system? This box has 48 GB (Win 2008 R2 EE x64), instance capped to 18GB because its shared dev environment. Any help/insight would be greatly appreciated as I don't really know XML!
When you are using SSMS to do XML queries FOR XML, it will generate all the XML and then put it into the grid and allow you to click on it. There are limits to how much data it brings back and with 220,000 rows, depending on how wide the table is, is huge and produces a lot of text.
The out of memory is the fact that SQL Server is trying to parse all of it and that is a lot of memory consumption for SSMS.
You can try to execute to a file and see what you get for size. But the major reason for running out of memory, is because that is a lot of XML and returning it to the grid, you will not get all the results all the time with this type of result set (size wise).
DBADuck (Ben)
The out of memory exception you're hitting is due to the amount of text a .net grid control can handle. 220k lines is huge! the setting in SSMS to show unlimited data is only as good as the .net control memory cap.
You coul look at removing the ELEMENTS option and look at the data in attribute format. That will decreate the amount XML "string space" returned. Personally, I prefer attributes over elements for that reason alone. Context is king, so it depends on what you're trying to accomplish (look at the data or use the data). Could youp pipe the data into an XML variable? When all is said & done, DBADuck is 100% correct in his statement.
SqlNightOwl