Save As Command?

[Yecenia]

We have a form that tracks employee assignments. The same assignment can
change multiple times in one day, but the changes are minimal. Regardless,
each change/version must be saved.

Can I keep each employee one time in a table, show that table in an editable
form, and put a command button that saves the information/record that is
showing to another table?

Help!

 

[Dirk Goldgar]

We have a form that tracks employee assignments. The same assignment can
change multiple times in one day, but the changes are minimal.
Regardless,
each change/version must be saved.

Can I keep each employee one time in a table, show that table in an
editable
form, and put a command button that saves the information/record that is
showing to another table?

If I understand the situation you decribe ...

The static information about the employee, which doesn't change frequently,
should be in one table, maybe called Employees. The assignment information,
which changes frequently, should be in another table (maybe called
Assignments), which is linked to the Employees table by a common key field
(EmployeeID, or some such). There would be a one-to-many relationship
between Employees and Assignments.

As I understand it, you need to preserve the history of changes to each
employee's assignments. Therefore, your Assignments table needs to contain
a date/time field (maybe called WhenAssigned), and you have to do some
special coding on a form to ensure that, rather than modifying an employee's
current assignment record, you create a new one whenever you change the
assignment. Your code might automatically populate that record initially
with the latest values for that employee, so that you only need to update
the fields that have changed.

When that record is saved, you would set the WhenAssigned field to the value
of the function Now(), which gives the current date and time. That way, a
query can pull the latest record for each employee, thus allowing you to
view and report the current assignments.

All of this is quite doable; however, coding to always create new assignment
records rather than modifying existing ones could be a little tricky.

 

[John W. Vinson]

We have a form that tracks employee assignments. The same assignment can
change multiple times in one day, but the changes are minimal. Regardless,
each change/version must be saved.

Can I keep each employee one time in a table, show that table in an editable
form, and put a command button that saves the information/record that is
showing to another table?

Help!

I would do this using two tables - an Employee table related one-to-many to an
EmployeeAssignments table. You'ld have a Form based on Employees and a Subform
based on EMployeeAssignments; when a new assignment is entered simply find the
employee's record on the mainform (using a combo box perhaps), and enter a new
record on the subform.

 

[Yecenia]

If I understand the situation you decribe ...

The static information about the employee, which doesn't change frequently,
should be in one table, maybe called Employees. The assignment information,
which changes frequently, should be in another table (maybe called
Assignments), which is linked to the Employees table by a common key field
(EmployeeID, or some such). There would be a one-to-many relationship
between Employees and Assignments.

As I understand it, you need to preserve the history of changes to each
employee's assignments. Therefore, your Assignments table needs to contain
a date/time field (maybe called WhenAssigned), and you have to do some
special coding on a form to ensure that, rather than modifying an employee's
current assignment record, you create a new one whenever you change the
assignment. Your code might automatically populate that record initially
with the latest values for that employee, so that you only need to update
the fields that have changed.

When that record is saved, you would set the WhenAssigned field to the value
of the function Now(), which gives the current date and time. That way, a
query can pull the latest record for each employee, thus allowing you to
view and report the current assignments.

All of this is quite doable; however, coding to always create new assignment
records rather than modifying existing ones could be a little tricky.

--
Dirk Goldgar, MS Access MVP
www.datagnostics.com

(please reply to the newsgroup)

I do have one table called Employee Details and another table called
Assignment_Log. I have a one to many relationship between the two.

It sounds like I would need to create some sort of coding, but I would not
know where to begin. What suggestions do you have?

 

[Dirk Goldgar]

I do have one table called Employee Details and another table called
Assignment_Log. I have a one to many relationship between the two.

Very good.

It sounds like I would need to create some sort of coding, but I would not
know where to begin. What suggestions do you have?

At this point you should decide how you want to look at and edit the data.
What form or forms do you want, and how do you want them to behave? Since
you intend to keep a history of each employee's assignments, do you want the
form to show all previous assignment details as well as the current one? If
so, a simple main-form/subform arrangement such as John Vinson suggested may
be all you need, with maybe a little code to initialize a new assignment
record by copying data from the most recent previous record.

Alternatively, you could have a form that shows the current details in a
nonupdatable way, and a command button to create a new assignment based on
those details and present it for editing in the same form. Or ... well, you
could set it up lots of ways -- the point is that you need to decide how
*you* want the data to be presented, and how you want the user (whether it's
you or someone else) to be able to work with it.

Once you've decided that, if you can't figure out how to make it happen, we
can help you with the details.