Chris F Clark schreef: > If you have a fixed database, and you do two selects which specify the > same sets of fields to be selected and the same keys to select records > with, one expects the two selects to return the same values.
When your "fixed" means read-only, or (fully) locked, then yes. Modern databases also have modes without locks, so without special attention (like maybe your "fixed") the two selects do not necessarily return the same set of records. > Further, if you > do an update, you expect certain fields of certain records to change > (and be reflected in subsequent selects). Doesn't your "fixed" block updates? > However, therein lies the rub, if you do a select on some records, and > then an update that changes those records, the records you have from > the select have either changed or show outdated values. Not necessarily outdated: values can be fixed in time for a purpose. Example: calculating interest is done once per day, but the whole process takes more than a day. Some systems implemented a lock plus requery just before the update, to check for unacceptable changes in the stored data; this to prevent having to keep locks while waiting. > If there is > some way to refer to the records you first selected before the update, > then you have an aliasing problem, but maybe one can't do that. One > could also have an aliasing problem, if one were allowed to do two > updates simultaneously, so that one update could changed records in > the middle of the other changing the records. Some databases allow you to travel back in time: run this query on the data of 1 year ago. All previous values are kept "behind" the current value. -- Affijn, Ruud "Gewoon is een tijger." -- http://mail.python.org/mailman/listinfo/python-list
