Plucky Posted February 5, 2019 Posted February 5, 2019 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 Posted February 5, 2019 Posted February 5, 2019 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 Posted February 6, 2019 Author Posted February 6, 2019 Hi Comment Thanks for this. Ive now added the extra elements and its all working well.
Plucky Posted February 6, 2019 Author Posted February 6, 2019 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 Posted February 6, 2019 Posted February 6, 2019 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).
Dr.Gopala krishnam raju AMBATI Posted February 6, 2019 Posted February 6, 2019 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
Dr.Gopala krishnam raju AMBATI Posted February 6, 2019 Posted February 6, 2019 (edited) 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 Posted February 6, 2019 Posted February 6, 2019 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 Posted February 6, 2019 Posted February 6, 2019 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 Posted February 7, 2019 Posted February 7, 2019 (edited) OK Edited February 7, 2019 by Dr.Gopala krishnam raju AMBATI
Recommended Posts
This topic is 2172 days old. Please don't post here. Open a new topic instead.
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now