Importing/exporting data with carriage returns (I Think)
Robert Helbing
bobhelbing at airtro.com
Tue Aug 29 09:29:48 PDT 2017
I also came across the problem of purging linefeeds and carriage returns
from incoming data. I found it frustrating that neither "instr()" nor
"xlate()" could find or replace the pesky intruders.
I ended up scripting this character-by-character search for them instead.
It seemed to do the trick.
29 ------- - - - - - - - - - - - - - - - -
cleands ■ If: ' look for linefeed characters
(ASCII=10) ■
Then: sp =
chr("10") ■
30 ------- - - - - - - - - - - - - - - - -
■
If: ■
Then: gosub
filtstr ■
31 ------- - - - - - - - - - - - - - - - -
■ If: ' look for carriage return characters
(ASCII=13) ■
Then: sp =
chr("13") ■
32 ------- - - - - - - - - - - - - - - - -
■
If: ■
Then: gosub
filtstr ■
33 ------- - - - - - - - - - - - - - - - -
■
If: ■
Then:
return ■
34 ------- - - - - - - - - - - - - - - - -
filtstr■
If: ■
Then: ps =
"1" ■
35 ------- - - - - - - - - - - - - - - - -
test_ds■ If: mid(ds,ps,"1") = sp and ps eq
"1" ■
Then: ds = mid(ds,(ps +
"1"),dlen(ds)) ■
36 ------- - - - - - - - - - - - - - - - -
■ If: mid(ds,ps,"1") = sp and ps gt
"1" ■
Then: ds = mid(ds,"1",(ps - "1")) & mid(ds,(ps +
"1"),dlen(ds)) ■
37 ------- - - - - - - - - - - - - - - - -
■
If: ■
Then: ps = ps +
"1" ■
38 ------- - - - - - - - - - - - - - - -
-
■ If: ps gt
dlen(ds) ■
Then:
return ■
39 ------- - - - - - - - - - - - - - - - -
■
If: ■
Then: goto
test_ds ■
On Mon, Aug 28, 2017 at 4:27 PM, Brian K. White via Filepro-list <
filepro-list at lists.celestial.com> 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.
>
> --
> bkw
> _______________________________________________
> Filepro-list mailing list
> Filepro-list at lists.celestial.com
> Subscribe/Unsubscribe/Subscription Changes
> http://mailman.celestial.com/mailman/listinfo/filepro-list
>
--
*Robert HelbingPresident(626) 357-5315 x14*
*www.airtro.com <http://www.airtro.com>*
<http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
Virus-free.
www.avg.com
<http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.celestial.com/pipermail/filepro-list/attachments/20170829/abd00abf/attachment.html>
More information about the Filepro-list
mailing list