IMPORT/CLOSE issues?

[Kenneth Brody]

Quoting Fairlight (Mon, 10 Apr 2006 20:58:32 -0400):

> Found a weird problem with a client's code today.  They're going through
> multiple records with selection sets and importing data into records in
> another table.  The filename is in common here, but it's kind of
> irrelevant.
[...]
> getline::import ascii ref=(FILENAME) r=\n f=\n:
> :not ref:return:
> ::aa(400,*)=ref(1):
> ::return:

You do realize that once the import hits EOF, "aa" will continue to
hold the value of the last line imported?  Also, your main loop did
not check for EOF.  (At least not in the code listed.)  Could this
be the cause of your infinite loop?

[...]
> My solution given deduction #2 was to add a "CLOSE ref" at the
> appropriate spot after writing the new record and before the end, and
> pray that it would notice the alias was not attached to anything any
> longer.  We did that, and things did indeed work correctly henceforth.
>
> Now -my- question (having already determined what the problem was and
> having fixed it) is this:
>
> 1) Why does IMPORT not re-execute -every- time it is called?

It does.  Each time you hit the IMPORT line, the next "record" (if
any) is imported.  Just as each time you hit an EXPORT, a new export
record is started.

> 2) Why does IMPORT at least not re-execute if the data source has
> changed since its last invocation on the same alias?

Once open, IMPORT/EXPORT will continue using the filename specified
at the time it was opened.  In order to force a new filename, you
need to close it.

> 3) Has it -always- worked this way?  Is this even the intended
> behaviour?

By "behavior", I assume you mean my statement above about needing
to close the import/export in order to change filenames?  Yes, this
has always been the behavior, since variable filenames were first
allowed.

If you meant something else, please elaborate.

> Prior to seeing this code, I believed you had to step
> through a file with different subscripts to get each successive line.

Subscripts are for each field within the record, not for different
records within the file.

> I had no idea you could re-import and just keep pulling line 1 time
> after time and have it be the next successive line in the file.

It's not "line 1", it's "field 1".  Each time you execute the import,
the next record (in this case, a line in a text file) is read, giving
you a new "field 1" (and "field 2", and "field 3", and so on).

> Intentional or bug?

Intentional.  How else could it work?

> My own $0.02:  This is totally unconventional behaviour as regards file
> I/O in pretty much any language,

Huh?  What other method of sequential I/O exists in these other
languages of which you speak?

> gives you no sane way to detect EOF

You use "NOT importname", exactly as you have done.

> unless there's something in the file you know will be the last item you
> need to look for (there thankfully is in this case), and is entirely
> contrary to what one would expect from the code as written.

Given that your code uses "not ref" to detect EOF, I don't understand
your problem here.

[...]
> Point is, IMPORT is definitely behaving in a way I would never have
> anticipated.

Other than the "you need to close it in order to switch to a different
filename", what part is "unanticipated"?

> The fix is logical given the behaviour exhibited--but the
> behaviour exhibited is something I'd never have thought would work.

Why not?

[...]

--
KenBrody at BestWeb dot net        spamtrap: <g8ymh8uf001 at sneakemail.com>
http://www.hvcomputer.com
http://www.fileProPlus.com