Hello,

as i can read in forum, in case of Error # 1005 (Cannot lock the row in the table) we want to show on client-side some information about the user currently locking but if we run:

SELECT SS.User, SS.IPAddress, SS.Process
FROM Configuration.ServerSessionLocks SSL
LEFT JOIN Configuration.ServerSessions SS ON (SS.ID = SSL.SessionID)
WHERE LockType = 'Row'
AND UPPER(ObjectName) = UPPER('$CURRENT$TABLE$NAME$')

we get a result if we do this within edbManager. But if we do this right after the user gets the exception on client side, of course only with user permission, we don't get a result.

Is this normal? How can we get this information without admin-rights on database?

Yusuf Zorlu
MicrotronX

So, how can we show on user side, that current row is locked by other user?
There must be a functionality in elevatedb .. i don't think that we have to write our own code on

onEdit: insert into locks table
onPost: delete form locks table

??

Yusuf Zorlu
MicrotronX

Yusuf,

<< Is this normal? How can we get this information without admin-rights on database? >>

You can't - as indicated in the manual, querying these tables requires admin privileges (the calling user must be granted the Administrators role).

Tim Young
Elevate Software
www.elevatesoft.com

<<
You can't - as indicated in the manual, querying these tables requires admin privileges (the calling user must be granted the Administrators role).
>>

And how do you show your users that another user with name / IP / computer is currently editing this record?

Yusuf Zorlu
MicrotronX

Yusuf

From the manual

<<This table reflects all locks currently acquired by all of the sessions that are present on the ElevateDB
server that the current session is logged in to. The current user must be granted the system-defined
Administrators role in order to view this table. Please see the User Security topic for more information.>>


If my interpretation is good you just need to be a bit inventive. A small function which creates its own TEDBSession, TEDBDatabase and TEDBQuery should do the job. Create the components in code, login as an administrator, get the info, stuff into result, free the components.

The biggest difficulty I can see is obfusticating the admin password.

Roy Lambert

Roy Lambert wrote:

<<If my interpretation is good you just need to be a bit inventive. A small function which creates its own TEDBSession, TEDBDatabase and TEDBQuery should do the job. Create the components in code, login as an administrator, get the info, stuff into result, free the components.

The biggest difficulty I can see is obfusticating the admin password.

Roy Lambert>>

Hi Roy, yes the problem is that different customers have different passwords for their "Admin accounts" ... and this would need that the client-configuration needs not only a client password, also the admin-password needs to be saved on client side. Make no sense to me.
I think we need a functionality in ElevateDB where the server sends back the locking users details to the client, where we can show it somehow. This should be a basic functionality of DB-Servers ... hit me if i'm wrong!

>> Tim, is there anything planned?

Yusuf Zorlu
MicrotronX

Yusuf Zorlu wrote:

> different customers have different passwords for their "Admin accounts"

Note the requirement is for an account with the administrator role, not the "admin account". You can create another account for this purpose and give it just that role.

It does strike me that a new role for just this purpose would make sense though.

--

Matthew Jones

Yusuf


1.
I agree with Matthew.

2.
I've seen this requirement posted here a few times, I've also had it asked of me when I was in a corporate role. My guess 99+% of the time its not needed.

Firstly - edits should be kept short and people shouldn't start editing a record and wander off to lunch.
Secondly - apart from in a small organisation the fact that Fred in accounts (way over there) has the record locked doesn't help
Thirdly - it often doesn't matter to work flow if person B has to wait until person A has unlocked the record sometime in the next hour or two
Fourthly - sometimes the record HAS to stay locked while a problem is sorted out

Question to be asked is "what is going to happen when they find out who locked the record?"

If its that important mandate that they create a WHOHASWHATLOCKED account with admin privileges. My bet is that its something they've been told is a good idea, or think is a good idea but haven't thought things through. If its vitally important then yes, as you suggested, implement your own monitoring system and wait for complaints about performance.

Roy Lambert

Hi Roy,

1. i agree with matthew, too and will force our server.exe to create an internal admin-account for this

2. we have customers working on terminalservers with more than 80 users at the same time in server-farms. Mostly logistics companies doing something within orders, two or more people can work at the same time with same positions so yes we need a mechanism to inform user that his collegue in another country is currently locking this position so they can get in touch with each other ...


I hoped that we have something from ElevateDB available here (as it was with advantagedatabaseserver), but now we use 1.) to solve our issue.

Yusuf Zorlu
MicrotronX

Yusuf

>1. i agree with matthew, too and will force our server.exe to create an internal admin-account for this

That sounds like you're modifying the server code - if so why not build something in there?

>2. we have customers working on terminalservers with more than 80 users at the same time in server-farms. Mostly logistics companies doing something within orders, two or more people can work at the same time with same positions so yes we need a mechanism to inform user that his collegue in another country is currently locking this position so they can get in touch with each other ...

I'm ancient and cynical - in theory its a good idea but I wonder how often practice and theory coincide.

At least, as you say, you have a solution.

Roy