Error using the ADO AddNew method Version: 2002 (10.0) XP

[Guest]

I have a single user in a group of over 70 that is getting the following error:

Current Recordset does not support updating. This may be a limitation of the
provider, or of the selected locktype.

Here is the code causing the error. It's occurring on the last line (110)

20 Set cnn = CodeProject.Connection
30 Set rst = New ADODB.Recordset
40 With rst
50 .ActiveConnection = cnn
60 .CursorType = adOpenKeyset
70 .LockType = adLockOptimistic
80 .Source = "SELECT * FROM tblUploads WHERE [Temporary] = True and
[UserID] = '" & alActualUser & "'"
90 .Open Options:=adCmdText
100 If .EOF Then
110 .AddNew

This is actually just an example, as she's getting the same error in every
piece of code where the ADO .AddNew method is called.

The LockType and CursorType settings seem fine. We use Windows XP, Access
2002 Runtime and the most recent Jet Patch, MDAC 2.8 patch and Office XP SP3
have all been run.

We are using Access user level security and this is only occurring when one
specific user is signed in to the database. If I sign in on her PC the error
does not occur. If she signs in on any PC, it occurs. She is a member of
the same groups as the rest of the users. I tried removing her from the
workgroup file and adding her back but it didn't help. I have also checked
her network security settings and they seem fine -she can edit/create/delete
privieleges in all relevant folders.

I found a KB article 287455 which says the error can happen if you use a
client side cursor and the Microsoft.Access.OLEDB.10.0 provider. I'm not
specifying a cursorlocation so I believe the default of adUseServer should
apply, and cnn is CodeProject.Connection, which should be using Jet, not
Access 10, no?

Any other ideas?

 

[Alex Dybenko]

Hi,
do you have a primary key for tblUploads table?

 

[Guest]

Hi Alex,

Yes, tblUploads has an autonumber primary key. And, even better news, I
just discovered the problem this morning. We use a central logon database
for users to open other databases and in the generation of the script for the
Shell command, a very subtle fault in the code was attaching the /ro switch
only for this user, causing the database to be opened as read-only. The
biggest problem was that as far as I can tell Runtime does not provide the
warning as a database is opening that it's being opened as read-only. It was
only when I tested her ID again on my machine and also assured the runtime
switch was not added that I got the initial read-only warning message and
figured out what was happening.

Thanks for the reply,
Jeff

Hi,
do you have a primary key for tblUploads table?

--
Alex Dybenko (MVP)
http://alexdyb.blogspot.com
http://www.PointLtd.com

I have a single user in a group of over 70 that is getting the following
error:

Current Recordset does not support updating. This may be a limitation of
the
provider, or of the selected locktype.

Here is the code causing the error. It's occurring on the last line (110)

20 Set cnn = CodeProject.Connection
30 Set rst = New ADODB.Recordset
40 With rst
50 .ActiveConnection = cnn
60 .CursorType = adOpenKeyset
70 .LockType = adLockOptimistic
80 .Source = "SELECT * FROM tblUploads WHERE [Temporary] = True and
[UserID] = '" & alActualUser & "'"
90 .Open Options:=adCmdText
100 If .EOF Then
110 .AddNew

This is actually just an example, as she's getting the same error in every
piece of code where the ADO .AddNew method is called.

The LockType and CursorType settings seem fine. We use Windows XP, Access
2002 Runtime and the most recent Jet Patch, MDAC 2.8 patch and Office XP
SP3
have all been run.

We are using Access user level security and this is only occurring when
one
specific user is signed in to the database. If I sign in on her PC the
error
does not occur. If she signs in on any PC, it occurs. She is a member of
the same groups as the rest of the users. I tried removing her from the
workgroup file and adding her back but it didn't help. I have also checked
her network security settings and they seem fine -she can
edit/create/delete
privieleges in all relevant folders.

I found a KB article 287455 which says the error can happen if you use a
client side cursor and the Microsoft.Access.OLEDB.10.0 provider. I'm not
specifying a cursorlocation so I believe the default of adUseServer should
apply, and cnn is CodeProject.Connection, which should be using Jet, not
Access 10, no?

Any other ideas?