Re: updating member change date on source files

On 18 May 2012 13:42, rick baird wrote:

What needs to be "solved"? The database close sets the "Last
source update date/time" when the source was [or inconclusively may
have been] updated. Because features of the
[pre]compilers\linker\binder\debuggers\interpreters depend heavily
on the value maintained by the DB, there was [and presumably is
still] no external user interface to change the value.

We've changed the way we mark our code changes which required
updating comment lines in the source members to initialize them for
the new method.

But changing the source programmatically updated the last change
date of the source.

Of course it did. The source *was* changed. :-)

We do not want to recompile but it would be nice to retain the last
changed date on the source members from when the program was actually
last changed (not comments).

So the intent is to deceive any tooling that both references the "Last source update date/time" timestamp and [thus] does not know nor care whether the changes were only to comments.? To such features, any change is a "change". If lines were added for example, then a source debugging utility that depends on the unchanged source [lines; updates, inserts, or deletes] could give incorrect output if ignoring [or having been deceived about] there were changes.

Does the [alluded means to effect change via the] OVRSYSDATE feature also override to give a static time value? If not, because the full stored "Last source update date/time" value includes time [down to the seconds only], I am not sure how much help that would be to help pull off this deception.?

Why would there be any requirement to change the value to
something which is not a reflection of reality? And if the values
are changed [esp. if not by QDBCLOSE], then be sure to understand
the consequences if not also\afterward effecting necessary
recompile et al.

Yes, we understand that it will put the source out of alignment with
the actual objects - this is not of too much concern for now.

So then perhaps only a concern after changes cause things to break ;-) That of course implies that the breakage would be manifest in a way that is obvious; i.e. failure vs merely [perhaps subtle] incorrect output.

Regards, Chuck