Why?
George Simon
george at worldest.com
Thu Jul 1 09:17:33 PDT 2004
I said:
"To clarify the previous post a little bit, the error occurs ONLY from
*report when using the normal automatic table and calling the "getlong"
table from automatic processing. If I remove the line calling the "getlong"
table from automatic processing and call it from the output processing table
(compare) running *report, I DO NOT get the error. If I call the table from
@once, I DO NOT get the error. If I cut down the automatic table to only
the dummy field definitions needed to run the report, I DO NOT get the
error."
In any case, you do not feel this is a filePro bug but something in my code
that is causing the problem. And as such, it is very unlikely that whatever
that may be, will be fixed by running it with 05.0.13 (by the way, it also
fails with 05.0.11) so I rather wait for 05.0.14 or whatever version
includes the printing of memo fields to upgrade my almost-perfect 05.0.09
version. That feature might be worth the risk of breaking working code.
8-)
George Simon (IT Department)
American River Logistics, LTD
614 Progress St.
Elizabeth, NJ 07205
Phone:(908)354-7746 Fax:(908)354-7491
mailto:george at worldest.com
http://www.americanriverintl.com/
-----Original Message-----
From: Kenneth Brody [mailto:kenbrody at bestweb.net]
Sent: Thursday, July 01, 2004 11:23 AM
To: George Simon
Cc: George Simon; filePro mailing list
Subject: Re: Why?
George Simon wrote:
>
> Ken, if I call the table from the output processing table, hasn't the
> automatic processing table already executed all its code before the output
> processing even begins?
I thought you said @ONCE? But, yes, if you call it from the actual output
processing, then automatic has been executed by then. However, you have
still changed the sequence of events leading up the the execution of the
statement that is causing the crash in the original situation.
> And if so, why is it that whatever line is causing the error to occur when
> the table is called from automatic, does not have any effect when the
table
> is called from the output processing table?
Because by changing processing, you have changed what's in memory where,
and you have changed the sequence of events. Without having the files to
duplicate it with, there is no way for me to answer the question with any
more detail. For all I know, line 87 of automatic processing causes some
memory to be corrupted, but line 963 causes something else to happen that
makes that corruption irrelevent.
> The only difference I see is that one line (the one that calls the table)
is
> remarked out from the automatic table.
> I just don't understand, I guess.
[...]
--
+-------------------------+--------------------+----------------------------
-+
| Kenneth J. Brody | www.hvcomputer.com |
|
| kenbrody at spamcop.net | www.fptech.com | #include <std_disclaimer.h>
|
+-------------------------+--------------------+----------------------------
-+
More information about the Filepro-list
mailing list