Hi All,
Progress 10.1b on Windows environment.
I'm new to using the clob data type and am having a problem saving XML passed down into my program as a MEMPTR.
To recreate problem I have created the following code.
DEFINE VARIABLE vmTempXML AS MEMPTR NO-UNDO.
DEFINE VARIABLE vmTempXML2 AS MEMPTR NO-UNDO.
DEFINE VARIABLE vmXML-in AS MEMPTR NO-UNDO.
DEFINE VARIABLE vmXML-out AS MEMPTR NO-UNDO.
DEFINE VARIABLE xml-in AS character NO-UNDO.
DEFINE VARIABLE startPos AS INTEGER NO-UNDO.
def temp-table tt-db no-undo
field dbfield as clob.
/* following creates XML and saves to MEMPTR */
XML-in = "<?xml version='1.0' encoding='UTF-8'?><HiAffinity>".
SET-SIZE(vmTempXML) = 0.
SET-SIZE(vmTempXML) = GET-SIZE(vmXML-in) + 1.
put-bytes(vmTempXML,1) = vmXML-in.
SET-SIZE(vmXML-in) = 0.
SET-SIZE(vmXML-in) = GET-SIZE(vmTempXML) + LENGTH(xml-in) + 1.
put-bytes(vmXML-in,1) = vmTempXML.
put-string(vmXML-in,startPos + 1) = xml-in.
startPos = startPos + LENGTH(xml-in).
create tt-db.
copy-lob vmXML-in to tt-db.dbfield.
When run I get the error "Invalid character code found in data for ISO8859-15 (12008)"
I read some postings which said to remove the extra character when setting the size, but this has not helped. Any help would be greatly appreciated.
Regards
Harj
Hi,
Why don't you use a LONGCHAR variable to build the XML doc in. That way you don't have to use a memptr and you don't have to deal with the SET-SIZE. Besides that a LONGCHAR has it's own code page so that should make it easier. You may also consider to use the SAX-WRITER to create the XML doc in the first place, instead of manually creating a concatenated string.
HTH,
Wouter.
Hi Wouter,
Thanks very much for your reply, its greatly appreciated. The reason for
using MEMPTR is because I'm utlising existing code and bolting this new
feature to it. Our system passes and retrieves XML's in memptrs so that
what I have had to use.
I have eventually got to the bottom of the problem by using CLOBS and
making sure server and client are started using code-page UTF-8. In this
way we seem to have no problems. I am happy to send code to anyone who
wishes to see how it works.
Regards
Harj
Harjinder Mankoo | DST Global Solutions Billing | Senior Analyst
Programmer | +44 (0)208 390 5000
Wouter Dupre
30/11/2009 09:06
Please respond to
progresscommunities
To
Harjinder Mankoo
cc
Subject
New message: "Saving XML in the database as a clob"
Harjinder Mankoo,
A new message was posted in the thread "Saving XML in the database as a
clob":
http://communities.progress.com/pcom/message/75281#75281
Author : Wouter Dupre
Profile : http://communities.progress.com/pcom/people/wdupre
Message:
Harj,
The reason for
using MEMPTR is because I'm utlising existing code and bolting this new
feature to it. Our system passes and retrieves XML's in memptrs so that
what I have had to use.
Take a look at the COPY-LOB statement: it allows you to copy the contents of a MEMPTR to a LONGCHAR and back again. That way you could work with string (in the LONGCHAR) and copy it to a MEMPTR for external purposes.
-- peter
Hi Peter,
Thanks for your reply. I did use copy-lob but for things to run smoothly
it was expedient to have both the server and client started with same
codepage ie UTF-8. If theye were different then go into all sorts of
problems with codepage conversion.
Anyway all is OK now.
Harj
http://www.dstglobalsolutions.com
*****************************************************************************
From May 18th 2009:
DST International Limited will be known as DST Global Solutions Limited.
DST International Output Limited will be known as DST Output Limited.
Please update your address book with the new email address and visit our new websites:
http://www.dstglobalsolutions.com and http://www.dstoutput.co.uk
=============================================================
Notice: This e-mail and any attachments are intended only for the individual or company to which it is addressed and may contain information which is privileged, confidential and prohibited from disclosure or unauthorized use under applicable law. If you are not the intended recipient of this e-mail, you are hereby notified that any use, dissemination or copying of this e-mail or the information contained in this e-mail is strictly prohibited by the sender.
Whilst we run anti-virus software on all internet e-mails we are not liable for any loss or damage. The recipient is advised to run their own anti-virus software.
If you have received this transmission in error, please return the material received to the sender and delete all copies from your system. Thank you.
DST Global Solutions Limited is a company registered in England and Wales with company number 1772349.
DST Global Solutions Group Services Limited is a company registered in England and Wales with company number 5211646.
DST Global Solutions Billing Limited is a company registered in England and Wales with company number 4370287.
DST Output Limited is a company registered in England and Wales with company number 4220397.
Pensions and Actuarial Services Limited is a company registered in England and Wales with company number 2957435.
The registered office for all the above mentioned companies is: DST House, St Mark's Hill, Surbiton, Surrey, KT6 4QD, England.