The following statements are what I have found so far that do not work with design-locked files when used from other file:
The target file is design-locked, preventing modifications to forms and procedures while allowing data editing.
When these statements are used within the file, they function as intended. However, when accessed from another file, an error message “You are not authorized to change or inspect the design of this database” appears.
That’s exactly as intended. If it didn’t work that way, it would be trivial to break into a database by making your own database with malicious code. These operations can only be performed by someone that has access to the database, so these operations can only be performed by code that is part of the database itself.
This statement has to inspect the database structure to find out what kind of field is being filled (number, date, etc.). The security level doesn’t allow this.
This command can possibly add new fields to the database, which is not allowed because of the security. If you don’t need to add new fields, you should switch to the importtext statement, and use the “ADDFIELDS”,“NO” option.
Do you mean like the filemenubar statement? Of course that is not allowed. Again, the point of the security level is to allow the owner of the database to lock it down so that someone else can’t change it. For example, they might lock down the menus to specific commands only. It wouldn’t be much of a lock if anyone could come along with another database and override the menu specification.