H
Håvard Danielsen
Guest
andrew.may wrote: if so, does anyone know if the frameworks have been changed to be partition-safe (or are partitions just incompatible with ADM framework). Mike Fechner wrote Ok. ADM2 RowIdent's do also contain ROWID values. -------------- ADM2 uses rowids as record identifiers when updating and when batching. The update is protected by the optimistic locking checking, so it is unlikely to cause any damage if the rowids have been changed (due to a move). However the optimistic lock check is also using rowids to find the current record(s)… (see fixes below) Over the decades ADM2 has been extended with request methods that use keys instead of rowids and as of current only batching still relies on rowids. All other requests have been refactored to use key based methods. Note that the older the ADM2 version is the more likely it is that rowids are used internally. In older versions visual objects also use rowids (concatenated string of rowids) as the identifier to their data sources. (The only practical way to avoid this is to upgrade) This means that existing customer code may still use the old rowid based methods. ADM2 11.4 will have the following fixes to make updates work transparently over a partitioned database. Problem: Errors on subsequent saves after an update that moved the record to another partition. Fix: The rowids that identifies the database records of an SDO row are refreshed on every save. Problem: Record does not exist or is deleted error on save if someone else moved the records (in the SDO join) after you read it. Fix: The optimistic locking check will do a second find using keys if the rowid fails in a partitioned database in order to give the correct error. (changed or really deleted) No plans to fix adm2 batching to use true keys. As mentioned the visual objects do not depend on rowids in recent versions. The DataView is a “rowid-free” alternative that can replace existing SDO and SBO data-sources also if they are batching (you have to write your own backend though…) What you may have to fix yourself The refreshRow method is one known case that still uses rowids internally and that does not have an alternative key based method. This is not used by the framework itself, but it is commonly used to refresh a single row for example in cases where the update is done from a different object and data-source. We did add an getUseKeyOnRefresh() function in some version 11 release that can be overridden to return true. Note that this is not backed by a true property, so it has to be overridden in code (cannot be changed in Dynamics repository).
Continue reading...
Continue reading...