It turns out I wrote a long discussion before figuring out that Panorama is doing exactly what it is supposed to do. I think my original answer still contains a ton of useful information, but if you’re in a hurry you can skip to the end for the solution.
The Can Modify Design option actually is more of a “design is protected” option. Not only does this prevent the design from being modified, but it also prevents the design from being inspected by unauthorized users. If you don’t have permission to modify the design, you also don’t have permission to find out what the field names are, or the form names, or other metadata information about the database. This provides more security to the database. For example, if you don’t know what the field names are, you can’t write code in another database that would export the data.
However, this does break some common coding techniques. For example, it’s common to check whether a procedure exists using code like this:
arraycontains(dbinfo("procedures",""),"some procedure name",cr())
But if the database is restricted so that the design can’t be modified, this code won’t work, because the code is not allowed to retrieve the list of procedures. To get around this a new function was added in Panorama X 10.2.
procedureexists("some procedure name")
Because this function doesn’t provide access to the list of procedures, it will work even if modifying the database design isn’t allowed.
There’s a similar issue with the objectinfo( and objectinfoarray( functions – they doesn’t work if modifying the database design isn’t allowed. The editfield statement relies on these functions, so it doesn’t work. Here’s the code in EDITFIELD that causes the problem.
let targetObjects = objectinfoarray({objectinfo("id")},{objectinfo("fieldname")=targetField and objectinfo("class")="TextEditorObject"})
At the moment there is no alternate “safe” method that can be used in this situation, so this feature simply doesn’t work in a locked down database. You would have to do this the old fashioned way – give the object a name and then open the object
objectaction "the name","open"
You may wonder why objectinfo( and objectinfoarray( are restricted. If they weren’t, an attacker could write code in a separate database to analyze your forms and expose all sorts of private information – field names, procedure names, etc. What’s needed is a more specialized function that allows this task to be performed without exposing potentially sensitive information.
I did some further research and I have a question for you – is this code in a procedure in the database in question? If so, it should work. Panorama assumes that code you have written into procedures in the database is authorized to do things in the database, even modify the design. But if you do something like this:
window "Database X:Form Y"
editfield "Zorg"
it won’t work. Oh wait – that is EXACTLY what you are doing (though with openfile, not window)!! Ok, that’s the problem – Panorama thinks your code is potentially from an attacker. What you need to do is make a procedure in “DB-B”, let’s assume it is called EditMyField. Then your code would be
openfile "DB-B"
call EditMyField
