recordset no updatable - table lock
Hi
On my app, now I moved to multi-user. The problem is that, on the first computer connected to the "server", all its OK. However, on the second computer, the records that I want to update yields the error "recordset is not updatable". It looks that I do have a table level lock and not a record level lock.
How do I unlock the table and lock the record? (the forms are unbound - I am using manual selects...
any help appreciated
/joao
On my app, now I moved to multi-user. The problem is that, on the first computer connected to the "server", all its OK. However, on the second computer, the records that I want to update yields the error "recordset is not updatable". It looks that I do have a table level lock and not a record level lock.
How do I unlock the table and lock the record? (the forms are unbound - I am using manual selects...
any help appreciated
/joao
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
this situation is that, some times it is ok, other no!
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Hi
I am going to read thoroughly But something wrong is happening, because, suddenly, it happens ALWAYS!!!.
I am going to read thoroughly But something wrong is happening, because, suddenly, it happens ALWAYS!!!.
ASKER
Thanks! here is what REALLY happened:
A few weeks ago I migrated the backend to sql/sever (yes: it was a really stupid move, for the actual app.
I migrated all tables and it went smooth, albeit 8 to 15 times slower (sigh).
Then I migrated to a separate server, hosting the sql/server (I costed 3 full days to get it running on that server, using the backup/restore facility) and then I was stuck by not being able to use any client machine AT ALL - to put it to work, even with your help, it would cost me at least 3 to 4 more days (the event to be supported by the app would be over).
To use sql/server we need to fully understand the cabala at black belt level. We need to parameterise TCP/IP / PORTS /USERIDS (sigh sigh sigh oh sigh), and as a prize we get an app running muuuuuuch slower.
So I decided to rollback in emergency to the ms/access engine BE.
But microsoft team has an internal bet that no customer should be allowed to do so.
Yes. They have some devilish tricks to play to mavericks:
They took out all the keys from all tables! - that was a good move -- what a lesson to me.
So my app, that was working since july, suddenly started to fall apart incoherently and then, totally.
After your feedback, I started looking onto the tables' structures, started yelling at the sky (yes, using some baaad words), re-keyed all the tables and its up and running again..
People may say that sql/sever is much safer, performant and bla bla bla.
I'll will say: definitely yes.
But only if it works.
A few weeks ago I migrated the backend to sql/sever (yes: it was a really stupid move, for the actual app.
I migrated all tables and it went smooth, albeit 8 to 15 times slower (sigh).
Then I migrated to a separate server, hosting the sql/server (I costed 3 full days to get it running on that server, using the backup/restore facility) and then I was stuck by not being able to use any client machine AT ALL - to put it to work, even with your help, it would cost me at least 3 to 4 more days (the event to be supported by the app would be over).
To use sql/server we need to fully understand the cabala at black belt level. We need to parameterise TCP/IP / PORTS /USERIDS (sigh sigh sigh oh sigh), and as a prize we get an app running muuuuuuch slower.
So I decided to rollback in emergency to the ms/access engine BE.
But microsoft team has an internal bet that no customer should be allowed to do so.
Yes. They have some devilish tricks to play to mavericks:
They took out all the keys from all tables! - that was a good move -- what a lesson to me.
So my app, that was working since july, suddenly started to fall apart incoherently and then, totally.
After your feedback, I started looking onto the tables' structures, started yelling at the sky (yes, using some baaad words), re-keyed all the tables and its up and running again..
People may say that sql/sever is much safer, performant and bla bla bla.
I'll will say: definitely yes.
But only if it works.
Oh, not a pleasant experience!
ASKER
Hi -
once again, thanks! Great clear article!
/joao
once again, thanks! Great clear article!
/joao
ASKER
NOPE...... but it will be a looooooong time before switch to sql/server....
thanks again!
thanks again!
Keep in mind, that once you move to SQL Server, you need a couple of things
1. a primary key in every table
2. a rowversion (timestamp) field in every table. This field is not about date/time, it is used by SQL Server to prevent write conflicts. You might want to read this article or do some research on this data field type
1. a primary key in every table
2. a rowversion (timestamp) field in every table. This field is not about date/time, it is used by SQL Server to prevent write conflicts. You might want to read this article or do some research on this data field type
ASKER
thanks for the article! I went through it and it was great!
ASKER