Malcolm,
As I understand it that is what is being done behind the scenes
already with the NOCPTRAN option. The whole memo is converted to a
base64binary representation which lets us avoid some ugly translation
code ( ASCII(26) is just one of the many characters that cause the
XMLTOCURSOR to blow up). And it all works for me now lacking a smooth
transition from VFP Cursor to SQL Server Table and back.
Thanks,
Mike
----- Original Message -----
From: "profox" <profox .AT. bdurham DOT com>
Subject: Re: XMLToCursor ??
> Mike,
>
> On the toXML side, why not convert chars outside the range legal
> range of
> chars to something like &###; (like HMTL does) and on the XMLto
> side,
> convert your &###; patterns back to binary chars.
>
> The ### would be the ASCII numeric code, i.e. in your case, chr(26)
> would
> be converted to &026;
>
> Just an idea ...
>
> Malcolm
>
> ----- Original message -----
> From: "Mike McCann" <mcsoft@cox.net>
> Subject: Re: XMLToCursor ??
>
> lctest = "this is a string"+CHR(26)+;
> "this is more string"+CHR(13)+CHR(10)
>
> *** add NOCPTRANS to create a binary Memo field
> CREATE CURSOR c1 (f1 M NOCPTRANS)
>
> APPEND BLANK
> REPLACE f1 WITH lcTest
> CURSORTOXML('c1','lcXML',3,2+4+8,0,"1")
> XMLTOCURSOR(lcXML,"c2",4)
>
> Does the trick. My success was limited because in the wider case, I
> have found no way for SQL Server to store and retrieve my Binary
> Memo
> field.
>
> Thanks,
>
> Mike
>
> ----- Original Message -----
> Subject: XMLToCursor ??
>
>
>> Why does CURSORTOXML create an XML that XMLTOCURSOR can't extract
>> (or am I missing a setting)??
>>
>> lctest = "this is a string"+CHR(26)+"this is more
>> string"+CHR(13)+CHR(10)
>> CREATE CURSOR c1 (f1 M)
>> APPEND BLANK
>> REPLACE f1 WITH lcTest
>> CURSORTOXML('c1','lcXML',3,2+4+8,0,"1")
>> XMLTOCURSOR(lcXML,"c2",4)
©2004 Mike McCann |
