Ed Leafe wrote: > On Dec 29, 2006, at 5:29 PM, johnf wrote: > >> Thanks Ed but I have an add on question. Memento is used to check >> the local >> dataset (data cursor) but what are we doing to check the SQL data >> on the back >> end? ie. If a user is about to update the database and someone >> has changed >> the backend data. What happens? Some of the SQL engines will >> return a >> record status as dirty. > > That of course is engine-dependent. If the engine disallows the > save, a DBQueryException will be raised. It is up to the developer to > handle that in the bizobj.
I think there is a generic way of dealing with what John is talking about. I haven't seen anything like VFP's WhereType - did I miss it? Here is how I described VFP's behavior <quote http://fox.wikis.com/wc.dll?Wiki~VfpViews~VFP> WhereClause: I am not sure how this affects local tables. Docs say it doesn’t, but they don’t say how local tables are handled. This is how you contend with multi user collisions. A WhereClause is constructed that tries to identify the record by a set of fields and the original values of those fields. If the fields were dirtied by modifications to the view, those changes affect the Field=value part, and maybe the WhereClause. If someone else changes the data on the server, the record that is being edited will not be found, and the UPDATE command will not update any records. The server will somehow respond with the number of record effected (0) and that is how a collision is detected. WhereType = 1 – Key: what ever fields are marked as key (regardless of primary index settings) are paired up with their original value. If there are multiple fields marked as key, then it is a compound key, and the expressions are ANDed. Ex: WHERE cInvno=”123” AND cItem = “1”. As long as the key has not been changed, changes to this record by other users will just be overwritten. (no locking) WhereType = 2 – key and updateable: a big honken where clause is constructed out of anything marked as key or updateable. WHERE pkPers =123 AND cFName = “Carl” and cLName = “Karsten” and cAdd1 = “8345 Newland Av” AND …. If someone else changes any of these fields, the WhereClause will not be true anymore, and so no records will be updated. WhereType = 3 – Key and Modified: a smaller WhereClause is constructed out of the PK and any fields that were modified in the view. (It still uses the original values.) UPDATE Pers SET cCity = “Niles” WHERE pkPers =123 AND cCity = “Nils” (note the wrong spelling). In this case, other fields could have been changed, but as long as the cCity field is still incorrect, the update will happen. WhereType = 4 - Key and TimeStamp: This assumes that the back end has a ‘last modified field’. When the query was executed, a Date Time (either current server time or the last modified value of the record) is included (call it xDateTime). The WhereClause then uses this value: WHERE pkPers =123 AND LastModified = xDateTime. If the record had been modified after xDateTime was set, then this will fale. This has a similar affect as 2, only it is a much smaller where clause, and it includes any field in the record, not just the updateable ones. </quote> _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-dev
