It may not be a bug... but it is awful...

[John Esak]

Well, it was one of those long, really long frantic nights when I've been
trying to finish up the last bits of a new release of the SS Accounting.
Today, I promised to send out Version 1.1.0, skipping over the earlier
promised 1.0.2. this version has all the typos, small additions, fixes,
etc., that turned up in the 1.0.1 version, plus one really nice enhancement
to the G/L istself.

Anyway, as usual, I left one of the things I thought would be easiest to do
until last.  Way last... but still there was plenty of time. Sure... did you
ever read Richard Kreiss's thing about how we put things off? :-)


To the point. this hassle took me more than two hours of my time and an hour
of Tony Ryder's time trying to figure out. Then after a 30 minute rest, I
realized the problem just by accident. Here is what this is about in a
nutshell.  I made a huge improvement to the Accounting system in how it
"closes" the G/L year and stores the data in a qualifier so you can get
reports for previous years and periods.  This new method is infinitely
easier and is essentially a one button thing rather than the several steps
that were necessary in the 1.0.1 version. To do this, I am standing inside
clerk on record one of a control file. I run a routine that copies the
current year to a qualifier. It does it all creates the key, data, indexes.
Then it posts a few things to that new qualifier to ensure that years don't
get closed twice and so on. The simple lookup to this new qualifier kept
failing with the following notice:

*** A filePro error has occurred.***



Press H to hardcopy, Press Enter to continue



Yup, that is it... that's all of it... and there ain't no more. I worked for
2 hours on the problem doing everything I know how to do to debug such a
thing. (And two hours of debugging is like 77 hours in filePro dog years!)
God, I was so frustrated. Anyway, Tony was in the FP room reasonable for him
because he's in Australia, not too reasonable for me because I'm here and it
is 4am in the morning, my deadline rushing closer and closer.

The damn thing just kept being *so* strange. It would pass the lookup but
not let me assign any value to any field in the lookup file. I mean the "not
lookup" line was false and everything just wouldn't work. I could not assign
any field... any value... yet I could see all the fields in the debugger.  I
was doing the lookup to record #1... the alias(@rn) showed a "1". All the
field on the lookup record had their correct t values... I just couldn't
post anything into them. Simply putting one of the lookup fields on the left
side of an equals sign blew me out to the error and form there back to the
command line from where I came.

I was counting the hours until I could call filePro support... or better
minds than my own. Tony was still working on the problem, when I finally
gave up.

I tried to sleep but just stared at the ceiling for a long time. Then it hit
me all of a sudden.... I don't know if you caught it but I mention that this
routine copies the current data to a new qualifier. I, of course, properly
create that new qualifier, and make sure I close the file and do everything
according to Hoyle.... but I am standing in the control file and the new
qualifier has been made for this file I'm standing in also. It is *this*
qualifier that will not let me write to it. (I know, because in my hours of
debugging I've tried lookups to the other new qualified files and they all
work!  Just the qualifier for the same file I'm standing in.  The clue
finally fell on my head when I thought, hey maybe filePro reads the
"available" or "existing" qualifiers when it goes into clerk (like it does
indexes) and those are the only ones you can post to??  Turns out this is
it.... thought I still don't understand why because with indexes there is a
set number of them... easy to read into memory space.... how in the hell can
filePro want to read all the existing qualifiers in the current file as it
loads... what if there are thousands of them. I'm assuming that the number
of qualifiers is only limited by disk space. It would be like trying to read
all the available filePro files when clerk loads. This obviously isn't done.
When you do a lookup to any file, at that point in the runtime process if
the file isn't there you get an error. But not so with qualifiers
apparently. If a qualifier for the current file does NOT exist when you load
clerk, it can not be looked up to... well, that's the hell of it... it can
be looked up to and you can get any of the data from the record you want...
but you can't post data to any of the fields in the looked up file.  I did a
tiny test program to prove this out.

  1  -------   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -
       . If:
       Then: end
  2  -------   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -
@keyT  . If: 'keyT
       Then:
  3  -------   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -
       . If:
       Then: ff="test@" { "newqual"
  4  -------   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -
       . If:
       Then: lookup xxx= (ff) r=("1") -p
  5  -------   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -
       . If:
       Then: xxx(1)="hello"
  6  -------   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -   -
       . If:
       Then: end

Run this code and go to record 1. Just sit there, do NOT press "T".  Then in
an alternate login go and physically create the "newqual" qualifier for that
same file you are standing in (test in this case).  In Unix this is a simple
matter of creating the key manually and then change its ownership to
filePro. (whatever applies in Windows do the same thing.) Then go into this
new qualifier with clerk and add some data to this new qualifier on record
1. Then leave the file... and go back to where you are sitting on the
original file/qualifier above. Press the "T" and you will see the beautiful
error message letting you know there was a problem... but not giving you any
clue as to what the problem is. It will crash at line 5. Put a "debug on"
there and test the values of the lookup... they are all there and
avaialble... you just can't assign values to any of the lookup fields.

I know you are all going to think this is so obvious and why did it take
John so long to figure this out... but believe me if I hadn't laid it all
out here, I'm sure it would have caused a lot of head scratching for the
best of you. :-) Only because you can see xxx(@4n) and xxx(1) and so on...
you *know* you've done a successful lookup. You can *see* this, it just
doesn't WORK! (a not so minor difficutly :-))

Like I say, I can understand gathering various critical things when you load
clerk like indexes, but if your clerk "creates" a new qualifier in some part
of your process and then you want to later post to that qualifier in the
same process... you are out of luck.

I know FP Tech (or hopefully Ken on this forum) will have the right
explanation or should I say the correct explanation for what I am just
trying to intuit here... but it is my feeling that this should be allowed.
What if it is the first time you are deleting a record, perhaps... and there
is no "del" qualifier yet... so your process makes one... and then you try
and copy the record to it before you delete it... I doubt whether this would
work, then again it might. I haven't tried it, but judging by the above
code, it won't.  Even so, I can't think up any other scenarios right now...
I'm too tired. :-)  But my specific need should be enough... it is a
legitimate process... a reasonable thing to think should work. I'm hoping
Ken doesn't say there is some reason why this behavior can't be changed.

I did a workaround, but it is kludgy and I hate workarounds.

So anyway, a caveat for an obscure thing that might happen to you should you
be pushing on various limits.  My question after all of this is, why is this
a limitation... I don't think it should be.  I think it is a bug, or
probalby an oversight the desingers maybe thinking this situation would
never happen.

Thanks for your support.

Bartles & James