How can we help you today? How can we help you today?
mago
Dears: I know you mentioned the script to point out the data in previous post. So I tried to execute it. DECLARE @table nvarchar(80), @column nvarchar(80), @qry nvarchar(255) DECLARE cColumns CURSOR FOR select o.[name] AS , c.name AS [Column] from syscolumns c INNER JOIN sysobjects o ON c.[id]=o.[id] where c.xtype IN (select xtype from systypes where name IN ('nchar', 'ntext', 'nvarchar')) AND o.xtype='U' OPEN cColumns FETCH NEXT FROM cColumns INTO @table, @column @FETCH_STATUS=0 BEGIN SELECT @qry='SELECT FROM WHERE CAST( AS BINARY) BETWEEN 0xdddddddd AND 0xffff' exec sp_executesql @qry FETCH NEXT FROM cColumns INTO @table, @column END CLOSE cColumns DEALLOCATE cColumns GO After execution this sql, it point out more than 10 thounds records may have problems in a specific table. Even if we know the offending rows, how could we do ? we still couldn't correct or delete it because it's for user input, not us. Besides that, when I execute data compare using our software, it shows error from System.Text.UTF8Encoding.GetByteCount. But if we write a .Net program to read db and parse it directly with System.Text.UTF8Encoding.GetByteCount, it didn't show any error. It's just our testing. I hope this could provide some info to you. [image] Brian Donahue wrote: Hi mago, I suspected the update wouldn't help. SQL Server will happily allow you to stuff binary data into an nvarchar field. When Data Compare sees the column type is nvarchar, it knows to resolve the data to Unicode for displaying in the grid. If the type converter encounters byta values between 0x7FFF and 0xFFFF, then it can't be converted to Unicode. Maybe if you post up the table schema, I can construct a query that will point out the offending row(s) of data. / comments
Dears: I know you mentioned the script to point out the data in previous post. So I tried to execute it. DECLARE @table nvarchar(80), @column nvarchar(80), @qry nvarchar(255) DECLARE cColumns CURSO...
0 votes