I’m looking for whatever procedures brought forward from v6, which may still work with Pan X. I’ve found the DB file suffix used back in v6, and have replaced all instances of it for the current .pandb. Yet, in running one of these procedures, I get the alert:
Using the same search which rooted up all the v6 file names, nothing turns up. The procedure in question itself is clean for such a reference. I’m about to go into “The power of Christ compels you!” mode.
It even persists after 1.) using the Relational Workshop to write the lookup, and 2.) making a copy of the needed target DB, renaming it as the ghost, and then going thru the Workshop.
I’m pretty sure you cannot just add ‘.pandb’ and expect it to work…if I recall correctly, you must save the database in Pan 6 with the ‘.pan’ extension, then open Pan X and then open the Pan6 database when Pan X is running.
That’s true, but that’s not how I tried the work-around for this situation. The file whose name was changed (to the Ghost’s) was already a working PanX file. The file suffix didn’t need changing. Thanks for reminding me of this detail.
Was that renamed file open when you attempted the lookup? The error message is saying that it isn’t.
That’s because the file doesn’t exist. But it’s the only file which a lookup( will look up. Using the 100%-kosher/hallal Workshop with the desired target file designated and opened, the lookup substitutes this ghost file. And this also happens with a from-scratch, constructor-made, brand new data-entry form.
There is so many tiny details that doesn’t work as the help file says they should in Pan 10.2, I’m thinking of retreating to 10.1.
I can assure you that there is no such thing as a “ghost” lookup. There is a lookup in your code that is doing this. You know which procedure has the error, so you need to go thru it line-by-line to find where the problem occurs. The name “WBPS Customers 3.1” might not be in the code itself, it could be in a variable or a field. Perhaps even a permanent variable, in which case no code search would ever find it if the original statement that created the variable is not around.
And there is no “WBPS Customers.3.1” to be found in any of the procedures (25 in the invoice file, or 39 in the CUS file — both their original and current working files saved in PanX), nor in any of their fields. This checks out. I also don’t think I’ve ever used a permanent variable.
The ghost-haunting, created by the Relational Workshop and placed in the Procedure sub-panel
«Cus ID» = lookup(“WBPS Customers.pandb”,«L Name»,«Name»,«Cus ID»), happens when, back in data mode, you tab through it (the 2d field tabbed though — the 1st being «Name», required for the lookup).
The lookup( itself should work just as well in the Formula sub-panel, but it won’t let me enter anything there. And currently, something is also blocking me from entering in the «Name» field, even though these two sub-panels are empty, as they should be for something reserved for manual entry.
I’m grateful for your help, Jim, when the big thing on your plate is native code for 10.2 on an M1 chip.
The Relational Workshop would never create that formula. The database name does not include the .pandb extension, this should be:
lookup(“WBPS Customers", ...
Let us know if that fixes the problem. I can’t imagine how that could cause an error message with a suffix of .3.1 to occur, but let me know. Hmm, I just tried a lookup( with the incorrect .pandb suffix on the file name and it displayed the correct error message:
So I still think that you have something somewhere with the text “WBPS Customers.3.1” - you just haven’t found it yet.
In Panorama code you almost NEVER use the .pan or .pandb suffix. The only exception would be if you are dealing with the file as a file, not as a database, for example with the fileload( function (though that function won’t work on Panorama X databases anyway, since they are packages). When referring to a database name, especially an open database, you only use the name, not the suffix. (This also means that code doesn’t have to change from Panorama 6 to Panorama X, since the suffix isn’t part of the code.)
Bill could grab my Variable View file from the Panorama Database Exchange and view all his variables and check their current values for the mysterious text.
. . . but don’t copy that literally because the opening and closing quotes don’t match.
I did find a “…3.1”, but it was “Accounts Receivable3.1”, not exactly an exact match. But that was it. Once changed to an existing file name, the procedure got the OK stamp.
Found it! THANKS, Gary. But not in VariableView but in DesignSheet (your fabulous gift to all of us who miss this). I’ve already made the correction inside an obscure formula, and will check out the repair tomorrow. (I was supposed to be upstairs 30 minutes ago.)
Again muchos thanquos to all for their suggestion.
The target database is now scrubbed of “WBPS Customers.3.1” references in the procedure “field” of two data fields, and the lookup(- now goes through. Except somewhere deep inside the database, something didn’t get the memo. Now the above alert appears, and I have to do a “return/tab” to move on through the entries. But I’ll let that pass.
Does your database have a .ModifyRecord procedure.
You might find the new diagnostic tool described here helpful in tracking down this problem.
