Hi,

I'm experiencing a lot of "Error #300 Cannot lock the table for shared access" for no apparent reason since I have switched to D12 and the newest EDB version.

I'm using a customized ElevateDB Server, the settings are largely default.

It always happens on Table.Open, which I do when a user opens a form. There are no transactions.

Can someone give me a hint on the circumstances in which a table cannot be locked for shared access?

Thanks,

Heiko

Heiko


Ignoring the easy one (you have exclusive set on the table) the most likely culprit (I think) is updating the configuration files. I also have a vague memory that it may be that you've exceeded the permitted number of sessions.

Just had a skim through the newsgroups

1. doing something to the table that requires exclusive access (eg adding a column) whilst its already open - even in the same session
2. it seems to be more prevalent in f/s mode
3. possibly an sql query that is prepared but neither unprepared nor freed - ie the table is open
4. trying to access tables from different config files

Roy Lambert

Hi Heiko,

did you see the last thread with Error 9999?
https://www.elevatesoft.com/forums?action=view&category=edb&id=edb_general&msg=23253&page=1

I think this #300 locking is a subsequent error out of a faulty server.

Tim told me, that there was a fix in 2.38 Build 2 for same type of issue with queries on views.
"..., so obviously there is something in the fix that is breaking something else..."

Roy

Thanks! I think I can rule out anything of that.

gripsware

Thank you!! I think that's exactly what happens. Will try to downgrade EDB.

...which I can't, since the previous EDB version isn't available for D12...

That was the last time I'm using the newest Delphi for anything customer related. Putting out fires for weeks now...

After going back to Delphi 11.3 and EDB 2.37.3 I had now 3 days without error reports.

Pretty safe to say it's an EDB problem.

Heiko Knuettel wrote:

After going back to Delphi 11.3 and EDB 2.37.3 I had now 3 days without error reports.

Pretty safe to say it's an EDB problem.

I.B.  Have you communicated this to Tim??

I had a thoughty last night.  
I could be wrong, has been known to happen, but as I see it, the server is the server is the server.  All it is looking for is the proper communications from the clients.
With that thought in mind, what happens if you simply replace your 2.37.3 edbsrvr.exe with the equivalent 2.38.2 edbserver.exe for your D11.3 clients?
As I see it, if the problem resurfaces, then you have a very strong case to blame the edbsrvr.exe.
On the other hand, if the problem doesn't surface, then you have a strong case to eliminate the edbsrvr.exe as the culprit and need to look elsewhere.
Just a thought.

Regards,
Ian

Ian

No, I haven't contacted Tim directly, I thought he might look in here from time to time.

I guess it will be no fun finding that error, I can't reproduce it, so it probably has something to do with user load, poor connections or slow client PCs.

There is an access violation in the server logs, and after that random Error #300s. Just as described in the other Error 9999 thread .

>>what happens if you simply replace your 2.37.3 edbsrvr.exe with the equivalent 2.38.2 edbserver.exe for your D11.3 clients?<<

Since the error comes out of the server (at least I think so), it would still be there. The other way around might work.

Haven't tried it because different EDB versions on client and server might cause other problems (?), and since I am using a customized server there are functions checking if server and client have the same EDB version - if not, something did go wrong during an online-update.

I'm fine now, as we say in Germany "the cow is off the ice", I'm in no need to update to D12/EDB2.38 anytime soon.

Heiko