X-SQLT Command-line Processor (xsqlt.exe)

As a command-line processor of X-SQLT language you can use xsqlt.exe utility. It implements all language specifications and allows you to perform specified tasks by using generally available technologies like ADO DB, MSXML and Windows Script Host, and by supporting common data formats (XML, CSV and JSON) and transformations (XSLT, XPath, VBScript, JScript, PascalScript, etc).

xsqlt.exe is easy to use, fast and resource friendly utility, that can be incorporated into any automation process, or used as a standalone tool for frequent tasks, like:


To execute your X-SQLT project, simply pass its filename as a command-line parameter of this utility, or double-click the project in your Windows environment (if you have associated ".xsqlt" file extension with xsqlt.exe utility).

    
  xsqlt.exe C:\MyProject.xsqlt
  

Moreover, this utility does not require you to create X-SQLT project file to perform your tasks (although it is a basic mode of usage). It has implemented intelligent parser of command-line arguments, that allows you to pass (as parameters) essential options only. For example, to transform XML file with XSL template, you can execute this utility as follows:

    
  xsqlt.exe "C:\books.xml" "C:\books.xslt" "D:\books.htm"  
    

You can read more about xsqlt.exe usage in Command-line parameters topic.


Remarks

Please, keep in mind, that simple "xml" conversion uses SAX technology to read or write xml data, so it is very fast and resource efficient even for huge source data files or for huge database results written into xml destination files. This also applies to conversions from XML to CSV or JSON format.
On the other hand, "xslt" and "xpath" transformations use DOM technology, so they require a lot more of memory and more time to make the job.

For now, only oledb database sources are supported. Native connections to database engines are planned in the future. That's why the following sub-nodes of source element are ignored (so far): server, database, username, password and role.

For now, binary data fields from databases are stored (and read) in binary form (into XML and JSON formats). In the future, there could be an option to read and write binary data encoded (eg in MIME Base 64 encoding).

For now, JSON is supported only as a target (destination) format. Also the conversion from XML format into JSON does not support record-tag attribute yet - the conversion is made 1:1 (you can make a chain of XPath and XML to JSON transformations to produce filtered JSON result from XML source).