I'm in way over my head doing some XML stuff. I've got an XML file that I need to load. It's structure is:
INVOICE
CLAIM
CLAIM
CLAIM
A few of the CLAIM children(?) have a line like this:
<claim errorCode="CX" number="12345678">
I need to walk through the XML document and pull out the records that have an errorCode element(?), grab all the lines from that claim and store them in an array.
Anybody have a nice VB6 project that opens an XML file and traverses it pulling out the children or elements or attributes whatever they are called?
Reading XML in VB6 in general is quite a common question. The code in your case doesn't sound difficult to write at all with Line Input, Split, and InStr, though I'm not quite sure what you mean by "grab all the lines from that claim and store them in an array".
The time you enjoy wasting is not wasted time. Bertrand Russell
The MSXML libraries come in several versions. Version 6.0 is current and usually version 3.0 is available as a fallback for downlevel systems (Windows XP without an update to MSXML 6.0 or Windows before XP). Everything else is pretty much obsolete.
The versions vary in terms of bug fixes, security fixes, performance levels, and adherence to current standards. MSXML 6.0 for example supports XSD as well as DTD (if you turn on DTD support), while MSXML 3.0 does not (it supports DTD only).
With MSXML libraries you have two choices: SAX or DOM.
Most of what you'll find posted here is DOM-based processing, probably because it is simpler to get started with even though it can add tremendous memory and CPU overhead (and code complexity) fast. SAX is much faster because it focuses on parsing and doesn't have to construct a towering object hierarchy out of each XML document - basically leaving that to you.
SAX is a better choice if your XML documents are huge, or if you need to create some other data structure besides an XML DOM.
If you don't use MSXML there are still two other options: 3rd party XML processing components or hand-rolled code. While at first you might think coding a few parsing loops is no big deal, but XML can be trickier than it seems at first glance.
The example I have attached uses MSXML 3.0 SAX parsing. The sample document is an old Microsoft sample, and uses a DTD to define "types" and their structure and the values' defaults, etc.
For example an <invoice> might have an <address> element which has a company attribute. But not every instance of <address> will have an explicit company, so the DTD defines this as optional with a default value of empty (""). An <address> might also have a type attribute with values like home, work, business, or other... with a default of other if not specified.
Your DTD (or XSD) takes care of these definition details. Often they are separate documents referenced via directives in each XML data document, but here an embedded DTD is used. The SAX parser can also parse without a document definition but you get slightly different results (delete those lines from file.xml and see).
The example code just parses the XML and produces a structured dump in a TextBox. It could just as easily filter for certain values and do something else with the data.
Last edited by dilettante; Feb 4th, 2011 at 10:49 PM.
This means that MSXML cannot find the file specified. As posted, the example will look in the current directory for file.xml so something may have "moved" it from this perspective?
I compiled the sample on Vista SP2 and tried it there as well as on XP SP3 and Windows 7. No problems.
What if you pass App.Path & "\file.xml" as the argument to ParseDumpXML?
CurDir$() and App.Path can have different values, particularly if you start VB6 first then open the project from the IDE's File menu.
Last edited by dilettante; Feb 5th, 2011 at 12:16 PM.
I'm very familiar with the use of the DOM object but have never used SAX. Based on the XML document posted in the sample, can you show me how you would get the patients firstname and familyname for invoice number=27?
I think you're looking at it the wrong way. SAX is a parser, not a DOM, so it is most useful for performing a one-pass transformation of an XML document into another format. A good example might be for importing XML data into a database, or updating a database when the XML document represents changes. It isn't intended for things like making ad-hoc queries against the same document.
So a more useful question might be one like that in the original post: "How can I get an array containing the patient's firstname and familyname for each invoice?"
This one reworks the previous example so that it extracts the the number and patient firstname and familyname from each invoice into a two-dimensional array with one row per invoice. Then it displays the array in a grid control.
This kind of thing can be much more efficient in both time and memory than creating a great big DOM hierarchy. But if you need most of the data from the XML file or you cannot predict what parts you need you might be better off using a DOM as long as the XML documents are small.
Until the document gets to the 20KB and up range the DOM overhead doesn't matter much, especially in a desktop program where only one user is asking for service at a time. You see the SAX approach more often in high volume applications.
Re: Post #6
Dilettante, you're right, it was the file.
Changed the Form_Load code to App.Path & "\file.xml"
and all was well.
I'm glad that was it.
Web searches showed that almost nobody interprets this error correctly even though it happens a lot in MSXML applications. Most discussions trail off with random suggestions about reinstalling the program or updates to it... then go silent.
Probably once the problem is found and fixed nobody ever posts back with the solution.
You get this funny error because MSXML uses UrlMon.dll to load files, since the the files can be local or on an HTTP or even FTP server.
Reply With Quote
Originally Posted by VBClassicRocks
