This line is triggered following a selection from a rundialog form. The procedure then evaluates what is in the array somearray to do some other things.
The error generated is “ArrayBuild Error: The database avariablename is not open”. There is no database with the name of the variable’s value. It never was a database, just a variable value. I don’t see how this ever worked in Panorama 6.
The arraybuild statement has the form, arraybuild array, separator, database, formula, query, so you statement is looking for a database called avariablename.
I suspect you should be using a different statement for whatever it is that you are doing.
No, it doesn’t expand to that. Instead of avariablename, the expanded version will contain the contents of avvariablename, and anothervariablename will expand to the contents of that.
Based on what Jeff has given us, this code could work. It really depends on what is in those variables. At some point presumably avariablename was set to the name of an open database, and the anothervariablename variable was set to the name of a field in that database. But you didn’t show us that code (I assume it’s complicated), so we can’t really say.
If I have a problem with an execute statement, I’ll usually change it to message or displaydata, so that I see exactly what code is actually being executed. Or even copy it to the clipboard and paste it into a temporary procedure so I can try it out in a procedure window, where I can get better error information.
The odd thing is of course the error message. If that message is coming from arraybuild, which it seems it must be, how can it possibly reference the avariablename variable? In this situation, the arraybuild statement should not even know that the arraybuild variable exists. I can’t understand this message from the code snippet provided.
Huh? The contents of this variable HAS to be the name of a database. That’s what the arraybuild statement requires in this spot. If it isn’t, that’s why it doesn’t work, though I don’t understand the error message.
At some point presumably avariablename was set to the name of an open database, and the anothervariablename variable was set to the name of a field in that database.
Huh? The contents of this variable HAS to be the name of a database. That’s what the arraybuild statement requires in this spot. If it isn’t, that’s why it doesn’t work, though I don’t understand the error message.
That’s my point. It isn’t and never was a database. I don’t know how it works in Pan 6, but it does.
The content of the variable avariablename is the result of a choice made in the process and anothervariablename is indeed the contents of a field in the open database. Let’s say the choices are USPS, FedEx and UPS. So arraybuild is using on of these choices as the database name. There was never a database named UPS, for example. That’s why I can’t see why it works in Pan 6. That’s why it’s so confusing. And yes, this is happening in the middle of about 4 procedures called by one another.
Impossible. If it works in Panorama 6, there was a database name in that field.
[quote=“JeffK, post:4, topic:3136”] and anothervariablename is indeed the contents of a field in the open database.
[/quote]
No, the way this is written it must be the NAME of the field, not the contents of the field.
I think you need to write the arraybuild statement you need in a separate procedure, and test it. Then figure out how to write an execute statement to generate that code. Then run and verify that the code is really being generated the way you think.
That’s what I thought, but when I display the contents of the variable that is supposed to be a database (message avariablename), it is one of the choices, not a database.
I figured I would have to rewrite it, but I thought I would double-check to see if what I thought was impossible was also impossible to you. The problem is, I’m not sure what the arraybuild statement is that I need since the one being currently used is impossible. I’ll update this if and when I figure it out.
I know that - I was trying to simplify my response to explain to Jeff what was happening. I had assigned values to the variables and used the message statement but tried to keep it simple - probably confused everybody instead.
I’m also baffled as to why Jeff has anothervariablename in chevrons when it’s a variable.
Here’s an example that shows why this is needed in this case. This rather silly example will display the value of each field in the current database (from the current record).
Suppose the current database has fields named First Name, Last Name, and Phone Number. Then when you run the code above, it will generate this code, line by line:
Without the chevrons, each of these lines would result in a syntax error, and the program would stop. So it doesn’t matter what the characters are in the variable name anothervariablename, what matters is what the CONTENTS of this variable are. The same is true in Jeff’s code.
After a lot of testing, I think what is happening is that the execute statement doesn’t work in Panorama 6 but it doesn’t throw an error message. Panorama X does throw an error message.
After speaking with my client, it turns out that they no longer have the requirement for which this code was originally created, so I could just delete it.