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