August 28, 2008 at 6:06 am
Hello all,
I was trying to deploy the cube and get the error
Warning1Errors 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.
It was working fine till yesterday. Could not figure out the issue. Please help me out.
Thanks
sanjay
August 28, 2008 at 7:00 am
You have a field length specified for an attribute in one of your dimensions that is shorter than the data in the database field.
August 28, 2008 at 7:38 am
but if i create a new Project with the same dimension table and fact table, its working
August 26, 2011 at 10:39 am
For all you people that get this mysterious error when updating the backend DB using a SQL script and a temp table. I also got this error recently "The size specified for a binding was too small, resulting in one or more column values being truncated." after running a script to update a table in the DB. Here is what I found out.
The specific column I was updating in the DB table was defined as a varchar(10) in the DB. I defined the same column in the temp table in the SQL script as a char(5). This field never contains more than 3 characters. As such, the Cube (Analysis Server) had this field defined as a wchar(3). The original update script worked fine against the DB, but failed in the cube processing. After running the scripts numerous times, I determined the following: 1) Either define the column as a varchar in the temp table with a size equal to or larger than the data (3) or 2) define it as char(3), which is the same size as the field in the cube.
Apparently, Analysis Services does not use the data type and size definition from the back-end DB, but instead creates it's own definition based on the type of data it is processing. As I said, this data is never greater than 3 characters, is usually numeric in nature, but can contain blanks or nulls. Therefore, Analysis Services defined it as a wchar 3. Somehow, when I ran the update script against the DB with temp table column defined as char(5), the size of 5 characters carried through from the DB to the Cube. Thus the error in processing the cube.
My recommendation is to define columns in temp tables in scripts the same size and type as they are defined in the DB. In this case a varchar(10). Good luck.
Viewing 4 posts - 1 through 3 (of 3 total)
You must be logged in to reply to this topic. Login to reply