| DTFSTAMP stamps a database with the date and time the programming was last changed.
|
| As everyone knows, just opening a database changes its date and time, so
there is no way to know when the design of a database was last modified. The
DTFSTAMP program provides a way of knowing when the programming in a database
has been changed. |
| It works because you put a special string in the programming and it "comes
through the back door" to change this string, but only if you have actually
changed the programming in the database. If you haven't changed the programming,
the program does nothing. That is, it only changes the date and time if you
have changed the programming since you last stamped the DTF file.
|
| The string you entered can be part of a message that can display
the current version of the database to the user, or it could be in a remark
(if you're using Q&A 5). The string is in the form DATABASE DATE & TIME,
followed by a space where the date and time will be stamped.
|
| Your programming could display a message like this: CUSTOMER DATABASE DATE & TIME:21 APR, 2002 10:32AM.
|
| Furthermore, DTFSTAMP has hooks to support automatic delivery of modified
databases to satellite locations or clients. For example, you can easily write a BAT file to stamp each
database and then copy those that have actually changed (since you last stamped them) to a holding area to be delivered
to a satellite location, put into production, or delivered to a client via ftp or pcAnywhere.
|
| If you're using DTFWIN, you can have menu choices, perhaps under "Help", that display the versions of
your databases when selected by the user. |
| But such a menu choice isn't really needed, as the DTFWIN program has been
modified to use this information on startup to transparently verify that all
databases are the correction version. This way you can be sure
that the correct version of all databases have been installed. |