Single user file thinks it is a shared file?

I have a Single User File that I open with the OpenDatabase statement before replacing its data with an ImportText statement. On first attempt to run the procedure, I get the following error message: “ImportText statement cannot replace existing text when database is shared.” However, if I first open the file with an OpenFile statement and then run the above procedure to replace the data, it works with no error message. I am puzzled. It is possible that I created the single user file by detaching and copying a shared file, but I honestly can’t remember. Is there a way to make sure a single user file is truly a single user file so that it does not occasionally think it is a shared database?

Also there seems to be a subtle difference between and OpenFile statement and an OpenDatabase statement. I changed my procedure to first open the file with an OpenDatabase statement, and the files does not appear to open (although MemoryUsage indicates the file is open and in memory). Switching out the OpenDatabase statement with and OpenFile statement does open the file.

You are actually opening the database with the OpenDatabase statement either way. In Panorama X, the OpenFile statement is constructed using Panorama code, and ultimately relies on the OpenDatabase statement (which is written in Objective-C) to open the database.

Again, there can’t be any difference, because ultimately Panorama always uses OpenDatabase to actually perform the open operation.

There is something else going on other than what you have described. I could speculate, but probably not very productively.

This post is inadvertently about two separate topics. The first is about a single-user database that has at times an attribute of a shared database. The other topic is about an issue related to an OpenFile statement. I wish to re-address the issue regarding a single user database that persistently sometimes give me an error related only to shared databases. I know persistently sometimes is probably an oxymoron, but let me explain. The procedure builds an array from data stored in a shared database. The procedure continues by importing the array to and replacing data in a single-user database. It is a straight forward and fairly simple procedure. The problem arises when the procedure executes an OpenDatabase statement for the single-user database prior to importing the array and replacing the data in the single-user file. The following error message occurs:
However, if I manually open the single-user file prior to running the ImportText statement, no error message occurs. The error only happens when I execute the procedure (which is stored in a shared database) from a cold start without the single-user database open and in memory. Thus this anomaly occurs persistently (every time from a cold start) sometimes (but never when the single-user file is already open). Perhaps someone with a better brain than mine can lend me a hand. Much thanks. By the way, there is no file on the server with the same name as the subject single-user database.

I feel like you’ve just re-stated your original post without providing any additional information. It appears that you think a single user database but a shared database is actually active. Remember, in a procedure the active database isn’t necessarily the visibly frontmost window, you may have used setactivedatabase or a secret widow.

The error message doesn’t say what the database is. The shared database may have a different name, but it is active at the moment you tried to do the import. You could verify this but adding an instrumentation line right before the importtext statement.

zlog info("databasename")
importtext ...

Jim, you are right. The shared database was the active file as you stated. The statement prior to the ImportText is OpenDatabase [single-user file]. I assumed that OpenDatabase would force the single-user file to active database position, but it does not. However, when I substitute the OpenDatabase with OpenFile, the OpenFile statement does make the single-user file the active database.

It will make the specified database active unless the database is already open with no windows.

That explains what I thought was strange behavior of my code. My puzzle is now solved. Thanks for the help!