Can a calculated field be saved permanently

[ChrisO]

Well, just from the point that I dislike the words never and always…

If we have a database that can be used to better productively with bound forms as a user interface then use them.

If we have a database where the interface could be better for the user with unbound forms then write whatever is necessary to produce that interface.

The user wants it easy and accurate, that’s their problem. The user does not care how it works, that’s our problem. The difference between the two is money and that’s everybody’s problem.

The aim, as I see it, is to produce the best bang for the buck.

I do not see the need for the words never and always, it simply depends on the money available.

Edit:
I’ll post an example of what I’m talking about.
Some imagination is required but the principle should be obvious.
Imagine…
It’s a job costing Gantt chart. The bars can be moved and changed in length.
The costs relating to the job would be entered on mouse right click.
Those costs could be unit hire costs or ongoing labour costs across overtime, weekends and public holidays.
If the bar is positioned relative to a timeline then, on left mouse up, the job can be re-costed and saved.

The real stretch of imagination here is; how would we bind that type of user interface?

If imagination was not used then Stephen Lebans site would not exist
There is no right way to use Access, there is only imagination and money.

Chris.

 

[VilaRestal]

I agree that herb's suggestion was bad but not because it involved using an unbound control. That bit of it was fine and is a perfectly ok way to go. Maybe not the best way but that's debatable: it does have advantages. The bad bit was updating the field by executing an update. As Pat points out that would cause problems. It should be Me!Field =

 

[gemma-the-husky]

I think when designing an interface, you need to be very careful to try and adhere to accepted standards.

a windows form generally has a minimize, maximise and close button. Ok, with some access froms, you may not want to allow the first two - and occasionally you might not want a close button. maybe the "close" action NEEDS to run some code, so you have to disable the close button, and provide your own - but this will/might be disconcerting to a user, who generally expects to see a close button

again, in most systems. users can have multiple windows open. So a "directed" control system that forces users to open just a single form at a time may certainly be considered a bit "primitive" and unfriendly. On the other hand, the more windows that are open, the more the developer has tothink about unexpected interactions between those forms

now, in the same way any regular users of an access interface will expect that records get saved in a number of ways

- when closing a form, when navigating to a new record, by clicking a record selector, even by using a menu or keyboard short cut.
- but generally NOT by having to click a "save me" button

- so to try and change this default accepted behaviour is hard for two reasons

- first, it is difficult to disable every possible "normal" save action
- second, it needs a lot of more complex coding problems

(eg - a bound field automatically knows how much data it can hold. an unbound string will allow you to enter too much data, that might give a 3265 error (i think, maybe it is a different error number) when you try to assign to a field in a recordset)

- (and third, it is not the interface a user generally expects)

Now, in some cases we do need to use unbound forms to control data, and maybe provide a "save" or some other button to commit the item.

But we do need to accept that this is unusual. It changes the normal user interface, and there does need to be a cogent design reason for doing this.

just my personal thoughts.


----
and in terms of this thread, which was about saving calculated controls - I am sure we all save some data which could be calcluated from first principles.

it is generally a trade off between a need to have data permanently available, and the work that would be involved in calculating the value from base data. even then some info that could be calculated relatively easily might still get stored as a calcluated value.

maybe the invoice total, sales tax/vat rate on an invoice, and the sales tax calculation itself are cases in point. You COULD calculate these, by adding together invoice lines. you could even get the prices on invoice lines by drilling back to pricing records - but i doubt if many of us actually do that in practice.