Access won't let me save a design change to a table

[Phil Sheppard]

I added a new field to a table in Design View, then clicked Save. A box came
up saying the table was read-only and changes couldn't be saved. I saved the
table with a new name, but discovered that the new table didn't contain my
data. Obviously I could import it, but there must be a way of saving design
changes to a table. I haven't found it in Help or any Community Discussion.
Can anyone help?

 

[George]

Is the table a linked table, by any chance?

 

[Larry Kahm]

Was the table in use by someone else when you attempted this modification?

Larry

 

[Phil Sheppard]

Larry - Thanks for replying - see my reply to George. Phil

 

[Phil Sheppard]

Is the table a linked table, by any chance?



Many thanks for replying. It wasn't linked or in use by someone else, but it did seem to think it was shared. I discovered the solution by going to Tools/Options, then changing the status of the table or database from Shared to Exclusive.

As a general constructive comment, I think a general approach to Help which
Microsoft should adopt is to include in Help topics every single element of
every single menu window, with more extensive comment on what the element
does. They have the question mark, but not for every window, and the comment
often does not really explain the function. This is certainly true for the
Shared/Exclusive choice in the window I've referred to above.

Thanks again.

Phil Sheppard

 

[George]

Excellent that you found your own solution. The ones we come up with
ourselves are always the most satisfying.

With regard to Help, there are occasions on which I wish the discussions
available were more, well, helpful. In MS's defense (and this is true of
pretty much every software company, I believe), trying to come up with the
level of detail you describe would be a very intense undertaking indeed.
I've written about Access, both as an author and as a developer providing
documentation. I can testify that it's not easy, in a limited number of
words, to cover every conceivable variation on every conceivable topic even
when you have (theoretically) unlimited resources, as MS might seem to have.

That said, again, I do agree Access Help could stand to be revised with more
of an end-user viewpoint in mind. I hate the kind of help topics that do
nothing more than describe options for a setting. I always want to know
things like "WHY" I would choose one option over another. If I knew which
option was approprriate for a given situation already, I wouldn't be looking
at help in the first place just to know what the options are, now would I?

Sorry, I got off on a little rant there. You seem to have hit a sore spot.


Yes, I agree with you about Help.

George

 

[Phil Sheppard]

George - Thanks for your interesting comments. I don't agree with you that
my suggestion would be a very intense undertaking. When they design and
write applications, they have to write code for every single element in every
single menu, so the additional task I'm suggesting is simply to describe (in
layman's language) what each task does and maybe why you would select it
against the other options. The designer/code writer should know this off the
top of their head, so it would be a matter of writing a few sentences in a a
minute or two. I would have thought proper documentation is a standard
requirement in software development, and the interlinking of functions should
be meat and drink to someone designing a relational database!

Phil

 

[George]

Yes, but it is a lot of work to do it right.

I've written a 500+ page book which is, by anyone's standards, merely an
introduction to basic Access functionality. It took me more than 6 months
(admittedly, I was writing between development projects, but nonetheless it
was not a short period of time).

One of the more common pieces of feedback I got was "You should have
discussed such and such in more detail" or, "Why didn't you describe such
and such option." Trust me, the developers put enough time into creating the
code . Asking them to create Help files as they go would meet with a lot
less than enthusiasm from most of them. Again, I'm not arguing the
desirability of it. I'm simply saying that the task is not as simple as it
might appear.

Plus--and I say this with all due respect to my fellow developers--coding
and writing about it are two divergent skill sets. I readily admit to
greater facility with the latter than with the former. I have a high degree
of respect for those who can do both well. You'll see posts from many of
them here. Not to put too fine a point on it, but I am in awe of their
knowledge and their ability to convey it succinctly.