S
Sandspirit
I saw this posting and I need the code for the version control. It is
EXACTLY what I have been looking for to maintain a history of changes
for my data. I am tracking documents per officer of companies and most
of the docs need to be updated at various times and I need to capture
the old data. There are various types of controls such as date,
checkboxes, and memos. I am holding things up because I do not have
this code. Take pity on me.. puhlease! I tried contacting the author
but to no avail. ;-(
Also, is there a way to not have to name each field, but to lump them
together by their types( i.e., checkboxes, memo, etc.)?
****2) Version control: Two fields are added to the table:
Version Number and Superceded-By Version Number. This is
especially useful when using a relational-based system.
When you add a record, the Version Number is added. This
is a "current version," which can be an incremented
number. When this item is updated, a new record is added,
but the "old" record is updated by specifying the version
number that invalidated it. Therefore, at any time in
history, you can see what something looked like at a
specific version.
An example might be:
tblData
DataID ThisVer NewVer DataElementID DataItself
1 1 2 1 (date) 1/1/2002
2 1 3 2 (currency 1) $350
3 1 3 (currency 2) $400
4 2 3 1 2/1/2002
5 3 2 $475
6 3 1 3/1/2002
Therefore, version #1 says:
1/1/2002 -> $350 -> $400
Version #2 says:
2/1/2002 -> $350 -> $400
And the latest version (version #3) is:
3/1/2002 -> $475 -> $400
Relationally-based version control. The number of
elements in this case is dynamic (i.e., the number of
fields comprising a record can change), and no data are
ever lost.
Combine this with a fairly complicated cross-tab appended
to a can-change base table that traps changes through a
form and updates this relational listing kinda thing, and
you can pull it off. (Yup, I did this once.)
David Atkins, MCP (original author)
I hope someone can help me,
Sandspirit.
EXACTLY what I have been looking for to maintain a history of changes
for my data. I am tracking documents per officer of companies and most
of the docs need to be updated at various times and I need to capture
the old data. There are various types of controls such as date,
checkboxes, and memos. I am holding things up because I do not have
this code. Take pity on me.. puhlease! I tried contacting the author
but to no avail. ;-(
Also, is there a way to not have to name each field, but to lump them
together by their types( i.e., checkboxes, memo, etc.)?
****2) Version control: Two fields are added to the table:
Version Number and Superceded-By Version Number. This is
especially useful when using a relational-based system.
When you add a record, the Version Number is added. This
is a "current version," which can be an incremented
number. When this item is updated, a new record is added,
but the "old" record is updated by specifying the version
number that invalidated it. Therefore, at any time in
history, you can see what something looked like at a
specific version.
An example might be:
tblData
DataID ThisVer NewVer DataElementID DataItself
1 1 2 1 (date) 1/1/2002
2 1 3 2 (currency 1) $350
3 1 3 (currency 2) $400
4 2 3 1 2/1/2002
5 3 2 $475
6 3 1 3/1/2002
Therefore, version #1 says:
1/1/2002 -> $350 -> $400
Version #2 says:
2/1/2002 -> $350 -> $400
And the latest version (version #3) is:
3/1/2002 -> $475 -> $400
Relationally-based version control. The number of
elements in this case is dynamic (i.e., the number of
fields comprising a record can change), and no data are
ever lost.
Combine this with a fairly complicated cross-tab appended
to a can-change base table that traps changes through a
form and updates this relational listing kinda thing, and
you can pull it off. (Yup, I did this once.)
David Atkins, MCP (original author)
I hope someone can help me,
Sandspirit.