Help - "this recordset is not updatable"

[ZRexRider]

I've been reading the newsgroups and most of the solutions for this
message are simple and obvious but unfortunately don't solve my
problem.

I have an MS-Access 2002 ADP application that connects to SQL server.
The application is deployed to 100+ users and in most cases works fine.

I have a sub-set of users (~20) who have an auditing function. They
review transactions entered by the other 100+ and accept or reject
them. There are a few fields that these auditors are allowed to
change. However, there are a number of users in this sub-set who are
unable to edit these fields. If they attempt to change that status bar
displays "this recordset is not updatable".

It seems to be MS-Access/workstation related. If I have the user (who
has problems) log into the PC of a user who doesn' t have this problem
using their own logon credentials it works perfectly. If I reverse
that - have a user who has no problems editing this data log on to a
workstation where the user is having problems - they find that they
cannot edit the data either. So in my mind it doesn't have anything to
do with user rights, the recordset or my code since it's the same
recordset, same database, same code no matter who runs it.

I've been comparing Access versions, service packs, DLL versions....
and I'm not finding anything obvious. Does this ring any bells with
anyone?

Thanks

[salad]

ZRexRider wrote:

I've been reading the newsgroups and most of the solutions for this
message are simple and obvious but unfortunately don't solve my
problem.

I have an MS-Access 2002 ADP application that connects to SQL server.
The application is deployed to 100+ users and in most cases works fine.

I have a sub-set of users (~20) who have an auditing function. They
review transactions entered by the other 100+ and accept or reject
them. There are a few fields that these auditors are allowed to
change. However, there are a number of users in this sub-set who are
unable to edit these fields. If they attempt to change that status bar
displays "this recordset is not updatable".

It seems to be MS-Access/workstation related. If I have the user (who
has problems) log into the PC of a user who doesn' t have this problem
using their own logon credentials it works perfectly. If I reverse
that - have a user who has no problems editing this data log on to a
workstation where the user is having problems - they find that they
cannot edit the data either. So in my mind it doesn't have anything to
do with user rights, the recordset or my code since it's the same
recordset, same database, same code no matter who runs it.

I've been comparing Access versions, service packs, DLL versions....
and I'm not finding anything obvious. Does this ring any bells with
anyone?

Thanks

Have you gone to
http://groups.google.com/advanced_search?hl=en
and entered
recordset not updateable
in the All words box and entered
*Access*
in the Groups box yet?

[Cilla]

salad wrote:

ZRexRider wrote:

I've been reading the newsgroups and most of the solutions for this
message are simple and obvious but unfortunately don't solve my
problem.

I have an MS-Access 2002 ADP application that connects to SQL server.
The application is deployed to 100+ users and in most cases works fine.

I have a sub-set of users (~20) who have an auditing function. They
review transactions entered by the other 100+ and accept or reject
them. There are a few fields that these auditors are allowed to
change. However, there are a number of users in this sub-set who are
unable to edit these fields. If they attempt to change that status bar
displays "this recordset is not updatable".

It seems to be MS-Access/workstation related. If I have the user (who
has problems) log into the PC of a user who doesn' t have this problem
using their own logon credentials it works perfectly. If I reverse
that - have a user who has no problems editing this data log on to a
workstation where the user is having problems - they find that they
cannot edit the data either. So in my mind it doesn't have anything to
do with user rights, the recordset or my code since it's the same
recordset, same database, same code no matter who runs it.

I've been comparing Access versions, service packs, DLL versions....
and I'm not finding anything obvious. Does this ring any bells with
anyone?

Thanks

Have you gone to
http://groups.google.com/advanced_search?hl=en
and entered
recordset not updateable
in the All words box and entered
*Access*
in the Groups box yet?

It does sound workstation related but still a security issue. What are
the sql privs the workstations have. Are the workstations identical.
It sounds like its the workstation privs not the user privs.
However....

Do you have both sql and access security involved? If so, it could be
the access sequrity file that is stoping it on the workstation not the
sql security at all. This sequrity in access is held in the
system.mdw. Try creating a new system.mdw via workgroup administrator
under tools security. This will disconnect the existing security and
create a new empty access security on the workstation.

good luck

[deluxeinformation]

It does sound workstation related but still a security issue. What are
the sql privs the workstations have. Are the workstations identical.
It sounds like its the workstation privs not the user privs.
However....

Do you have both sql and access security involved? If so, it could be
the access sequrity file that is stoping it on the workstation not the
sql security at all. This sequrity in access is held in the
system.mdw. Try creating a new system.mdw via workgroup administrator
under tools security. This will disconnect the existing security and
create a new empty access security on the workstation.

Correct me if I'm wrong, but I don't think Access workgroup security
applies when the application is an ADP. And I'm not sure how one
defines security at the workstation level for SQL server. I'm not
saying you're wrong, I just am not aware of SQL being aware of specific
workstations, only roles and users.

I would first make sure that each user is utilizing an identical copy
of the ADP or ADE by copying a version from a machine that does work to
one that doesn't, and make sure that both users' accounts on each
workstation reference the same copy.

Bruce

[ZRexRider]

de************* **@gmail.com wrote:

It does sound workstation related but still a security issue. What are
the sql privs the workstations have. Are the workstations identical.
It sounds like its the workstation privs not the user privs.
However....

Do you have both sql and access security involved? If so, it could be
the access sequrity file that is stoping it on the workstation not the
sql security at all. This sequrity in access is held in the
system.mdw. Try creating a new system.mdw via workgroup administrator
under tools security. This will disconnect the existing security and
create a new empty access security on the workstation.

Correct me if I'm wrong, but I don't think Access workgroup security
applies when the application is an ADP. And I'm not sure how one
defines security at the workstation level for SQL server. I'm not
saying you're wrong, I just am not aware of SQL being aware of specific
workstations, only roles and users.

I would first make sure that each user is utilizing an identical copy
of the ADP or ADE by copying a version from a machine that does work to
one that doesn't, and make sure that both users' accounts on each
workstation reference the same copy.

Bruce

You're correct - MS-Access workgroup security is not available in ADP
files so I don't think that's an issue. I've not heard of workstation
security but so I'm "guessing" that's not it either.

Here's what I did find though:

The following workstations do not prohibit changing data and have the
following versions of ADO:

Workstation A: 2.81.1117.0
Workstation B: 2.71.9030.0
Workstation C: 2.71.9030.0

The following workstations do not allow the user to change data with
the exact same application, having the exact same user as the
successful user on A,B and C:

Workstation D: 2.53.6200.0
Workstation E: 2.53.6200.0

Now this is kind of an odd error to blame on a version of ADO but
sometimes when you line up the right variables and toss in an odd
version DLL you get spastic results. I'll post the results of my test
after upgrading D or E with the latest MDAC. I have to go through the
red tape of getting corporate support team to do it though - won't let
me do it.

Thanks for the feedback everybody

[deluxeinformation]

ZRexRider wrote:

You're correct - MS-Access workgroup security is not available in ADP
files so I don't think that's an issue. I've not heard of workstation
security but so I'm "guessing" that's not it either.

Here's what I did find though:

The following workstations do not prohibit changing data and have the
following versions of ADO:

Workstation A: 2.81.1117.0
Workstation B: 2.71.9030.0
Workstation C: 2.71.9030.0

The following workstations do not allow the user to change data with
the exact same application, having the exact same user as the
successful user on A,B and C:

Workstation D: 2.53.6200.0
Workstation E: 2.53.6200.0

Now this is kind of an odd error to blame on a version of ADO but
sometimes when you line up the right variables and toss in an odd
version DLL you get spastic results. I'll post the results of my test
after upgrading D or E with the latest MDAC. I have to go through the
red tape of getting corporate support team to do it though - won't let
me do it.

Thanks for the feedback everybody

I don't think this is at all unlikely. It wouldn't surprise me at all
if making sure everyone had the latest ADO fixed things. Let us know
what you find out.

Bruce

[ZRexRider]

Done! Yes the solution to this problem was to upgrade all workstations
having < ADO 2.71.9030.0 . The support team upgraded all to 2.8xxx and
presto - all users are able to change this listbox data without error
messages and without code changes.

Hopefully this thread will help the next guy.

de************* **@gmail.com wrote:

ZRexRider wrote:

You're correct - MS-Access workgroup security is not available in ADP
files so I don't think that's an issue. I've not heard of workstation
security but so I'm "guessing" that's not it either.

Here's what I did find though:

The following workstations do not prohibit changing data and have the
following versions of ADO:

Workstation A: 2.81.1117.0
Workstation B: 2.71.9030.0
Workstation C: 2.71.9030.0

The following workstations do not allow the user to change data with
the exact same application, having the exact same user as the
successful user on A,B and C:

Workstation D: 2.53.6200.0
Workstation E: 2.53.6200.0

Now this is kind of an odd error to blame on a version of ADO but
sometimes when you line up the right variables and toss in an odd
version DLL you get spastic results. I'll post the results of my test
after upgrading D or E with the latest MDAC. I have to go through the
red tape of getting corporate support team to do it though - won't let
me do it.

Thanks for the feedback everybody

I don't think this is at all unlikely. It wouldn't surprise me at all
if making sure everyone had the latest ADO fixed things. Let us know
what you find out.

Bruce