Importing/exporting data with carriage returns (I Think)

[Richard D. Williams]

This tip from Mark will not work;

Why not just translate the \r to \001 before import, and then whenever
outputting or otherwise referencing the data on the way out, translate \001
to \r?

If you replace one \r with a \001, you replace all. Therefore the row 
terminator is still not unique.

There is a PHP Class that will read column values directly from an xls file.

https://stackoverflow.com/questions/13439411/from-xlsx-sheet-rows-to-and-php-array

But, as Mike is not a programmer, this may not be a solution for him to 
pursue.

Richard D. Williams

On 8/28/2017 6:27 PM, Brian K. White via Filepro-list wrote:
> On 8/28/2017 3:16 PM, Fairlight via Filepro-list wrote:
>> They call it -logic-. ...
>
> I don't see that Mike did anything wrong deserving of these responses.
>
> He's not a programmer and lacked the background to make sense of your 
> initial answer. That is not illegal. Once you establish that, just 
> switch into that mode.
>
>
> Mike, this kind of thing can be addressed several possible ways, and 
> Mark's first answer was really just meant as a general description or 
> basic outline of one possible approach, not any kind of exact commands 
> or details. No one could offer any exact details yet at that point 
> because we didn't yet know enough details about your situation. First 
> comes picking a possible approach, then comes hashing out what exact 
> details are required to make that happen.
>
> That idea might not have been practical for you for some reason, or 
> might be doable but might not be the most convenient option available. 
> It was too early at that point to do more than essentially spitball 
> some different basic possible approaches.
>
> For instance:
>
> * If there are CR's or LF's or both within the cells, then how ARE the 
> records delimited, if not by CR? Maybe you don't need to do anything 
> but adjust the record delimiter option on the import command line in 
> processing. That would be much better than cobbling together some 
> external pre-processing steps.
>
> * Or, you could do your own more manual parsing of the data by using 
> open and readline instead of import. Then you could detect incomplete 
> records and read in the next line, and concatenate to the previously 
> read line, repeat until you know you have read in a complete record 
> (by counting the commas that weren't inside any quotes or something). 
> This would not be convenient to write at all, but it's one and only 
> advantage is, it would be done entirely in filepro processing and 
> doesn't depend on any external programs or batch files, and once it's 
> done, it's done. It'll then 'just work" forever.
>
> * Or, if you control the export, then maybe you could alter the export 
> to make it possible for fp to import it reliably. (again, even this 
> one idea, has many possible meanings. Impossible to guess them before 
> even knowing the first thing: "if you control the export". Only IF 
> that is true, the next question would be, what program are you 
> exporting from? maybe that program has some option to specify the 
> record delimiter, or if not, maybe you can add another column to the 
> data that you could then look for in processing to detect the real end 
> of the record. Or maybe you could export in a fixed-length format, and 
> then the filepro import wouldn't even look at any LF or CR at all. 
> They would just be bytes like any other bytes.)
>
> * Or maybe pre-processing the data is the most practical way to go 
> after all.
>