It may not be a bug... but it is awful...
GCC Consulting
gccconsulting at comcast.net
Sat Apr 14 09:03:40 PDT 2007
Top post:
John,
The same thing happens if you create a new index to be use in a browse
lookup.
You can at least assign the index value even if it doesn't exists. It will
complain at run time.
However, it would be nice if, when F6 in the wizard is pressed, it would
reread the available indexes.
Of course, there may have been a performance issue if cabe had to read the
indexes at this point over using what had been cached somewhere in memory.
Richard Kreiss
GCC Consulting
> -----Original Message-----
> From:
> filepro-list-bounces+gccconsulting=comcast.net at lists.celestial
> .com
> [mailto:filepro-list-bounces+gccconsulting=comcast.net at lists.c
> elestial.com] On Behalf Of John Esak
> Sent: Friday, April 13, 2007 11:01 AM
> To: Filepro-List at Lists. Celestial. Com
> Cc: Support at Fptech. Com
> Subject: It may not be a bug... but it is awful...
>
>
> 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
>
>
>
> _______________________________________________
> Filepro-list mailing list
> Filepro-list at lists.celestial.com
> http://mailman.celestial.com/mailman/listinfo/filepro-list
>
More information about the Filepro-list
mailing list