"Cannot update: Database or object is read only"

[Jackie]

Why is this message is displayed on one computer, but not on another computer?

Specifics:
This message is displayed when a the TransferText command is executed in a module. All of the permissions have been verified that the user executing the command has all of the rights for updating the table that is populated. This message is also displayed when a macro using the TransferText command is executed. The NT Attribute Properties for the data being imported indicate that the "Read Only" attribute is unchecked.

I copied the .mdb and associated system.mdw to a different computer and was able to run the TransferText command without error.

I have tried to "TransferText" to other tables in the database and get the same error. When I specified a file created from a different source, the command ran without error. This leads me to believe that the source has changed, but the error occurs with earlier successful version of the source.

Any idea where to continue trouble-shooting this problem?

 

[RickSpr]

I wouldn't bother checking for access restrictions on the external text file. Read only shouldn't be a problem on those.

Can this user update the table in plain old Datasheet View? If not, we can eliminate problems in the import logic.

You said you'd checked the permissions on the tables, so that's out. But how about the database itself--is the directory it resides in writable by the user? Likewise the lock file?

What do you mean by "When I specified a file created from a different source, the command ran without error"? Do you mean it succeeds with a different text file? If so, I'm totally stumped. Rick Sprague

 

[Jackie]

Thanks for responding.

The user is able to update data in the tables and is able to copy files from the network drive on which the .mdb. system.mdw, and test data files exist.

The application imports comma delimited text files produced by a legacy system. I copied these files to the user's C:\ drive and still got the "Read Only" error. I created a test file in quatro pro and was able to successfully import.

The user is running on Windows NT. Is it possible that the System Admin staff has placed some sort of restriction on the files? If so, what type of restriction?

You said that bother read only shouldn't be a problem on the external text file. Does this mean that access can import text files regardless of being marked "Read only" in the Windows properties?

 

[RickSpr]

OK, everything you say sounds kosher. I'm quite stumped. The only thing I can think of you haven't checked is the update permissions on the Import/Export specifications tables. These are system tables named MSysIMEXSpecs and MSysIMEXColumns. You wouldn't normally need to update them when you do a text import, but there are certain circumstances where Access tries to update the spec in the background.

Show hidden/system tables (Tools>Options>View), then check the permissions the user has on these two tables. If one of them is read-only to the user, that might be your problem. The replication system protects you from actually making any changes to them anyway, so it's safe to go ahead and give the user Administer permissions on these tables.

It's possible that whoever set up the permissions had Show System Tables turned on, and just went through all the tables removing permissions, so he/she got these two in the bunch. But these tables shouldn't really be restricted that way; Access takes care of protecting his own tables.

Give it a try and let us know if it works. Good luck! Rick Sprague

 

[Jackie]

I checked the permissions on the system tables and they are set to update, etc.

Since the user is running Windows NT and the development machine is Windows 95, we had an NT Administrator with local admin priviledges logon and execute the application. She also gets the "Read Only" error.

At this point, is there anything else within the Access application that should be verified? Our next step is to furhter investigate Windows NT configuration.

 

[RickSpr]

Some symptoms seem to indicate that the problem is with the text file, but others suggest it's in the database or Access internal logic. I wish we could narrow it down better. When you copy the text file to the user's local hard disk, it still fails, right? Can you open the file on the local hard disk with Notepad? If so, can you save it?

If Notepad can't open it, the database is out of the picture and something is wrong with the text file. Maybe it has an NT 4.0 file stream hidden within it. That's about all I know about file streams, though.

If Notepad can open it, on the other hand, the text file may (or may not) be exonerated. Rick Sprague

 

[Jackie]

After some experimenting, we have narrowed it to the user permissions. When the import button on the application screen is selected, a macro is called. The macro calls a function in a module. The macro had perms selected for the "Admin" user. No other macros had perms selected. When the offending macro's perms were unselected, the import executed.

What is weird is why did this work on one machine, but not another?

Someone suggested that the system.mdw being used is Access '97 while the .mdb is Access 2000.

Is there some way to identify the version of the system.mdw?

 

[Guest_imported]

This sounds like it could be a filename extension problem. I had the same situation exactly and it turned out to be a bug in the MS Jet Engine that if you do TransferText in Access 2000 and the file extension does not match one of the accepted input types, then it fails exactly as you specified.

You should definitely check into this link...

http://support.microsoft.com/support/kb/articles/Q245/4/07.asp

Hope this helps.