Data entered into form is not shown in Table

[engr_saud1]

Hi ,
i have a data/text field in the table "Current status" . It calculates value using an IIF statement in the Form. But that value is "not appearing " in the table.
Moreover , all the data that is entered using expression builder in respective datafields in the form is " not reflected" in the table. Please help !!!

[Missinglinq]

It is very seldom appropriate to store Calculated Fields; they should simply be re-calculated, as needed, for other Forms, Queries, Reports, etc.

The Expression Builder places the Calculations in the Control Source of a given Textbox. A Control Source can be populated with an Expression, or with the name of the Field the Control is Bound to, but it cannot do both at the same time!

Linq ;0)>

[June7]

Saving a calculated result requires VBA code. However, I don't think necessary to save result in this case.

How is data entered by using expression builder?

If form is bound to data (RecordSource property is set) and controls are bound to fields, entry/edit in controls will pass directly to record in table.

[Missinglinq]

...How is data entered by using expression builder...

The Expression Builder can be called up from the Control Source or Validation Properties, but is normally done from the former, which is the case here, I suspect, which is why there's nothing (as is proper) being saved to the Table.

As I said, I don't believe I've ever had occasion to use it, and actually had to experiment to find out how it worked!

Linq ;0)>

[June7]

I understand calling up the expression builder from those locations but that just creates a calculation and doesn't 'enter data', no different from IIf expression for the CurrentStatus value. Doesn't matter how expression is created (manually or with builder), calculated result does not save to table without VBA code. So I am not sure what the OP was trying to convey.

[orange]

Perhaps you could describe to us WHAT you would like to happen in plain English.
You might research Bound vs Unbound forms to get some insight on how these are meant to work.

Also, reading, understanding and using these ten suggestions could be helpful with your Access activity.
They are basic, but very relevant.

http://www.mvps.org/access/tencommandments.htm

The Ten Commandments of Access:

1) Thou shalt design normalized tables and understand thy fields and relationships before thou dost begin.

2) Thou shalt never allow thy users to see or edit tables directly, but only through forms and thou shalt abhor the use of "Lookup Fields" which art the creation of the Evil One.

3) Thou shalt choose a naming convention and abide by its wisdom and never allow spaces in thy names.

4) Thou shalt write comments in your procedures and explain each variable.

5) Thou shalt understand error handling and use it faithfully in all thy procedures.

6) Thou shalt split thy databases.

7) Thou shalt not use Autonumber if the field is meant to have meaning for thy users.

8) Thou shalt not copy and paste other people's code without at least attempting to understand what it does.

9) Thou shalt not use "SendKeys", "Smart Codes" or "GoTo" (unless the GoTo be part of an OnError process) for these will lead you from the path of righteousness.

10) Thou shalt back-up thy database faithfully, working not on thy Production Database, but on the Prototype Copy, as it is right and good to do.