Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » ElevateDB Technical Support » Support Forums » ElevateDB General » View Thread |
Messages 1 to 6 of 6 total |
Locking and Concurency question |
Fri, Mar 15 2013 6:19 AM | Permanent Link |
Beni | Hello,
I have an application using ElevateDB database. At this moment I'm using the pessimistic row locking protocol. To test it I started 2 different instances of the same application, loaded a list of records using a query. I did manage to handle the situation when both applications are trying to edit the same record. How can I handle the situation when one of the applications is done with the editing and the other application still has the old properties for the record? Is there any way to find out if the record is out of date? The documentation does mention something about the EDB_ERROR_ROWMODIFIED but this happens only when the locking is optimistic. Thanks, Beni. |
Fri, Mar 15 2013 11:07 AM | Permanent Link |
Fernando Dias Team Elevate | Beni,
Having a sensitive result set is the first step. If you want to be sure that you are looking at 'live' data you must ensure that your queries are Sensitive. If you are using TEDBTable then it's 'live' data for sure, if it's TEDBQuery, then you have to set TEDBQuery.RequestSensitive to TRUE and follow the set of rules that allow your queries to return a sensitive result set (there's information about what rules in the manual, or if you like we can guide you). After that, both TEDBQuery and TEDBTable have a Refresh method that as you can guess refreshes the data you are seeing. -- Fernando Dias [Team Elevate] |
Fri, Mar 15 2013 11:43 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | Beni
I'm not sure what it is you want to achieve here. With pessimistic row locking ElevateDB handles the situation quite well by itself. Try running two instances of EDBManager, run the same query in each making sure to ask for a sensitive result set. Start editing in one, switch to the other and it tells you that you're not allowed to edit that row --------------------------- ElevateDB Manager --------------------------- ElevateDB Error #1005 Cannot lock the row in the table Test. --------------------------- OK --------------------------- Once the original edit is posted trying to enter data into that column for that row results in the data being refreshed. If what you want is for the second instance to show the new data as soon as the first has posted it then you'll have to implement some sort of custom messaging to let all instances know that the data is changed and, as Fernando suggests call Refresh. If its not possible / convenient to implement some form of messaging then all you can do is have a timer and refresh the tables / queries at intervals. Roy Lambert [Team Elevate] |
Fri, Mar 15 2013 2:45 PM | Permanent Link |
Beni | Thanks for your answers!
I just notice something I didn’t see until now! Yes, I’m using sensitive queries and I handled the situation when 2 applications were trying to edit the same record (#1005 error code). My problem was related to a record changed in one application and already loaded in another application. I just notice that when you go into edit mode the record (in the second application) is updated (refreshed) silently which is interesting … but is this the right solution? I will have to explain to my users that what they see may change when they are trying to change it. Wouldn’t be a better solution to raise an error when the user tries to change an out of date record – when the locking is attempted? I made something similar “manually” (with another database management system): kept a table with last change date for the records (record primary key, record type and datetime when the last time the record was saved) and every time when the user was trying to edit a record the last change date for that record in the local session was compared with the last change date from the database. For sure such a mechanism can be more efficient when it is implemented in the database engine. ... just a suggestion/idea ... and again, thanks for your answers, Beni. |
Fri, Mar 15 2013 3:30 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Beni,
<< I just notice something I didn’t see until now! Yes, I’m using sensitive queries and I handled the situation when 2 applications were trying to edit the same record (#1005 error code). My problem was related to a record changed in one application and already loaded in another application. I just notice that when you go into edit mode the record (in the second application) is updated (refreshed) silently which is interesting … but is this the right solution? I will have to explain to my users that what they see may change when they are trying to change it. Wouldn’t be a better solution to raise an error when the user tries to change an out of date record – when the locking is attempted? >> This is the property that you want (TEDBSession): http://www.elevatesoft.com/manual?action=viewprop&id=edb2&product=delphi&version=7&comp=TEDBSession&prop=RecordChangeDetection If you set it to True (default is False), then an Edit will raise a "Row modified" exception that you can trap in an OnEditError event handler and use to notify the user. You can then just retry the operation and it will continue on as normal. If you have any other questions, please let me know. Tim Young Elevate Software www.elevatesoft.com |
Fri, Mar 15 2013 3:37 PM | Permanent Link |
Beni | "Tim Young [Elevate Software]" wrote:
Beni, << I just notice something I didn’t see until now! Yes, I’m using sensitive queries and I handled the situation when 2 applications were trying to edit the same record (#1005 error code). My problem was related to a record changed in one application and already loaded in another application. I just notice that when you go into edit mode the record (in the second application) is updated (refreshed) silently which is interesting … but is this the right solution? I will have to explain to my users that what they see may change when they are trying to change it. Wouldn’t be a better solution to raise an error when the user tries to change an out of date record – when the locking is attempted? >> This is the property that you want (TEDBSession): http://www.elevatesoft.com/manual?action=viewprop&id=edb2&product=delphi&version=7&comp=TEDBSession&prop=RecordChangeDetection If you set it to True (default is False), then an Edit will raise a "Row modified" exception that you can trap in an OnEditError event handler and use to notify the user. You can then just retry the operation and it will continue on as normal. If you have any other questions, please let me know. Tim Young Elevate Software www.elevatesoft.com GREAT!!!! Thanks a lot!!!! |
This web page was last updated on Monday, April 29, 2024 at 05:23 AM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |