Updating nText column

Updating nText column

Post by Umachandar Jayachandra » Thu, 23 Dec 1999 04:00:00



    I think this is what is happening (you are right about unicode using 2
bytes & that is the explanation):

    If the length of your file is even, the EOF character is the last one.
Hence the actual data length is ODD. So you have to add one extra space to
make it even since UNICODE uses 2 bytes to encode each character.
    Similarly, if the length of the file is ODD & the EOF being the last
one. The actual data length is EVEN. Hence 2 bytes at a time goes in fine.

--
Umachandar Jayachandran
MCDBA, MCSE + Internet, MCP + Internet, MCSE

 
 
 

Updating nText column

Post by Simon Davie » Fri, 24 Dec 1999 04:00:00


Hi,
I'm using AppendChunk in Ado 2.1 to write text data to a nText field. I
first write the text out to a file using the SaveFile method of a rich text
box, specifying rtfText as it's type. I then read the file in as binary, and
AppendChunk, this all works fine. However, when I come to update the Ado
recordset if the LOF (length of file) I used to AppendChunk was even, I get
a "String data, length mismatch" error from ODBC! As a workaround, I'm
checking the length of the file and if it's even I'm appending a space, this
turns it into an uneven length text file. The update then works and my data
is stored. The only thing I can think of is nText is Unicode, and each
character is stored as 2 bytes, but why is the update failing? What am I
missing here?

Thanks, Simon

PS This was posted previously under the subject "String data, length
mismatch" but that was before I figured out the odd/even quirk.

 
 
 

Updating nText column

Post by Simon Davie » Fri, 24 Dec 1999 04:00:00


Thanks for the reply, it is greatly appreciated. It's a "known issue" I've
had for a while with my development and this confirmation is a relief.

Thanks.
Simon

Quote:>     I think this is what is happening (you are right about unicode using 2
> bytes & that is the explanation):

>     If the length of your file is even, the EOF character is the last one.
> Hence the actual data length is ODD. So you have to add one extra space to
> make it even since UNICODE uses 2 bytes to encode each character.
>     Similarly, if the length of the file is ODD & the EOF being the last
> one. The actual data length is EVEN. Hence 2 bytes at a time goes in fine.

> --
> Umachandar Jayachandran
> MCDBA, MCSE + Internet, MCP + Internet, MCSE

 
 
 

1. Updating nText column

    I think this is what is happening (you are right about unicode using 2
bytes & that is the explanation):

    If the length of your file is even, the EOF character is the last one.
Hence the actual data length is ODD. So you have to add one extra space to
make it even since UNICODE uses 2 bytes to encode each character.
    Similarly, if the length of the file is ODD & the EOF being the last
one. The actual data length is EVEN. Hence 2 bytes at a time goes in fine.

--
Umachandar Jayachandran
MCDBA, MCSE + Internet, MCP + Internet, MCSE

2. Help: Can Query be dispayed before running in obectpal

3. Updating RTF Document in nText column

4. Q: E/SQL SUN application size > 600K. strategies for smaller apps?

5. Concatenation of ntext column in UPDATE Statement

6. Limit query / SP, CPU usage

7. Update in a text, ntext column

8. BDE and table locks

9. puzzling issue with inserted, updated and IF UPDATE(column) in an update trigger

10. Complex search for ranges of values in non-atomized NTEXT column

11. Inserting into a NTEXT column

12. SQL ntext column using ADO

13. Reading unicode chars from an ntext column : how to