This project has moved and is read-only. For the latest updates, please go here.

Getting started



The provider is the entity that generated the specific XML document being processed.


The repository is the database the shredded XML data will be stored in. It can either be created manually before the first run, or by the application's first run. The repository may also need to be upgraded from an older version, and the app will also do that as needed, or can generate a script to do that.
For more info on how to get a database creation or upgrade script, see the console help page.


The source is the database the raw XML is stored in. When setting up XML to Table, you'll need to specify a source connection and source object. The source object can be a table, a view, or a query (or the name of a file that contains one of those). If the source object is a query, it cannot contain a common-table expression. You can also specify a source timeout.

The table, view, or query must return these columns:
  • DocumentID - The unique ID for the XML document. Must be non-null and be convertible to a 32-bit integer.
  • ProviderName - Must be a non-null string.
  • GenerationDate - The date the document was created. Can be null.
  • XML - the full text of the XML document.
  • SubjectID - the ID of the entity that this XML document concerns (e.g., the Customer ID)


XML to Table supports two different kinds of models, hierarchical and key-value.


When building a hierarchical model, XML to Table will create tables to correspond to the XML elements being processed. It can relate these tables with foreign keys, or through a set of ParentID and ParentTable columns. The names of tables and columns can be enforced to be a certain length.


When building a key-value model, XML to Table will insert unique XPaths into a "Variables" table, and values into a "DocumentVariables" table that links back to the DocumentID and the VariableID.


XML to Table can be run by specifying all of the parameters in a config file, or by specifying all the parameters on the command line. A config file setup allows you to run XML to Table over and over again without having to create a cumbersome batch script, while a command-line run allows you to quickly shred some XML without a lengthy setup.

If your configuration file contains passwords or other sensitive data, be sure to protect the file before deploying it. A handy script to do this is provided in the source (it takes the full path of the config file and the section to encrypt as arguments).

For detail on how to set up a config file, please view the Example.config.
For details on how to set up the command-line, please view the console help page.

For further info, please see Questions you might ask.

Last edited Oct 30, 2015 at 9:10 PM by nateirvin, version 14