Any reason why a calc'ed control doesn't actually have an "update" event?

[ineloquucius]

If I put a calculated control on my form, I don't seem to have any way of pushing its changes to a field when those changes happen. Access can be downright infuriating at times. I've spent days just putting together a simple invoicing application.

My form is not based on a query like the northwind database, because that created such ridiculous and useless behavior with subforms that I couldn't. So now that it is based on a good old fashioned table, when I change a qty or price, the calculated "extended price" (=[qty]*[price]) field visibly changes just fine, but it never has an "after update" or "after change" event. Why would this be? How am I to save these bloody changes to an actual field in a table without using some grossly inelegant code?

 

[RV]

I'm not sure wat your frustration is all 'bout, but could it be that you're not too familiar yet with Access yet
An unbound control indeed does habe an After Update event.
Calculated data is not stored in tables.
If you want to review calculated data outside your form, then start using queries.

RV

 

[ineloquucius]

I'm looking to copy the data within the form

I simply want to copy the qty*price to a field in the underlying table when the unbound, or formula bound control, has changed in response to a qty or price change.

so I change qty from 2 to 4, let us say. The calculated control "extended price" does indeed automatically respond, doubling itself in this example. But when it does, it does not invoke any procedure listed in the afterupdate or afterchange field.

Thanks for your time, incidentally.

 

[RV]

I simply want to copy the qty*price to a field in the underlying table

Again, you don't store calculated data in tables.
Referring to me previous reply.

RV

 

[ineloquucius]

Calculated Data

Never? What if you wanted to run a report based on invoice totals and such? I would have thought that between the two, storage space is generally less costly in time and money than processing. But you say one should never store a datum in a table that is a function of two other data...period? Do I understand that correctly?

Again, I appreciate your help. Obviously I'm no expert at Database theory. Perhaps I should skim through the general practice and theory section a while.

 

[RV]

Never? What if you wanted to run a report based on invoice totals and such? I would have thought that between the two, storage space is generally less costly in time and money than processing. But you say one should never store a datum in a table that is a function of two other data...period? Do I understand that correctly?

Yes, your understanding is correct.
Now of course the are exceptions to this rule none of which apply to your case.
In case you want to run reports, which you normally want if you want to generate iinvoices, you base your report on a query.
Normally you can use the same query as a base for the form.
You add calculations onto your query.

Search the forum or have a look at the sample databases here.
I'm sure there are some sample databases that use similar mechanisms.

RV