I have problem about encoding when data compare

magomago Posts: 36
I got an error:
Unexpected error: Found a low surrogate char without a preceding high surrogate
at index: 121. The input may not be in this encoding, or may not contain valid
Unicode (UTF-16) characters. Parameter name: chars
Found a low surrogate char without a preceding high surrogate at index: 121. The input may not be in this encoding, or may not contain valid Unicode (UTF-16) characters.

My sql compare is ver 3.3.8.304
Should i update it ? Please advised. Thanks

Comments

  • Brian DonahueBrian Donahue Posts: 6,590 Bronze 1
    Hi Mago,

    Updating may help, but as far as I know there is no fix for the root cause of this problem. This happens if someone has inserted certain binary values into an nvarchar or nchar column that cannot be resolved as Unicode because of conflicting information about continuation character data. (To make a long story short!)
  • Dears:


    It happens again. It staill couldn't work after upgrade. >_<
    Could you please give resolved way about that ?
    For us, the table is important and must be synced.
    Thanks a lot.

    Regards,
    Mago

    Hi Mago,

    Updating may help, but as far as I know there is no fix for the root cause of this problem. This happens if someone has inserted certain binary values into an nvarchar or nchar column that cannot be resolved as Unicode because of conflicting information about continuation character data. (To make a long story short!)
  • Brian DonahueBrian Donahue Posts: 6,590 Bronze 1
    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.
  • 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. >_<

    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.
  • Dears :

    I found there is "SQL Backup" software in your product list. :D
    How about its speed ?
    We have a database its data backup size is up to 1.7G.
    We want to sync database every hour.
    Could we use this product to replace SQL Data Compare ?
    Thanks for your info in advanced. :)


    Regards,
    Mago
  • Brian DonahueBrian Donahue Posts: 6,590 Bronze 1
    Hello Mago,

    You can implement automatic replication of databases using a technique called log shipping using SQL Backup. This works when you want to have a standby copy of a database because when the log shipping is taking place, the log shipping destination has to be in READ ONLY or Loading mode.

    There is more information here:

    http://www.red-gate.com/sql/more/log_sh ... backup.htm
This discussion has been closed.