Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase

Column "pobs_name" value is out of range for data type "varchar". Update column to a legal value Expand / Collapse
Author
Message
Posted Tuesday, July 15, 2014 7:45 AM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Friday, December 19, 2014 7:22 AM
Points: 25, Visits: 167
Hi All,

I recently found (from our weekend maintenance) that one of our vendor databases encountered a corruption notice and am trying to figure out (without going straight to allow_repair_data_loss) what rows have the 'bad' data and what is the actual cause of this error:

I ran this command: dbcc checkdb ('pmdb_cn') WITH DATA_PURITY

Results:

DBCC results for 'POBS'.
Msg 2570, Level 16, State 3, Line 1
Page (1:110113), slot 10 in object ID 2121058592, index ID 1, partition ID 72057594055688192, alloc unit ID 72057594065453056 (type "In-row data"). Column "pobs_name" value is out of range for data type "varchar". Update column to a legal value.
Msg 2570, Level 16, State 3, Line 1
Page (1:110113), slot 14 in object ID 2121058592, index ID 1, partition ID 72057594055688192, alloc unit ID 72057594065453056 (type "In-row data"). Column "pobs_name" value is out of range for data type "varchar". Update column to a legal value.
Msg 2570, Level 16, State 3, Line 1
Page (1:110117), slot 38 in object ID 2121058592, index ID 1, partition ID 72057594055688192, alloc unit ID 72057594065453056 (type "In-row data"). Column "pobs_name" value is out of range for data type "varchar". Update column to a legal value.
Msg 2570, Level 16, State 3, Line 1
Page (1:110117), slot 42 in object ID 2121058592, index ID 1, partition ID 72057594055688192, alloc unit ID 72057594065453056 (type "In-row data"). Column "pobs_name" value is out of range for data type "varchar". Update column to a legal value.
There are 299 rows in 7 pages for object "POBS".
CHECKDB found 0 allocation errors and 4 consistency errors in table 'POBS' (object ID 2121058592).
DBCC results for 'HQDATA'.
There are 0 rows in 0 pages for object "HQDATA".
DBCC results for 'TPROJMAP'.
There are 0 rows in 8 pages for object "TPROJMAP".
DBCC results for 'WRK_LOG_RESULTS'.
There are 0 rows in 0 pages for object "WRK_LOG_RESULTS".
CHECKDB found 0 allocation errors and 4 consistency errors in database 'PMDB_CN'.
DBCC execution completed. If DBCC printed error messages, contact your system administrator.

The table structure is this:

CREATE TABLE [dbo].[POBS](
[pobs_id] [int] NOT NULL,
[seq_num] [int] NOT NULL,
[pobs_name] [varchar](255) NOT NULL,
[pobs_parent_id] [int] NULL,
[pobs_descr] [varchar](255) NULL,
[pobs_manager] [varchar](255) NULL,
[update_date] [datetime] NULL,
[update_user] [varchar](255) NULL,
[create_date] [datetime] NULL,
[create_user] [varchar](255) NULL,
[delete_session_id] [int] NULL,
[delete_date] [datetime] NULL,
CONSTRAINT [pk_pobs] PRIMARY KEY CLUSTERED
(
[pobs_id] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY]

I'm running on SQL Server 2008 R2 + SP3

When I do a count of the records in Management Studio, I get 303.
DBCC CHECKDB output says 299 rows.

So am I really missing 4 rows? Or is it indicating that there are 4 rows that have invalid data in the particular column? -- which wouldn't make sense as I would've figured the datatype definition wouldn't have allowed the data to be inserted in the first place.

Thanks in advance
Post #1592565
Posted Tuesday, July 15, 2014 8:35 AM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Friday, December 19, 2014 7:22 AM
Points: 25, Visits: 167
Digging around some more, wanted to share what I found:

Using this link - http://support.microsoft.com/kb/923247

I did a DBCC PAGE on the affected pages and went to the specific slot that reported an issue. Then I was able to find the pobs_id of that row and could do a SELECT against the table and see the 'bad data':


DBCC PAGE ( pmdb_cn , 1 , 110117 , 3 )

Slot 38 Column 3 Offset 0x3c Length 255 Length (physical) 255
pobs_name = INVALID COLUMN VALUE

select * from POBS where pobs_id=6932
???????????????????????????????聽???????????????虏???????????????楼???????????????拢???????????????庐???????????????掳????????????????


So it looks like i have 4 rows where the data is unicode (Chinese characters) and cannot fit into this column.

I'm thinking that the datatype of the column should be NVARCHAR not VARCHAR in order to accept these values and be compatible with unicode characters. The db collation is Chinese so i *think* this column should be set to nvarchar..thoughts?
Post #1592615
Posted Tuesday, July 15, 2014 8:38 AM This worked for the OP Answer marked as solution


SSC-Forever

SSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-Forever

Group: General Forum Members
Last Login: Today @ 9:22 AM
Points: 40,632, Visits: 37,094
You need to update the column to legal values, consider altering the column later. But there's no guarantee that that is even a legal unicode string. Somehow invalid values have crept in, who knows what that was or is supposed to be.

btw, repair can't fix data purity errors. You need to manually update the affected rows to valid values.



Gail Shaw
Microsoft Certified Master: SQL Server 2008, MVP
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

We walk in the dark places no others will enter
We stand on the bridge and no one may pass

Post #1592616
Posted Tuesday, July 15, 2014 8:43 AM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Friday, December 19, 2014 7:22 AM
Points: 25, Visits: 167
GilaMonster (7/15/2014)
You need to update the column to legal values, consider altering the column later. But there's no guarantee that that is even a legal unicode string. Somehow invalid values have crept in, who knows what that was or is supposed to be.

btw, repair can't fix data purity errors. You need to manually update the affected rows to valid values.


Right, I think the presence of question marks in the data indicate invalid values (hence SQL turning them into question marks), correct? Or values where the original data was a Unicode character that cannot be imported/non-compatible with the database collation..?

I will go back to the application admin to ask for valid values to be entered.
Post #1592620
Posted Tuesday, July 15, 2014 10:32 AM This worked for the OP Answer marked as solution


SSC-Forever

SSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-Forever

Group: General Forum Members
Last Login: Today @ 9:22 AM
Points: 40,632, Visits: 37,094
It's invalid values (not varchar data) that due to some bug somewhere has snuck into the table. That's about all you can say.


Gail Shaw
Microsoft Certified Master: SQL Server 2008, MVP
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

We walk in the dark places no others will enter
We stand on the bridge and no one may pass

Post #1592673
« Prev Topic | Next Topic »

Add to briefcase

Permissions Expand / Collapse