Field Update

[born2prazeHim]

I have two fields in a table, if one field contains XX info the other field
will contain OO, I would like a string to automatically populate the second
field once the first field is entered.

 

[Klatuu]

Where do you want to do this?
Is is actually OO to XX or can it be other values?
Please provide some details so we can give you the correct answer.
You don't have to provide real values, just some examples.

 

[born2prazeHim]

one field has classRate and the other field has NEC if classRate is PS or PN,
NEC is 1111; if classRate is any other NEC is 2222

 

[Theomach]

This shouldn't really be under this category as it isn't really code.

Yiou need to set the ControlSource of NEC to this:

=IIF([classRate] = "PS" or [classRate] = "PN",1111,2222)

Be sure to have the actual name of the control where I have classRate.

HTH

one field has classRate and the other field has NEC if classRate is PS or PN,
NEC is 1111; if classRate is any other NEC is 2222

Where do you want to do this?
Is is actually OO to XX or can it be other values?

[quoted text clipped - 4 lines]

 

[fredg]

one field has classRate and the other field has NEC if classRate is PS or PN,
NEC is 1111; if classRate is any other NEC is 2222

So why do you have to have this information stored in the table at
all?
If the value in NEC is derived from the value in ClassRate there is no
reason to store any data in NEC. You can delete that field from your
table.

Then, anytime you need to know what NEC is, you can use a query:
NEC:IIf([ClassRate] = "PS" or [ClassRate] = "PN",1111,2222)

Or, if needed on a form or in a report, using an unbound control:
=IIf([ClassRate] = "PS" or [ClassRate] = "PN",1111,2222)

Regardless of where you do this, do not store this NEC value. It's
superfluous.

 

[Klatuu]

I'm with fredg on this. There is no reason to store NEC. It qualifies as a
calculated value. That is, the value can be determined by values in other
fields, so to store it would break one of the basic rules of data
normalization.

 

[Klatuu]

1. This is an appropriate group
2. Although technically correct in your calculation, it is a calculated
value and should not be stored at all.
--
Dave Hargis, Microsoft Access MVP

This shouldn't really be under this category as it isn't really code.

Yiou need to set the ControlSource of NEC to this:

=IIF([classRate] = "PS" or [classRate] = "PN",1111,2222)

Be sure to have the actual name of the control where I have classRate.

HTH

one field has classRate and the other field has NEC if classRate is PS or PN,
NEC is 1111; if classRate is any other NEC is 2222

Where do you want to do this?
Is is actually OO to XX or can it be other values?

[quoted text clipped - 4 lines]

will contain OO, I would like a string to automatically populate the second
field once the first field is entered.

 

[born2prazeHim]

Okay the main field has for example PS1(XX) but the NEC value generates only
from the first two characters, can it be identified by PS*****

one field has classRate and the other field has NEC if classRate is PS or PN,
NEC is 1111; if classRate is any other NEC is 2222

So why do you have to have this information stored in the table at
all?
If the value in NEC is derived from the value in ClassRate there is no
reason to store any data in NEC. You can delete that field from your
table.

Then, anytime you need to know what NEC is, you can use a query:
NEC:IIf([ClassRate] = "PS" or [ClassRate] = "PN",1111,2222)

Or, if needed on a form or in a report, using an unbound control:
=IIf([ClassRate] = "PS" or [ClassRate] = "PN",1111,2222)

Regardless of where you do this, do not store this NEC value. It's
superfluous.

 

[Theomach via AccessMonster.com]

I don't remember saying that it should be stored in the database. My
statement was to make the ControlSource be the calculation. This would make
it an unbound field and not stored anywhere. So neener-nanner. LOL

1. This is an appropriate group
2. Although technically correct in your calculation, it is a calculated
value and should not be stored at all.

This shouldn't really be under this category as it isn't really code.

[quoted text clipped - 14 lines]