XML Import

[Plucky]

Hi

Im looking at importing xml sheets into a database that gets generated by a digital platemaking machine after each cast is run. I would like the FM import to generate a new record for every Name element but each record must contain the Job and Plate element information as this stays the same for each cast run.

Is it possible to use these xml sheets as they are or would they need changing.

also does anyone one have a example I can look at to understand how it needs to be set up to import into FM

RUN71-60X50-155DLC-PRIORITY16.xml RUN73-80X50-155FSC-PRIORITY17.xml RUN75-80X50-125FSC-PRIORITY18.xml RUN76-80X50-125FSC-PRIORITY18.xml XML.fmp12

[comment]

1 hour ago, Plucky said:

Is it possible to use these xml sheets as they are or would they need changing.

It's a bit of both, actually. You can use them as they are, but you need to transform them into Filemaker's XML grammar. This is done during the import by applying a custom XSLT stylesheet to the XML.

I have written a skeleton stylesheet that imports the first 3  fields from each area of the XML. It shouldn't be too difficult to add more to it. Note that the order of the FIELDs defined in the METADATA section must match the order of COLs defined in the RESULTSET. 

names_import.xsl.zip

[Plucky]

Hi Comment

Thanks for this. Ive now added the extra elements and its all working well.

 

[Plucky]

Hi Comment

I'm probably asking to much now but Is it possible to import the xml elements and have FM split between two tables.

Table one (XML) would have the Job and Plate fields and the second table (Portal) would be a portal and contain the Name fields.

 

XML.fmp12 names_import.xsl

[comment]

it's possible - even desirable, in terms of data structure - but you will need to import twice: once into the parent Jobs/Plates table, and once into the child Names table.

The stylesheet you have can be used to import into the child table. You can remove all the "common" fields, except for JobName ( or some other unique identifier that will serve to link the names to the job/plate). Or you can simply not import them.

The stylesheet for importing into the parent table will have only the common fields - and you need to remove these two lines: 

<xsl:for-each select="Images/Name">

</xsl:for-each>

so that only one record is created in the parent table (I am assuming that the XML will always contain one Job/Plate and several Names).

 

[Plucky]

I will give it a go. 

[Dr.Gopala krishnam raju AMBATI]

3 hours ago, comment said:

it's possible - even desirable, in terms of data structure - but you will need to import twice: once into the parent Jobs/Plates table, and once into the child Names table.

The stylesheet you have can be used to import into the child table. You can remove all the "common" fields, except for JobName ( or some other unique identifier that will serve to link the names to the job/plate). Or you can simply not import them.

The stylesheet for importing into the parent table will have only the common fields - and you need to remove these two lines: 

<xsl:for-each select="Images/Name">

</xsl:for-each>

so that only one record is created in the parent table (I am assuming that the XML will always contain one Job/Plate and several Names).

 

I HAVE .XSD FILE can u make stylesheet plz

drugbank.xsd

[comment]

That would be work.

[Dr.Gopala krishnam raju AMBATI]

8 minutes ago, comment said:

That would be work.

yes i agree and when i see ur replies regarding various calculations since yrs i think it wouldnt be considered as work as i dont know xml i thought u will help me  

Edited February 6, 2019 by Dr.Gopala krishnam raju AMBATI

[Josh Ormond]

It's one thing to ask for help learning or understanding something, in this example XML and stylesheets. That is a big piece of why the forum exists to help people learn.

It is an entirely different thing, and somewhat inappropriate, to ask someone "build this for me". It's not what we are here for. If you wish to hire someone to do it for you, then have that discussion back-channel...and expect to be billed market rate.

[comment]

It's not only work - it's a lot of work. If you decide to undertake it, I suggest you consider carefully what exactly you want to import, to where. The document describes a complex database, with many tables. A drug can have many products. A drug can have many manufacturers. A drug can have many general-references and  each general-reference can be an article, a textbook or a link. A drug can have many reactions and each reaction can have many enzymes. There are many more such entities - and each of these entities would require its own table and a separate stylesheet to import records into it.

[Dr.Gopala krishnam raju AMBATI]

OK

Edited February 7, 2019 by Dr.Gopala krishnam raju AMBATI

[comment]

Please read what Joshua Ormond said.