Crash on post or lookup procedure

This code works perfectly, once.

nm=«First Name»+«Last Nameame, nm, Comments, "")+ "|IMAT S17|"
post "updateaddall", "New Panx Alex Mail","FullName",Name,"Address",Address,"City",City,"State",State,"Zip",Zip,"Country",Country,"HomePhone",HomePhone,"email",email,"Comments",wksh````

The second or third time I run it, PanX either crashes, or hangs with an infinite beachball. I wondered whether there was a problem because for one record the variable nm and the fields FullName and Name contained a space, but skipping that record had no positive effect. I restarted PanX several times, and also restarted the computer, but that didn't help.

I tried stepping through the procedure, but after the second line the stepping bounces back to the top of the procedure.

FWIW I'm still running OSX 10.11.6

Because a second database is involved, I suspect the local variable is the culprit.

Local variables are local to the procedure, not the database. A procedure can visit as many databases as it likes, and its local variables will remain in scope.

Parts of the procedure appear to be missing. It looks like nm is being assigned the result of a lookup(, but the first part of that lookup( function is missing. The Post command is apparently posting the contents of wksh, but wksh has never been assigned a value.

Sorry, I was deleting obsolete parts of the procedure and accidentally deleted current ones too. Here’s the current but still faulty version:

local nm,wksh
nm=«First Name»+«Last Name»
wksh=lookup("New Panx Alex Mail", FullName, nm, Comments, "")+ "|IMAT S17|"
post "updateaddall", "New Panx Alex Mail","FullName",Name,"Address",Address,"City",City,"State",State,"Zip",Zip,"Country",Country,"HomePhone",HomePhone,"email",email,"Comments",wksh

nm is defined from the calling DB and when I step through it shows as correctly assigned.

I’ll stress that the first (and sometimes the second) time this procedure runs it exhibits no problems. After that, it doesn’t just fail, it crashes or hangs Panorama.

I rewrote the procedure using superlookup, thus substituting a formula for the local variable nm. Again it worked fine for the first 2 records, hung up when I got to the name “John Paul Shields”. I force quit, restarted PanX, it worked fine for the first 2 records; I skipped Shields and went on to Victoria Dreher and again PanX crashed.

Remembering that I had some problems with superlookup before, I checked back in BitBucket and found issue #488; but I don’t think that’s a comparable situation. There I was trying to fill up a TDO with the results of a superlookup, but here I’m just trying to assign a value to a variable.

Are we treating this as an acknowledged bug? Jim, would it help to have copies of the files?

Yes, if there is to be any chance of tracking this down I would definitely need the files. Are there any form windows involved? Especially with Text List or Matrix objects? I have a suspicion they could be involved. If so, there’s a good chance that the problem is already fixed. You might try to run this procedure with only data sheet windows open and see if it works ok then.


By the way, it may not matter but by using a lookup( followed by a post this code will be searching for the name twice. If “New Panx Alex Mail” is large then this will take double time. I think this would be a case where it would be better to forget about the post statement, which after all is just a custom statement, and roll your own. Then you wouldn’t need the lookup.

local nm,odb
odb = info("database") // original database, needed for fieldvalue( function
nm = «First Name»+«Last Name»
setactivedatabase "New Panx Alex Mail"  // open secret window
pleaseselectall
find FullName=nm
if info("found")=false()
    addrecord
endif
Address = fieldvalue(odb,"Address")
City = fieldvalue(odb,"City")
Zip = fieldvalue(odb,"Zip")
Country = fieldvalue(odb,"Country")
HomePhone = fieldvalue(odb,"HomePhone")
email = fieldvalue(odb,"email")
Comments = Comments + "|IMAT S17|"
setactivedatabase ""  // close secret window

BTW, if my suspicion about forms is correct, this code may still crash when you run it multiple times in a row fairly quickly.