Anyone notice that simply referencing (not assigning values to) a field name in an empty datasource stack changes FocCount from 0 to 1? For example, if I have a datasource stack, stkABC and my code does the following:

stack clear stkABC;
reposition datasource1.SEGNAME.KEY_FIELD;
for all next KEY_FIELD into stkABC where KEY_FIELD eq "some value";

Let's say this returned 0 records so stkABC is still empty and FocCount should still be zero.

Then I do this:

Compute Var1 = stkABC().KEY_FIELD;

I guess Var1 would be assigned NULL or "" or something. Not sure since if I do a:
Type "Var1 = " Var1; in my code it just prints:

Var =

Anyway, after this I want to check the FocCount of stkABC in an IF statement to either do something or not, for example:

if stkABC.FocCount eq 0 then
form1.Button1.enabled = 0;
else
form1.Button1.enabled = 1;

Problem is this IF statement will evaluate as false because after the Compute statement that referenced stkABC().KEY_FIELD, stkABC.FocCount now equals 1 not 0, even though I know that stkABC is actually empty (or is it actually not?).

I know I can work around this by checking to see if stkABC.FocCount is 0, and if it is, not executing any code that even just references stkABC or stkABC() or stkABC(row number) if I want to intentionally keep stkABC.FocCount at 0 when stkABC is empty.

The dynamic behavior of stacks in the Maintain language is really helpful but it would nice if the manuals made it clear that just referencing an empty stack or field in an empty datasource stack either changes just the FocCount of that stack from 0 to 1 or actually creates a row in that stack and changes FocCount. It would have saved me a few hours of debugging.

I guess I would think that unless an empty stack is referenced on the left side of an assignment statement, the stack should remain empty and the FocCount of that stack should remain at 0. If it's referenced on the right side of an assignment statement, that should not affect the stack in any way.

Just curious on other peoples' thoughts on this.

I think I must have got used to this behaviour now. I remember hitting this issue years ago and having the same sort of thoughts as you.

My understanding, which could be wrong, is that this is to do with FocIndex rather than FocCount. As you know FocIndex can never be zero or less. By referencing a stack, FocIndex cannot be zero, so defaults to 1, ergo the stack has a FocCount of 1. I cannot remember now, but I think FocCount will always keep track of FocIndex if FocIndex goes above FocCount.

I think your solution of checking FocCount before running code sounds the most sensible, though I have a feeling I also check the value of a key field, which cannot be blank, in the stack(1).

Now I tend to run fexes to collect data, if the data collection could return zero records, and only use Next when it is a certainty that data will be retrieved.

I am not sure about the documentation (it's a while since I read it!), but I always cover this in training courses. So perhaps it should be covered better to bring in the element of least surprise.

Gentlemen
I can explain the reaon for this, but I agree that the behavior is not great. The reason is, whenever you reference a value or row in a stack, that row or value will automatically exist. So the line:
Compute Var1 = stkABC().KEY_FIELD;
Creates a row 1 in stkABC and gives KEY_FIELD either blank or 0 depending on its format and stkABC.FOCCOUNT goes to 1. The problems I have seen are with this scenario:

For all next Moviecode into stk
Where category eq 'XXX';
Compute Stk.NewField/a10;

After the Next statement, stk.foccount = 0 since there are no records that match this WHERE clause. However, when we compute the NewField into the stack, we not only add the column to the stack, but a row as well with all blank or 0 values. So, Stk.foccount = 1.

This issue has been in programming for a while, but there has been no good solution. To get around it, I find myself using:

If stk(1).moviecode ne '' then ...

Mark