Please state the obvious!

[Pendragon]

Access03/WinXP

I have a FE/BE and am at my end with what should be very simple. I have a
subform simply listing records from the table on which the form is based. In
trying to delete a record, the status bar says the data is read-only.

I've isolated this to the data file and not the form as I do not have this
problem on last week's backup of the data file. When I downloaded a current
data file from the client, I have the problem.

I have compared the relationships of tblIndividuals and tblServices
(one-to-many) and referential integrity is checked as are Cascades. I have
compared the details of each field in tblServices between the two data files
and they are exact.

I have verified three times that all user accounts have full permissions on
all objects for both the FE and BE files.

When I link the FE to last week's backup file, I don't have an issue
deleting records from the form, but when I link the FE to the current file, I
get the read-only message.

What am I missing? I'm going nuts.

Thanks.

 

[Jerry Whittle]

Open up Windows Explorer. Find the BE file. Right click on it. Go down to
Properties. Is Read Only un-checked?

Failing that, have you tried a compact and repair of the BE?

 

[Pendragon]

Read-only was not checked. I did the Compact & Repair on the BE, but that
didn't work.

I'm going to try to import the tables into a new database and see how that
fares.

 

[George Nicholson]

I have verified three times that all user accounts have full permissions

on
all objects for both the FE and BE files.

That cover Access security. What about operating system security?

Do all users have full OS permissions for the actual be file? (and the
folder its in as well, but that doesn't sound like the issue..)

 

[Pendragon]

Jerry & George - thanks for the replies. It gave me some ideas for future
problems of the same nature.

The central table has three number fields; the first is the Individual's ID
(a primary key from the Individuals table), the second is the Primary
Category ID (a primary key from the PrimaryServices table), and the third is
the Secondary Category ID (a primary key from the SecondaryServices table).
The SecondaryServices table has the ID field (autonumber), ServiceDescription
(text), PrimaryCategoryID (number).

The form is not based on the central table by itself; rather, it's a select
statement on that table joined to the two services table in order to populate
the form with the descriptions. The problem, I discovered, is that in
designing the SecondaryServices table, I apparently did not designate the ID
field as the primary key. Once I did that, I did not have a problem deleting
records from the Form view.

In a way, I guess, it makes sense, if you think of this in terms of a delete
query. Try to run a delete query on the tables as they were designed, and
I'd get that annoying error message about using an updatable recordset (or
something like that).

When I was comparing the two data files and the tables/fields, I guess I
missed the little key icon next to the field on the one table. That's okay,
it was only a couple hours wasted....... >:-(

Thanks!