views:

44

answers:

1

My table's records need to satisfy two conditions:

  • Entries in the ClosingDate field cannot correspond to a date before what is in the RequestDate field.
  • A BidBond value may be supplied if, and only if, the record's Type field is set to "Tender"

The two resultant multi-field validation rules are:

1. ([ClosingDate] Is Null) Or ([ClosingDate] >= [RequestDate])
2. ([Type]="Tender") Or ([BidBond] Is Null)
  • If Rule 1 is violated, the validation text should be "Closing date cannot occur before the request is made."

  • If the data entered falls foul of Rule 2, "Bid bonds can only be assigned to tenders." should greet the user.

I know I can combine the two validation rules with an And clause, but then how would I specify two different validation texts depending on which validation rule is violated?

+1  A: 

I don't see how to do what you want with validation rules at the table level. Instead I will suggest using forms for data editing. Forms give you more flexible options to handle complex business rules. You can handle your validation requirements with events (such as Before Update and After Update) associated with individual form fields, or events at the form level.

One possibility your question didn't address is what should happen if both your validation rules are violated in the same record. Your validation text issue becomes even more complicated. I wouldn't attempt it with table validation rules.

Furthermore, Access MVP types recommend limiting user interactions to forms. The users should never even see datasheet views of tables or queries.

HansUp
@HansUp: I also think that users shouldn't see tables or queries. However, I'd much rather have a table validation drive the form validation than use a 'band-aid' solution by having the form running an independent validation check.
Zaid
No argument on that point, Zaid. But I still don't see how to do it the way you want ... we can do it with a form.
HansUp
@Zaid: your instincts are good, but simply not possible with a Jet/ACE back end up through A2007. Starting in A2010, there are newly added table-level data macros, which sounds icky ("macros" are not something most experienced Access developers are likely to respect), but they are amazingly powerful -- you can implement what amounts to a trigger and it will apply to any user of the table. But previous to A2010, it can only be done at the application level, not at the engine level.
David-W-Fenton
@David: Thanks for the info. I just wish Microsoft had addressed this need at a software design level earlier...
Zaid
It's actually a pretty complicated problem to implement trigger-like mechanisms in a database engine that lacks a centralized point of interaction with the data store. That is, with a server database, the server daemon is the point of access to the data and can properly serialize updates to the data to insure conformity with structural rules when triggers are activated. With Jet/ACE, every client is accessing the same data file and I can't quite conceive of how a trigger could be implemented without vastly slowing down the engine. In any event, it was implemented for Sharepoint compatibility.
David-W-Fenton