Just one point - where you say hard code - I am not entirely in agreement - my xml handling code is generic for all the xml file i suck into u2, the EXT file is different for each xml file - it is in a way an addendum to the xsd and allows you to only import parts of the xml. If this is what you call hardcoding then i disagree it is a configuration. If however you are hardcoding your databasic for each xml file then yes that is hardcoding and i agree you should not do it that way !
Symeon. -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Tony G Sent: 29 July 2009 22:02 To: [email protected] Subject: Re: [U2] the XML/DB Tool > From: Coelho, Gregory > I am on UniData (7.1 and 7.2) attempting to create a set of > nested relationships in a XML file. In an attempt to learn > how to use the XML/DB Tool I've read through IBM's > UniData:UniBasic Extensions - but am now more confused that > at the onset. Can anyone direct me to a knowledge source for help? I'll piggy-back on Greg's request. I don't know if this is at all what Greg is trying to do but I'll take a chance and see if anything I'm doing can help with what he's doing. I've recently obtained a large and completex dataset which is composed of hundreds of megabytes of XML, defined by a set of XSD documents. Transforming the XSD into strongly-typed .NET classes is easy. Reading the XML into strongly-typed objects is easy. The next step is mapping these objects to MV files. Having done this sort of thing a number of times before, I'm firmly of the opinion that one should not, for example, import XML data for Customers and push that data directly to a CUSTOMERS file. Rather, I believe the data should be stored in one or more files, like CUSTOMERS.XML.PRIMARY, CUSTOMERS.XML.ADDRESSES, CUSTOMERS.XML.CODES, etc, and from there business rules should be run to properly integrate this data with the live application files. This ETL layer helps to ensure that live data isn't corrupted by a data dump, and it also helps to allow for changes in both the XML and the application without having to link the two directly. It's an MVC pattern which works well in a wide variety of applications. I have been brainstorming for quite a while now to find the best way to link middle-tier code to the back-end as defined above. I do not like the idea of hardcoding XML handling into the MV environment, so unless strongly compelled, personally I tend to avoid the U2 XML tools entirely. But I'm open for suggestions. Right now I use C# partial classes to represent the XSD schema, and am planning to create new partial classes to augment these with SaveToDBMS functionality, looping on class objects to run rules and process the data into MV files. I'd like to automate the generation of the files that are updated (like CUSTOMERS.XML.ADDRESSES above) or write a code generator that will use schema or code (via reflection) to create code to do this same function for any set of XML/XSD. Assuming I've explained the above properly - has anyone done this? Anyone interested in the outcome? Any suggestions? Is this a case where the U2 XML capabilities may present some value? I'll be happy to clarify where required. Thanks! Tony Gravagno Nebula Research and Development TG@ remove.pleaseNebula-RnD.com Nebula R&D sells mv.NET and other Pick/MultiValue products worldwide, and provides related development services remove.pleaseNebula-RnD.com/blog Visit PickWiki.com! Contribute! _______________________________________________ U2-Users mailing list [email protected] http://listserver.u2ug.org/mailman/listinfo/u2-users _______________________________________________ U2-Users mailing list [email protected] http://listserver.u2ug.org/mailman/listinfo/u2-users
