The simplest thing you can do is create a project and add dbc(s) and dbfs to it, then use the MODIFY button on a table you want to modify the structure.
You'll see this echo some commands to the command window, then:
Code:
USE table1 EXCLUSIVE IN 0
SELECT Table1
MODIFY STRUCTURE
So Scott is giving you the most important advice: EXCLUSIVE.
You get (Read Only) in the title of the table designer window if you only have a DBF opened SHARED.
Mike gives another very simple reason why a dbf only opens read-only when it has the read-only file system attribute set. But the more common case is only getting shared access, someone would need to intentionally set the attribute to data and I don't see a large use case for read-only files. A word dictionary? Even such meta-data will usually be open to slight changes, additional records, so it will not be flagged read-only in the file system.
A developer would rather keep a database in his local development folder to keep it away from users and always have exclusive access. And you should, too. That doesn't make it a simple case for getting that modified structure to production, because the current data is still the one in the file share you don't get exclusive hands-on without ending user sessions.
I assume you're not the original developer of this. Well, look out for documentation of procedures/handling of such situations. A good developer will have foreseen a way to quit all current users running the application to be able to apply changes to the database and provide a new EXE.
Bye, Olaf.
Olaf Doschke Software Engineering