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

[John Esak]

> 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
>

Yesterday, I felt that DECLARE'd (i.e., long variables) should act like 2
character variables in all regards... (i.e., *have* the multiple copies used
by the break/gt areas). I am changing my mind today... (the difference
between me and Kerry by the way, is I won't change it back again
tomorrow.... :-)  I agree with Nancy's logic. Since the variables themselves
can not be put on a report, using regular 2 character variables for this
need is good enough.  Also, it was most frustrating to me when I found that
a value I had set into a long variable in the data area was not there when I
got to the subtotal area. (this is because of a bug in filePro right now...
and this discussion will hopefully fix that bug...)  So, I think the long
variables should perform without expecting them to carry break values....
wherever they are declared.

I do, though, and this is _very_ important, feel that there should be NO
need to declare a long variable on an automatic table just to get it to pass
globally among tables. In other words, we MUST never lose the ability to do
this on a -v table:

          if: date ne ""
        then: goto sel
          if:
        then: declare date(8,mdy/,g)
          if:
        then: input popup date "Draw this report for what date? "
          if: @sk eq "BRKY"
        then: exit
          if: date eq ""
        then: goto askD
   sel    if: 2 eq date
        then: select
          if:
        then: end


I use this kind of process hundreds of time a day/month/year... It is seldom
that I rely on AUTOMATIC tables for anything these days... mostly legacy...
now that the above is possible... AND I can show that variable 'date' on the
report format by stuffing it into a 2 character global variable there.

So, as long as this doesn't go away... I'm for not having the long variables
carry the multiple copies.

John Esak