+1 vote

Hi again dear community^^,

I have a serverscript that is run by the user "admin" through the scheduleradmin.exe and that create a company record :

var ec = Database.OpenEditContext(ntComp, 0, false);

                Database.UpdateFields(ec, 0, VarArrayOf(["NAME"]), VarArrayOf([compName])); 

                Database.CommitChanges(ec, true);

                Database.Log("created : " + ds.FieldByName("K_COMPANY").AsInteger);

but right after my code is executed within the lock timeout delay, if I go with my own user on the created company, I have the currently locked record error.

Is that normal?

asked in Efficy/ Client side by (986 points)

2 Answers

+1 vote
Best answer

You can immediately release the lock with the following method:

Database.ReleaseRecord(ContextHandle) : Integer

To be used before the closing of the context, an example below

var editHandle = Database.openEditContext(entity, key);
try {
    // Do something
    Database.CommitChanges(editHandle false);
} finally {
    if (editHandle) {

This method is available from version 10.2

answered by (7.2k points)
edited by
Kristof, is it ok to directly remove the records in SYS_LOCKS when there was a lot of records locked by a ScheduleScript ?
This feels like a boobytrap question...
Of course you can do a truncate of the table, but this will also remove useful locks. A selective delete could delete all locks from the admin user. But why are the locks staying in that table? Did you try using the releaseRecord?
cannot use it the customer is still in Efficy 2014
Then go for a selective delete statement at the last record.
+2 votes

Hi Louis,

the lock is triggered by the following:

Database.CommitChanges(ec, true);

If you change this to the following:

Database.CommitChanges(ec, false);

Then there shouldn't be a lock anymore.

Best regards,

answered by (352 points)
Tested and it works fine. Thanks
In my whole career at Efficy, I never had to set that boolean value "refresh" of CommitChanges to true. So, always provide it as false, as this is best for performance as well.
Actually, I cannot believe it worked. The method below should release the lock, not the commit changes.

Database.ReleaseRecord(ContextHandle) : Integer
Hi Kristof,

Is this a new function? Im very curious when this was implemented.


Yes, it's been added since Efficy 10.2
I forgot to say it returns the key of the user that locked the record, but in case of workflow, that is typically the current user
Allright thats nice, thank you!
1,226 questions
1,495 answers
328 users