Jim,

This comes from resources being locked during an update normailly.
The term resources is pritty vague.  It means something needed during the 
update has a lock on it.  If someone else is modifing information in a table 
you are updating could cause this.  Some corruption in the database could 
cause this.  Very busy/slow networks will not help.  The resource could be the 
#1 file, a page or row in the #2 file, a page in the #3 file, waiting to get 
the next available block for the #2 or #3 file eithe from the #1 file or 
waiting for the network to allocate the next block.

Usually it goes away, and you don't need to worry about it.

If it continues to be a problem, you might want to do row locking in the 
datbase instead of the default page locking.  You do this by changing the 
setting of the qualcols setting before you connect to the database.  You need 
to change it from 10 to either 1 or 2, I don't remember for sure.  With row 
locking, you give up some performance, but will have fewer multi user 
conflicts.  When you are updating information, the system has to set more 
locks because it locks smaller pieces of the file.

This is kind of an interesting test:
Insert rows into a table one at a time from the R> and keep an eye on the size 
of the #2 file.  You will be able to tell when the R:base adds another block 
to the #2 file because you will do inserts instantly for a few rows and then 
all of a sudden an insert will be a lot slower, then they will go fast again.  
The time lag on the slow row is the amount of time it takes R:base to request 
another page from the OS and add it to the end of the #2 file.


Troy


>===== Original Message From [EMAIL PROTECTED] =====
>I encountered the subject message during execution of a well-tested program. 
I could find reference to it in the archive of this list but no suggested 
causes.
>
>I had password protection on the database and had failed to grant select 
permission on a view. Apparently the other users were using the password, or 
rarely accessing the view.
>
>As usual, mia culpa.
>Hope this is of use to someone,
>
>Jim Blackburn
>Kodiak
>================================================
>TO SEE MESSAGE POSTING GUIDELINES:
>Send a plain text email to [EMAIL PROTECTED]
>In the message body, put just two words: INTRO rbase-l
>================================================
>TO UNSUBSCRIBE: send a plain text email to [EMAIL PROTECTED]
>In the message body, put just two words: UNSUBSCRIBE rbase-l
>================================================
>TO SEARCH ARCHIVES:
>http://www.mail-archive.com/rbase-l%40sonetmail.com/

Troy Sosamon
Denver Co
[EMAIL PROTECTED]

================================================
TO SEE MESSAGE POSTING GUIDELINES:
Send a plain text email to [EMAIL PROTECTED]
In the message body, put just two words: INTRO rbase-l
================================================
TO UNSUBSCRIBE: send a plain text email to [EMAIL PROTECTED]
In the message body, put just two words: UNSUBSCRIBE rbase-l
================================================
TO SEARCH ARCHIVES:
http://www.mail-archive.com/rbase-l%40sonetmail.com/

Reply via email to