Field or variable does not exist


#1

This happens intermittently in Pan X when I try to perform this simple operation, and I can’t find a pattern to it.

I have a button that causes a prompt for an Account number so the user can go to a particular record if he knows the Account number. The code basically does this:

GetText AccountNumber
convert to numeric value
Find Acct = AccountNumber

It’s been working flawlessly for years in Pan 6, and usually works in Pan X. When it doesn’t, the response to entering a value and pressing OK is:

Field or variable "textValue" does not exist

I have no field or variable by that name, and it is not mentioned anywhere in my code. This must be an internal process that is failing for some reason, but I have found no way to overcome it except to restart.


#2

Yes, the textValue variable is a local variable used by the GETTEXT procedure itself. I have no clue as to why it is losing scope for you when gettext is run as a statement.


#3

I had a similar issue that drove me nuts trying to resolve, but it turned out to be brought on by an error in the variables I had set up for the GetText. So by sharing “basically” what yours does may not be sufficient. What variables are leading up to the GetText, especially the one used for the input text?


#4

I knew I’d be brought to task for my sweeping statement :grin: This is the code that my procedure runs:

local  Acct, AcctNo
Acct=str(«Acct.#»)
GetText "Account number:", Acct
AcctNo=val(Acct)
...

followed by a Find to locate the record, but it doesn’t get that far. The «Acct.#» field holds the account number for the current record, just to seed the GetText statement. The GetText prompt always looks just like it should, but entering a new value and pressing OK produces the error, if there is going to be one. This never failed in 6, and usually doesn’t fail in X, but it’s getting worse somehow. I guess I lied when I said restarting makes it work again; yesterday I must have restarted Pan a dozen times but couldn’t get past it. Today after two cold reboots it still does this.


#5

Out of curiosity, what happens if you replace the gettext statement with a gettextokcancel statement?


#6

Another clue, maybe. I put a debug statement here:

local  Acct, AcctNo
debug
Acct=str(«Acct.#»)
GetText "Account number:", Acct
AcctNo=val(Acct)

and it works correctly. I comment out the debug statement and it fails again. Over and over, it works exactly this way. Funny, the presence of the debug statement doesn’t actually cause the debug activity to happen, just lets the procedure work. I have often found that debug mode can make a procedure act differently, but this is even stranger.

Gary, I just saw your question before I finished this. Similar effect, but now with debug commented out I get a possibly revealing error: ‘field or variable “Acct” does not exist’ (immediately after declaring it and giving it a value). But sometimes it works regardless of debug or not. Does gettextokcancel handle things differently?


#7

There is no custom statement procedure for this command so I would assume it is hard coded. I therefore have no idea of how it is handled internally.


#8

Here is the only pattern I can find so far, but it is (so far) completely reliable.

If I have a debug statement where I showed it above, it works properly if the procedure window is open*

If I comment out the debug statement, it won’t work whether the procedure window is open or not.

If the procedure window is not open, it won’t work regardless of the status of debug.

*in this case, focus never goes to the procedure , as would be expected in debug, but it performs correctly.

When I say “won’t work”, I mean I get the ‘field or variable “Acct” does not exist’ error (using gettextokcancel) in the procedure. Using simple “gettext” gets me the ‘Field or variable “textValue” does not exist’ dialog error under the same conditions.

Having the debug statement in there, and the procedure window open, seems to be the only way to make it work. Voodoo.


#9

With a numeric field named Acct.#, your procedure works for me. I’ll hazard to guess that this snippet, all by itself, will work for you too. I’m going by my own drawn out experience with the same error. I suspect something else is wrong before it gets to this.


#10

I often suspect this. Reducing my code to just that snippet gets the same crazy results for me. Often in my development, after executing all sorts of code with varying results, things don’t seem to work right any more. Usually that is resolved by starting Pan over, but this problem hasn’t responded to that method. It seems like somehow the Pan environment changes in the process of doing various things, and code doesn’t perform as expected. Seems like that, don’t know the actual process. The inability of others to duplicate it makes it a lot harder to solve.

To lend further credence to this, I just tried coming at this a little differently. The database that contains all of this is the main file among about 9 that are opened using this file’s .Initialize procedure. In all of my testing the last couple of days I have always had it begin “normally” by letting it open all these files first. I just tried it by opening just the data sheet first, then the form that uses this, so that .initialize didn’t run, and whaddaya know, it executes normally, even with the procedure window closed, debug or not. So it would seem that somewhere my environment is being polluted (technical term). Just for grins, within this successful environment I ran .Initialize to see what would happen, and it ran through to the end and crashed Panorama, which is also not unusual. I need a weekend…


#11

I think I have discovered a reliable pattern to this, having experienced the same problem in other databases and other procedures, that use GetText the same way. The pattern I described above is not quite accurate, this seems to be it:

If the procedure window is open, and is the frontmost window, it executes correctly. How does it get to be the frontmost window, when clicking on the form automatically makes it the frontmost window? By putting debug in the procedure, which magically moves it to the front when the execution hits that point. Peculiarly, even though it’s in debug mode, it does not pause to wait for a Step or Run click, it executes right through the procedure(correctly). I am putting my debug statement after the local variable declaration, before any executing code.


#12

This is still happening, even on new procedures. The pattern seems the same as I described above. I am completely up to date on Pan X as of today. Tell me what to do next, this has to be solved.


#13

To be clear, what is happening is I get this error when I try to use GetText, unless I use a debug statement in the code and its window is open.