× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



The condition of /changed/ must be understood, for save of database files, to be generally distinct from the /last changed date-time/. When the object is changed, whether only the data or the objects themselves [*FILE or *MEM] have been changed, the file object becomes eligible for /save changed object/ processing, to include any changed members or all members when the file was changed. Whether the database *FILE object is updated with a new[er] changed date-time is moot, with regard to the feature of "save changed"; i.e. the object is still eligible for "save changed" processing, irrespective of any newer recorded as last changed date-time.

When a library is saved using the the SAVLIB UPDHST(*YES), the list of /changed [since last full-saved]/ objects for that library, is then discarded. Given a file.mbr with data changed three separate times, with three separate open & close even, the *FILE may _validly_ reflect only the first data change peformed since that last save library request [with updhst(*yes)]. The way to infer the member.data was changed since that date-time recorded in the *FILE, is to defer to the *MEM objects themselves.

For database files with changed data, since [effectively] it is the *MEM object that contains the data, that is the object tracking the data changes and thus is the object that is saved. However to enable the restore, both conceptually and literally, a copy of the *FILE is saved along with the list of any changed members; i.e. even if only one member changes, a copy of the *FILE must saved as well.

So.... The role of last changed date-time for the database *FILE object, for changes to data, need only be indicative of the first change for which it became eligible for the function of save changed objects. That is really done only because it is helpful to visualize that the object will be saved -- for lack of any other interface to show that. Again, the *FILE object is merely a container, a directory, of the members which actually hold the data. If every row insert, update, or delete was tracked across every member of any one file, the "changed date-time" of the *FILE would not only be updated way more often than necessary, those few bytes of storage would become a single point of contention such that for some high volume activity against only the data, would have the *FILE object remain in memory as well as the data. The database *FILE as a mere container need not remain in memory for database I/O, but constantly updating to indicate that the *FILE was /changed/, would require that. The /dataspace/ is of course in memory when data is changing, and it is where the tracking of /last changed/ information is performed -- that dataspace information is manifest via the member object, via an interface like DSPFD for *MBR information [thus previously, /effectively/, alluding to the member as doing that].

Although for source members there is a distinct 'last source change date-time', there is no similar distinct tracking of member data change, separate from any other member changes. That is, a change to the *FILE that must impact all members [versus one member like rnmm, chgpfm], will manifest the /same/ date-time for that change of both the file and its members. As was already noted, restore, chgobjown, grt/rvk, move, chgxxx, et al. will all effect a consistent change date-time, but one can not infer the data was last changed then. That granularity for data changes, is within the realm of journaling.

Regards, Chuck

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.