Welcome to the SQLitening support forums!
Started by John Lever, September 18, 2009, 07:56:27 AM
QuoteI put a temp 'lock' on the record.
Quote from: TechSupport on September 21, 2009, 08:39:40 AMI have often wondered what the best approach to locking would be in an SQL environment. Here is something that has been floating around my head for a while... it saves the user from having to use physical lock files or bytes in a record.SQLitening is already client/server so we have no problem sending requests to the server application. The application could send a message to the server prior to initiating an edit on a record. The message could be anything that signifies that it is about to edit a particular record (for example, EDIT_CUSTNUM=12324). When the server recieves this text it searches an internal array or linked list for the same text and, if found, then we know that another application has already requested to edit the record so the server sends back a message to the user saying that the record is in use. The user then simply needs to abort initiating any edit activity on that record.If the text does not exist on the server then SQLitening creates the text in an array/linked list and sends back a message to the user saying that it is okay to commence the edit. When the user finishes editing then it sends another special message to the server to remove the previous message from the array/linked list.Seems pretty simple, right? Other information could be stored with the text such as user id of the person doing the editing and maybe even the socket so that if after a certain number of pings it becomes evident that the connection is down then SQLitening can remove any "locks" that that connection may have placed.Anyone see any holes in this idea? Hopefully I have transferred my thoughts clearly from my brain to the keyboard.