PRODATASET and XML format

This works for the dynamic case because READ-XML is inferring the ProDataSet schema from the data, and creates a dynamic dataset "NewDataset" with one member table "fontie".  This is currently not supported for a static ProDataSet.  READ-XML is expecting the root node to be .  We are currently planning on enhancing READ-XML in Release 11 to handle this type of XML format for static ProDataSets. Of, course, the actual release is subject to change.

This works for the dynamic case because READ-XML is inferring the ProDataSet schema from the data, and creates a dynamic dataset "NewDataset" with one member table "fontie".  This is currently not supported for a static ProDataSet.  READ-XML is expecting the root node to be .  We are currently planning on enhancing READ-XML in Release 11 to handle this type of XML format for static ProDataSets. Of, course, the actual release is subject to change.

So the solution would be to READ-XML into a dynamics PDS and then COPY-DATASET to the static one? Or BIND a static definition of the table to the dynamically created table. The latter would avoid to deep-copy the data row by row.

Hi, for a single table you don´t need a ProDataSet. You can import the XML strait away.

Look at the example below.

DEFINE VARIABLE cXML AS LONGCHAR   NO-UNDO.

ASSIGN cXML = '1TestStreet'">http://www.w3.org/2001/XMLSchema-instance">1TestStreet'.

DEFINE TEMP-TABLE fontie NO-UNDO
  FIELD numinttie AS INTEGER
  FIELD name AS CHARACTER
  FIELD adress AS CHARACTER.

TEMP-TABLE fontie:READ-XML("LONGCHAR",cXML,"empty",?,?,?).

FOR EACH fontie:
    DISP fontie.
END.

You should use a Prodataset for 2 or more tables, It doens´t mean that you can´t use a Prodataset for a single table, you can, but is not necessary.

Like this example:

DEFINE VARIABLE cXML AS LONGCHAR   NO-UNDO.

ASSIGN cXML = '1Name1Street12Name2Street2'">http://www.w3.org/2001/XMLSchema-instance">1Name1Street12Name2Street2'.

DEFINE TEMP-TABLE fontie1 NO-UNDO
  FIELD numinttie1 AS INTEGER
  FIELD name1 AS CHARACTER
  FIELD adress1 AS CHARACTER.

DEFINE TEMP-TABLE fontie2 NO-UNDO
  FIELD numinttie2 AS INTEGER
  FIELD name2 AS CHARACTER
  FIELD adress2 AS CHARACTER.

DEFINE DATASET dsTest FOR fontie1, fontie2.

DATASET dsTest:READ-XML("LONGCHAR",cXML,"EMPTY",?,?,?).

FOR EACH fontie1:
    DISP fontie1.
END.

FOR EACH fontie2:
    DISP fontie2.
END.

Marcos

Unfortunately,

I also tried with a dynamic temp-table and I've got this :

Unable to infer TEMP-Table or dataset schema from xml data.

So I think that a static temp-table will not work too.

When I export an temp-table to XML i've got this XML

instead of :

Regards,

I think you're right but there is also a cost for this operation.

Copying dataset content to another will spend a lot of time.

I'm going to keep dynamic solution for now.

Thank you.

rpigeyre schrieb:
I think you're right but there is also a cost for this operation.
Copying dataset content to another will spend a lot of time.

Depending on the size that's right.

I'm going to keep dynamic solution for now.

Never, as long as there's a static solution! Here's the code with the BIND. The only thing you need to be aware of, is that the field data-types need to match. So your field numinttie needs to be CHARACTER (it will also be CHARACTER in the dynamic code).

DEFINE TEMP-TABLE fontie NO-UNDO REFERENCE-ONLY 
  FIELD numinttie AS CHARACTER 
  FIELD name AS CHARACTER
  FIELD adress AS CHARACTER.
DEFINE VARIABLE hPDS AS HANDLE      NO-UNDO.
DEFINE VARIABLE hTable AS HANDLE      NO-UNDO.
CREATE DATASET hPDS.
hPDS:READ-XML ("FILE", "sample.xml", "EMPTY", ?, ?).
ASSIGN hTable = hPDS::fontie:TABLE-HANDLE  . 
RUN bindTempTable (TABLE-HANDLE hTable BIND) .
FIND FIRST fontie.
MESSAGE fontie.numinttie  
        fontie.NAME
        fontie.adress
    VIEW-AS ALERT-BOX INFO BUTTONS OK.
PROCEDURE bindTempTable:
    DEFINE INPUT PARAMETER TABLE FOR fontie BIND . 
    /* NOOP */
END PROCEDURE. 

The benefit of this code, is that there is only a single point of failure when the incoming XML doc changes and that's the RUN bindTempTable call - this will ensure that the schema of the dyn TT and the static reference-only definition match.

BIND was added in 10.0B or something like that.

Ok thank you!

I'm going to try it with the BIND method.

I think there is something being overlooked here, although Antonio and Robin have both pointed to it.  It seems to me that the source of your problem is that there is only one table worth of data in your XML but, by putting a temp-table inside a dataset, you are creating another level of container.  Think about it .. if you had two tables worth of data in your XML, then you would have some wrapper tag which enclosed both in order to make it a single structure.  That's the dataset.  The dynamic code is clever enough to figure out that there is only one level and so it works, but the static case you are telling it that you expect another level and it isn't there.  Thus, read-xml into the TT by itself works, because there is no additional level indicated.  And, I'll bet that reading into a static PDS would work too if you would add an appropriately named set of wrapper tags around all the data to indicate the PDS.  So, just use a TT not in a PDS unless there is some good reason to need a PDS or, if you control the source of the XML, add a set of wrapper tags around all of the data.