Jump to content
Sign in to follow this  
Plucky

XML Import

Recommended Posts

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

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites

Hi Comment

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

 

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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).

 

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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 by Dr.Gopala krishnam raju AMBATI

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this  

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.