You are already thinking along the lines that I am wanting to take these
tables and forms.
The training form is actually just a summary of the additional forms that
will contain the greater detail of each phase/step in training.
Essentially, the tables look like this:
Trg-BFT; Trg-UPT1,... There are 5 phases/tables total with the summary
table (TrgProg) as an extra and sub to the main form/table. To complete
each phase, there are varying requirements. An example is that Trg-BFT has
5 requirements that must be met. When requirement 5 is completed, then the
AfterUpdate event will send the current date to TrgProg in its respective
field (and hopefully for the correct person). With all the code existing in
the forms, it should work out to going to the correct person the moment that
the subform is updated.
But, you are essentially saying to make a table that already has the
sequence there? Is that right?
Jason Lopez
"John W. Vinson" <jvinson@STOP_SPAM.WysardOfInfo.com> wrote in message
news:(E-Mail Removed)...
> On Fri, 13 Jul 2007 14:01:36 -0400, "Jason Lopez"
> <(E-Mail Removed)> wrote:
>
>>I am trying to put some VB code in as a form of validation on an Access
>>form. What I am looking for is essentially the ability to check 5
>>different
>>controls for data contained within. The controls are for dates that are
>>tied to a table that records the training completion dates. In an effort
>>to
>>avoid out-of-sequence training or edits to the data after the initial
>>entry,
>>I am wanting to put in this code. It essentially enables the field for
>>putting in data but disables subsequent fields to maintain the training
>>sequence.
>>
>>This is what I have so far (and it is *long* down below). At this point,
>>I
>>cannot seem to get it to work right. It immediately locks down the form
>>when there are dates in the fields. The only other thing that I can think
>>of is to have this same VB code for the BeforeUpdate, On_Click and
>>AfterUpdate events.
>
> Stepping back a bit... if you have one *field* for each kind of date,
> you're
> perhaps limiting your flexibility in terms of table design. Suppose you
> want
> to add a *sixth* type of training? You'll need to restructure your table,
> rewrite all your queries, redesign your forms and reports, rewrite all
> your
> code... ouch!
>
> Could you instead consider a four-table solution:
>
> Employees
> EmployeeID <Primery Key>
> LastName
> FirstName
> <other bio data>
>
> Courses
> CourseID <Primary Key>
> Description
> <other info about the training>
>
> Schedule
> SeqNo <what order the courses must be taken>
> CourseID <which course>
> <other info, e.g. comments, valid reasons to take a course out of order
> or
> skip it, etc.>
>
> Trainings
> TrainingID
> EmployeeID
> CourseID
> CompletionDate
> <comments, pass/fail, retakes, etc.>
>
> You could then simply *add a record* to the Trainings table; the form's
> beforeupdate event could be used to ensure that you're not entering a
> course
> out of sequence; it would make reporting MUCH easier.
>
> John W. Vinson [MVP]
|