Form Entries

  • Thread starter Thread starter Sondra
  • Start date Start date
S

Sondra

I have created a form that a user enters the following
data:

SOPNumber
SOPVersion
SOPTitle
SOPLevel
SOPSubContract

As I want to keep track of each version of the SOP, the
user is currently re-typing the 5 fields each time a new
version comes in; however in most instances the only item
that changes is the version.

Is there a way for the user to enter the SOPNumber and
have the other fields fill in from the previous entry for
that SOPNumber and then enter a new SOPVersion?

I have tried a ComboBox, but that changes the current
record that fills in the fields.

Basically, I want to replicate the fields as entered by
the query of the SOPNumber and then add a SOPVersion to
the new data.

Complicated but hopefully someone can advise me.

Thanks in advance.
 
Basically, I want to replicate the fields as entered by
the query of the SOPNumber and then add a SOPVersion to
the new data.

It sounds like you have a one-to-many relationship between an SOP and
multiple Versions of that SOP. A Form with a Subform based on two
tables in a one to many relationship might be the best bet.

John W. Vinson[MVP]
 
-----Original Message-----


It sounds like you have a one-to-many relationship between an SOP and
multiple Versions of that SOP. A Form with a Subform based on two
tables in a one to many relationship might be the best bet.

John W. Vinson[MVP]

It is in one table. No one to many relationship. One
table that just keeps growing. I am thinking there is no
way to do what I'm wanting.

SOPNumber 1
SOPTitle Whatever
SOPVersion 1.0

SOPNumber 1
SOPTitle Whatever
SOPVersion 2.0

SOPNumber 2
SOPTile Whatever
SOPVersion 3.0

etc. as new versions are introduced.
 
It is in one table. No one to many relationship. One
table that just keeps growing. I am thinking there is no
way to do what I'm wanting.

Well, I'm suggesting that - IN THE REAL WORLD - it *is* a one to many
relationship: you have one SOP with four constant fields, and for each
SOP you have many versions. It might be nice if your database
structure in fact modeled the real world situation! It may be that I'm
not understanding your real world structure.

That said, you *can* do what you're asking (which might not be what
you're wanting...) If you have a Combo Box based on the SOPNumber,
with the four constant fields in its row source query, you can put
code in the combo's AfterUpdate event:

Private Sub cboSOPNumber_AfterUpdate()
Me!SOPVersion = cboSOPNumber.Column(1) ' second column, zero based
Me!SOPTitle = cboSOPNumber.Column(2)
Me!SOPLevel = cboSOPNumber.Column(3)
Me!SOPSubContract = cboSOPNumber.Column(4)
End Sub


John W. Vinson[MVP]
 
-----Original Message-----


Well, I'm suggesting that - IN THE REAL WORLD - it *is* a one to many
relationship: you have one SOP with four constant fields, and for each
SOP you have many versions. It might be nice if your database
structure in fact modeled the real world situation! It may be that I'm
not understanding your real world structure.

That said, you *can* do what you're asking (which might not be what
you're wanting...) If you have a Combo Box based on the SOPNumber,
with the four constant fields in its row source query, you can put
code in the combo's AfterUpdate event:

Private Sub cboSOPNumber_AfterUpdate()
Me!SOPVersion = cboSOPNumber.Column(1) ' second column, zero based
Me!SOPTitle = cboSOPNumber.Column(2)
Me!SOPLevel = cboSOPNumber.Column(3)
Me!SOPSubContract = cboSOPNumber.Column(4)
End Sub


John W. Vinson[MVP]
.
Thanks for your help. After I read your first post I
realized that I wasn't in the real world. I have now
modified the database to be multiple tables (as needed)
with one to many relationships and its working great.

Thanks.
 
Thanks for your help. After I read your first post I
realized that I wasn't in the real world. I have now
modified the database to be multiple tables (as needed)
with one to many relationships and its working great.

Thanks.

<grin> I'm delighted to hear it.


John W. Vinson[MVP]
 
Back
Top