long variable error... a fix needed for 5.5.

[Nancy Palmquist]

> | So, this becomes a decision as to whether to treat long variables as the
> | kind that _have_ mutliple (up to 10) copies, like 2-character variables.  Or
> | treat them as if they were defined on the automatic table with only one
> | copy.  The rub is, of course, that they can be defined on the automatic
> | table as "globaL"... not (,g) but "global" so how should they work in that
> | instance, and others even more complicated... defined on CALLS, etc.

I understand that DECLARE GLOBAL means the value will travel between 
tables - not unlike the variables defined in the automatic table.

But the (,,g) in the definition indicates the value travels between 
records.  A way to collect data across records.

In every sense, the values collected at a break point in a report are 
(,,g) global and collect across records.  This allows the user to put 
=xx on a report and get a sum of values for xx.

Since it is not possible to use DECLARED variables in this way, I prefer 
the value to behave as one value, like the automatic type variables.  If 
I set a value to a declared variable and then try to print it at various 
break points I want the declared value to be what I set it to in the 
first place.  That makes sense and is what I would expect.

That is my input on this.
Nancy


> | 
> | My personal feeling is that they should be _exactly_ like 2 character
> | variables with the multiple copies so you could do what Nancy (and all of us
> | need to do a hundred times a day....
> 

I am not sure I expect them to provide subtotal levels.  John and I 
discussed this but since I am unable to directly print them on a report 
and would have to assign them to dummy's it would be just as easy to let 
the dummys collect the values.

I never use dummys this way, hardly ever use =xx on a report - except in 
the simpliest situation.  My preferred method is an array with my logic 
adding values to the appropriate elements.  If I map the array to dummys 
, I just display them with *xx to get my values.

I find this works better for me.  The internal logic used by filePro is 
always messing up my reports in one way or another so I learned a long 
time ago to manage it manually.  I can control it much better that way.

I can't remember ever using the tot(), or similar functions which make 
use of that data.  I don't say it is broken but it never reported what I 
expected.  I guess my brain worked differently.  I know the rules and 
can tell them to others, but I have found that some people use them very 
successfully and others can never make them work.  I am in the latter 
group when it comes to these functions.



Nancy
-- 
Nancy Palmquist
Virtual Software Systems
PHONE: (412) 835-9417			Web site:  http://www.vss3.com