I am using SQL Server 2008 R2 Full text indexing. I noticed that some results from my search are not included in the result. On further investigation I found that the suspected data contains ASC II control characters (http://www.theasciicode.com.ar/ascii-control-characters/escape-ascii-code-27.html). My table is in a simple flat structure and if any row contains one of those characters, the results are not displayed.
As soon as I replace the character in the data, the result appears. I am using CONTAINS in the query.
I could not find a link that confirms this behaviour. I can remove those characters from the database, but would be nice to have confirmation and understanding of the reason. Any help would be appreciated.
I think I figured out the issue. On investigating the full text crawl log I found the database size was reached (it is express edition). After doing some clean up all the rows are being returned properly.
The link that helped me in troubleshooting: http://technet.microsoft.com/en-us/library/ms142495(v=sql.105).aspx
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.
This is an error message I get after processing an SSIS Cube
Errors in the back-end database access module. The size specified for a binding was too small, resulting in one or more column values being truncated.
However, it gives me no indication of what column binding is too small.
How do I debug this?
This error message has been driving me crazy for hours. I already found which column has increased its length and updated the data table in the source which was now showing the right length. But the error just kept popping up. Turns out, that field was used in a fact-to-dimension link on Dimension Usage tab of the cube. And when you refresh the source, the binding created for that link does not refresh. The fix is to remove (change relationship type to 'No Relationship') and re-create that link.
Upd: Since that answer seems to be still relevant, I thought I'd add a screenshot showing the area where you can encounter this problem. If for whatever reason you are using a string for Dimension-to-Fact link it can be affected by the increased size. And the solution is described above. This is additional to the problem with Key, Name, and Value Columns on the Dimension Attribute.
ESC is correct. Install the BIDS Helper from CodePlex. Right click on the Dimensions folder and run the Data Discrepancy Check.
Dimension Data Type Discrepancy Check
This fixed my issue.
Open your SSAS database using SQL Server Data Tools.
Open the Data Source View of the SSAS database.
Right click an empty space and click Refresh
A window will open and show all changes to the underlying data model.
Documentation
Alternate Fix #1 - SQL Server 2008 R2 (haven't tried on 2012 but assume this will work).
Update / refresh your DSV. Note any changed columns so you can review.
Open each dimension that uses the changed columns. Find the related attribute and expand the properties KeyColumns, NameColumn and ValueColumn.
Review the DataSize properties for each and if these do not match the value from the DSV, edit accordingly.
Alternate Fix #2
Open the affected *.dim file and search for your column name / binding.
Change the Data Size element: <DataSize>100</DataSize>
As Esc noted, column size updates can affect the Dimension Usage in the cube itself. You can either do as Esc suggests, or edit the *.cube file directly - search for the updated attribute and related Data Size element: <DataSize>100</DataSize>
I've tried both fixes when a column size changed, and they both work.
In my case the problem was working on the cube on live server.
If you are working on the cube live, connecting to the server this error message pops up.
But when you are working on the cube as a solution saved on the computer you do not get the error message.
So work on the cube locally and deploy after making changes.
In my particular case, the issue was because my query was reading from Oracle, and a hard-coded column had a trailing space (my mistake).
I removed the trailing space, and for a good measure, Cast the hardcoded value to be CAST ('MasterSystem' as VarChar2(100)) as SOURCE
This solved my particular issue.
I encountered this problem. The question decided by removing leading and trailing spaces and functions rtrim and ltrim.
I encountered the same problem, refreshing the data source did not work. I had a Materialized Referenced Dimension for the Fact Partition that was giving me the error. In my DEV environment I unchecked Materialize and processed the partition without the error.
Oddly, now I can enable Materialization for the same relationship and it will still process without issue.
Simple thing to try first - I've had this happen several times over the years.
Go to data source view and refresh (it may not look like anything happens, but it's good practice)
Edit dimension. Delete the problem attribute, then drag it over again from the data source view listing.
Re-process full.
As others have mentioned, data with trailing spaces can be the cause as well. Check for them: SELECT col FROM tbl WHERE col LIKE '% '
Running into the same problem, the answer from Esc can be a solution too. The cause is much more 'hidden' and the more obvious solutions 'Refresh' and 'Data type discrepancy check' don't do any good in my case.
I did not find a proper way to "debug" this problem.
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 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.
I''ve a little problem while using SQL Server Full Text Search.
Let me explain,
I've a table with a BLOB inside (a PDF file).
I've created the full text index in that table like it should be.
I've the PDF iFilter from Adobe.
BUT, when I put some files in my table and execute a search like:
SELECT *
FROM MyTable
WHERE FREETEXT(*, N'thank');
It only returns the columns from my table (well, that's what I asked, right?).
But I wanted to return the sentence where the word 'thank' was found.
Is there any way to do this?
I've been fighting with this issue for almost 2 days...
Do you have any evidence that the PDF IFilter is working from within SQL Server at all?
Just as a test put an MS Word 2003 doc in there and see if it gets indexed properly.