I prefer to put this kind of logic in the application, rather than in the
tables. You can use a forms BeforeUpdate event to check that values are
appropriate, and if not, you can display a meaningful error message and then
cancel the update.
When you put the logic in the columns properties, you generally get an error
message that is very generic.
You can't do this in a Table, but you can use the Form's BeforeUpdate event to
detect this condition. I'm not at all sure what you're summing over but you
should be able to use DSum() in the Form's event.
One possible problem if you're using a form and subform is that the main form
record is saved to disk when you first set focus to the subform, and each
subform record is likewise saved to disk when you move to the next - so a
BeforeUpdate event may cause an apparent error if the withdrawals are
processed before the deposits. You may need to store the "active" transactions
in a temporary table, and only move them to the actual table when complete and
validated.
If one are willing to use methods that aren't directly supported within
the Access interface, and one needs engine level validation - for
instance if this might be updated from outside Access, I think this
should be doable through CHECK CONSTRAINTS.
Want to reply to this thread or ask your own question?
You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.