I ended up remote connecting to the customer and reinstalled from scratch, then restored their database from backup.  It's all working fine now.  No more Error # 300.

I think the permissions must have been screwed up somehow because it all seems fine now - so far.

= Steve

I actually got a couple of Error #300s today while testing the application.  Prior to that, I haven't seen this error.

" ElevateDB Error #300 Cannot lock the procedure GetRecipientList in the schema Default for shared access."

The stored procedure mentioned in the error message executed fine dozens of times without problems, but a couple of times generated this error message.

What is "schema Default"?  Should that be the schema it's accessing?

= Steve

Never mind, it was unrelated to the other Error # 300s that a customer was getting.  The errors I was getting were caused by a bug in my code.

= Steve

After increasing the amount of logging in my application I discovered from the log files that one customer had the Error #300 occur 219 times. It occurred with just one stored procedure.  Although the problem did occur a lot, it executed 1,402 times without an issue.

I'm now trying to work out what makes this stored proc different from all of the others.

= Steve

Steve


Interesting.

Never having had the problem my first guess would be how long it takes to run. It may be that there are some circumstances that slow it down which causes the lock..


Roy Lambert

Steve,

<< After increasing the amount of logging in my application I discovered from the log files that one customer had the Error #300 occur 219 times. It occurred with just one stored procedure.  Although the problem did occur a lot, it executed 1,402 times without an issue. >>

A "shared" lock error is an *open* error, meaning that something else is altering the procedure when you attempt to execute it.

Are you performing any frequent alteration (or drop/create) operations in your applications/server ?

Tim Young
Elevate Software
www.elevatesoft.com

Hi Tim,

<< A "shared" lock error is an *open* error, meaning that something else is altering the procedure when you attempt to execute it.

Are you performing any frequent alteration (or drop/create) operations in your applications/server ? >>

No, nothing like that happens during normal usage.  

The only time it is done is when the user installs an update.  The database is then altered if there are any database changes required.  The server runs as a service and is stopped as part of the update process so anyone still logged in is kicked out.

= Steve

Steve,

<< The only time it is done is when the user installs an update.  The database is then altered if there are any database changes required.  The server runs as a service and is stopped as part of the update process so anyone still logged in is kicked out. >>

Is this procedure executed only from the context of the client application, or is there server-side code that executes it ?  If the latter, does it get executed in a worker thread ?

Also, can you send me the database catalog that includes this procedure ?  I can try stress-testing it here to see if there's anything weird going on.

Tim Young
Elevate Software
www.elevatesoft.com

<< Is this procedure executed only from the context of the client application, or is there server-side code that executes it ?  If the latter, does it get executed in a worker thread ?

Also, can you send me the database catalog that includes this procedure ?  I can try stress-testing it here to see if there's anything weird going on. >>

Responded by email.