What you probably should do, though, is to write a few lines of code to scan
through the file prior to import, and tidy up all sick CRs, LFs, EOFs,
Commas, etc.

Then, you can dream even more... happily... IN that bar...

<g>

- Mike

Stay tuned until tomorrow. Dinner's on fire. I'll need some further info
tomorrow, Mike.


"Michael Kennedy" <Info (AT) KennedySoftware (DOT) ie> wrote

JoeSpareBedroom wrote:

It is almost certain that the line-termination character sequence (usually
CR/LF) is not present in this file.

Any sort of hexadecimal file-editor will probably show you the problem.

You might find that simply loading the file into an editor, and saving it
again as a text file, will solve the problem.

But ... "what changed?" Did someone alter the tool that generates that
file?

----
ChimneySweep(R): Fast(!) table repair at a click of the mouse!
http://www.sundialservices.com

"Sundial Services" <info (AT) sundialservices (DOT) com> wrote


I usually ask the vendors "what changed". Usually, someone retired and the
next person is doing things differently. Telling them there's room for
improvement is like telling the owner of a Hummer that their vehicle is
dumb.

"Michael Kennedy" <Info (AT) KennedySoftware (DOT) ie> wrote


OK....so I do what? Import the text file into one big field in a table, and
search for the sick/missing characters using their ASCII codes?

JoeSpareBedroom wrote:

No, the largest ALPHA field size in Paradox is 255 bytes. But you have
a good idea. There are many ways to attack your problem. Here's one.
If there are no CR/LF pairs throughout the file and the length of each
"record" is a fixed number of bytes, then you could write ObjectPAL code
using TextStream to to read x number of bytes and then write x number of
bytes plus the CR/LF characters to an output file, looping until you are
finished. Perhaps there is some software out there that will parse a
long record into many short ones.

"Ed Nash" <ask.me (AT) specifically (DOT) pls> wrote


PdoxWin was evicted from here long ago, but I see an idea for doing this
with PdoxDOS. Record length of these files is never more than 100-150 chars.
Import into a table, and just use a series of SUBSTR steps to pick out the
various fields out of the long line of text.

Ed has covered the overall approach already, except, if you use only
PDoxDOS, then you'll need to write some PAL-EDITOR code to read in the file,
clean it up, and write out the updated stuff.

Personally, I usually write a few lines of C, BASIC, etc, to do the above. I
don't like the EDITOR stuff in PAL.

Irrespective of language/tool used, the overall logic might be something
like:
- Open the input file. None, abort...
- Open the output file - overwriting any old one...
- Identify the exact size of the input file (Say SZ)
- Clear an "input" buffer, and note that it now contains "0" bytes (IN =
0)

- If the buffer is empty (IN=0), and SZ is 0, then we've processed all
possible input data, so close-down and exit.
- If the buffer is empty (or nearly-empty - see below), then read another
buffer-full, or just SZ bytes (if SZ is less than a bufferful). Reduce SZ by
what's read.
- Scan the buffer, doing the tidy-up... perhaps: identify all CRs, and
replace them (in-place) with LFs. Then scan for all LFs, and replace any
"string" of them by a single CR/LF pair. Do some "comma", quote,
double-quote, etc, clean-up also - as per your special needs... Remove any
EOF chars...
- Write the cleaned buffer...

A sneaky bit is that the tail of a buffer-ful might have a CR char, and the
head of the next buffer might have it's matching LF char. So, a solution to
that issue is to not process the last few hundred bytes of the buffer, but
to move them to the head, and fill up the rest of the buffer with fresh data
from the file... until there are no more bytes in the input file. Then,
obviously, run the clean-up on the entire buffer tail.

Hope that nonsense makes some... er... sense...

I have loads of code around here to perform the above functions -
more-or-less - but it would probably need to be tweaked for your special
needs. I guess, if you're familiar with PAL-EDITOR code, then it might be
best to use that approach...

- Mike