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.