I know it’s bad practice to have field names beginning with a numeric but this isn’t my code.
It appears that Panorama 6 procedures will happily compile a field name like 24AB but Panorama X wants chevrons around it. Is this correct?
I don’t know why you think Panorama 6 allowed this, but it doesn’t. I just ran a test and you definitely needed chevrons around a field name that started with a number. Perhaps there is some weird case where this wasn’t necessary, but in general, the chevrons are required.
Strange - I’m working on the Panorama X file that David Schranck sent me (see Postponing using PanX) and the procedures that wouldn’t compile all had this problem. I don’t have access to his original Panorama 6 database so I can’t confirm what was in it but he assures us that it’s been running for ages like that.
I’ve asked David to send me his Panorama 6 database and I can then report on what’s happened.
I couldn’t help but cringe when I read the above comment. In the mid 1990’s, I entered the responses to a survey into a Panorama database where the fields were named for the survey question number: “5”, “14” or “37”, etc. Using Pan for data entry was much easier than the statistical program I was going to use later to analyze the Pan exported data. After entering about 350 surveys, I thought I would sort and summarize a few fields that I was particularly interested in before exporting the data to the stat program. Well, the result was a mess, it was just incomprehensible. I think I called the Provue support line to set me straight.
Beginning the field names to a non-numeric character solved the immediate problem. For example, “5” became “Q5” and “37” became “Q37”.
Of course, the longer term problem was I couldn’t remember what question Q37 asked. Naming my fields after the content stored in them made much more sense. Thus, “Q5” became “Gender”, “Q14” became “CountyReside”, and “Q37” became “WheelchairModel”. Lesson learned.
The answer to why David’s Panorama 6 procedures without chevrons around a field name that started with a number were OK is that they contained this sort of structure:
if max(2DC,3DC) > AVE and max(5DC,10DC) < AVE
do something
endif
… and so the procedures all compiled. Of course, the really bad news is that max(2DC,3DC returns the value 3 without regard to the values in the fields. I’ve advised David of this and I await his response. The good news is that I’ve fixed all of these problems in the Panorama X version and it should run as intended. Hopefully, that will compensate a little.
Tom,
I have a text-analysis database I’ve been using for decades and it has 20 fields named 1 to 20. The trick is to put the field names in chevrons.
So the real answer is that these procedures were not ok, and the fact that these procedures compiled without error in Panorama 6 was a bug in Panorama 6 in the fact that Panorama was ignoring a bug in David’s code – yes, the procedure compiled without an error, but the procedures did not work correctly!
Panorama X correctly flags that this is an error. So Panorama X has just helped David find a bug (multiple bugs?) in his code that it sounds like have been lurking there for a long time. (I have just verified this behavior in both Panorama 6 and X).
I would hesitate to call it a Panorama 6 bug - Panorama 6 just didn’t go as far as Panorama X does in analysing the content of a procedure.
Another topic we’ve beaten to death.
Sure it’s a bug. Panorama 6 is just silently ignoring part of the code in a procedure (the alphabetic part of the field name), and then giving the wrong answer. That is a serious bug in my book.