Dummy variables
Kenneth Brody
kenbrody at bestweb.net
Fri Oct 17 12:09:59 PDT 2008
Quoting Steve Wiltsie (Fri, 17 Oct 2008 13:44:25 -0500):
> Thanks for the quick reply. I have inserted my responses after each of your
> suggestions below.
As they should be. :-)
> ----- Original Message -----
> From: "Jose Lerebours" <fp at fpgroups.com>
> To: "Steve Wiltsie" <swiltsie at micro-mui.com>
[...]
>> I wonder if you are running checks in batch or individually. If
>> individually, is it possible that you are running different processing
>> tables given some conditions and this is causing the problem?
>
> They are all run at the same time - in batch.
So, you run a single *report process, which goes through the file, prints
the report/form for each selected record, and everything prints correctly,
except for this one record, which prints "*aa" rather than the contents of
field aa?
[...]
>> One other thing I have noticed is that if you have something like **aa
>> will cause the variable to print not the value. Additionally, are the
>> checks form same for all employees?
>
> I agree, but this doesn't have the extra *. Yes, the same processing table
> and form for all employees.
What makes you feel that "**aa" would be a problem? It's simply field aa
with an "*" in front of it.
>> A quick fix may be to terminate employee on file and create a new record.
>> Not sure that a corrupted record would cause such behavior.
>
> I was thinking about that - or a bad spot on the hard drive.
Any possibility that field aa contains the value "*aa" for this record?
Add this to the end of the output processing (or just before the PRINT
that prints the record):
If: @RN = "the bad record number"
Then: mesgbox "On the 'bad record', aa is '" & aa & "'"
--
KenBrody at BestWeb dot net spamtrap: <g8ymh8uf001 at sneakemail.com>
http://www.hvcomputer.com
http://www.fileProPlus.com
More information about the Filepro-list
mailing list