On 2016-08-20 06:09, Wollenhaupt, Christof wrote:
Sounds like Christof's ExcelXML class. Recall that I can't use VFP data storage due to > 255 columns.
My class uses the first Excel XML format; the VFPX class uses the current XML format. The old format has the advantage of easily being creatable with text merge, since it's a plain text file. The XLSX Format is a ZIP file with a more complex XML format that requires a library to create files.
Personally, I'm mostly using a commercial product named GemBox these days with Rick Strahl's wwDotNetBridge to call it from VFP.
The CSV tip worked great...now I've got a DIFFERENT type of input source that is again a SDF flat (position-dependent) file, but the trick this time is that the record type flag is a single byte in position X. Depending on X, you have to choose the appropriate SDF layout definition. (Seriously, it's 2016...why the hell are they still outputting text files like this from what's probably a mainframe?!?!???) Same record type is a lot easier, but now that there are multiple layouts and I have to conditionally branch, it's not as easy. The output should be an Excel file with a separate tab for each record type. My current plan is to create the 3 CSVs (as there are 3 layouts per file, record types 1, 2, and 3) and then use Excel automation or Christof's ExcelXML to create the file. I'm leaning towards the former, as it's a given that Excel is on the machine here, and I'm thinking it'll be an easy macro to record and replicate in Excel automation code.
Files are by Provider Number, which is the first 6 characters in each record. I keep a cursor of Provider numbers, the Low Level File Function handle value for each, and then set the FWRITE handle accordingly based on the lookup. So with this changing record type (up to 3), I'll keep a file handle for each Provider and Record Type, output accordingly, and then Excel automation to marry them into one file for that ProviderNumber.
Any thoughts on this twist---would you do it a different way?