[AccessD] Dirty property

[Gustav Brock]

Hi Susan

Oh, you mean the schema design? I guess there is no black/white here.

If you, for example, count upper and lower teeth, there would hopefully never be a third option. You could argue, that in such a case you should state 0 (zero) for not teeth at all in either or both (and yes, I know dentists operate with a quadrant system with left/right as well).

So it depends.

I checked with a validation rule of:

    Is Not Null Or [OtherField] Is Not Null

But Access barks that other columns than the current cannot be used in the SQL.
Data macros I have never used and probably never will.

/gustav

-----Oprindelig meddelelse-----
Fra: AccessD [mailto:accessd-bounces at databaseadvisors.com] På vegne af Susan Harkins
Sendt: 23. juli 2015 15:05
Til: Access Developers discussion and problem solving
Emne: Re: [AccessD] Dirty property

No, I didn't mean the users, I meant the design. I'd like to hear how you would handle this -- I'd love to hear it. Would you mind sharing? Right now, I'm just handling it with a bit of simple code that checks for values and doesn't let the user save and continue without supplying one or the other. I could think of no way to do this at the table level, so went with code instead.

Susan H.

On Thu, Jul 23, 2015 at 8:00 AM, Gustav Brock <gustav at cactus.dk> wrote:

> Hi Susan
>
> > one of either two fields is required, but not both.
>
> That could easily be done in a form. I cannot imagine users are 
> operating at the table level?
>
> /gustav
>
> -----Oprindelig meddelelse-----
> Fra: AccessD [mailto:accessd-bounces at databaseadvisors.com] På vegne af 
> Susan Harkins
> Sendt: 23. juli 2015 13:44
> Til: Access Developers discussion and problem solving
> Emne: Re: [AccessD] Dirty property
>
> Well, in this particular form, I have a situation where one of either 
> two fields is required, but not both. I'm not sure how I could've 
> normalized it differently, but that's possible. I don't know of any 
> way to validate an either/or requirement at the table level. I think 
> it might be easily done in 2013 with the new data macro feature.
>
> I truly think the easiest course -- and I tend to take that road when 
> possible -- is to just remove the Close button from the form and force 
> users to close using the form's command buttons. To be consistent, I 
> guess it's best to remove it from them all.
>
> I appreciate the conversation, because learning this business about 
> the form close event and saving is great information. I almost never 
> work in Access anymore though and I've forgotten so much, but I don't 
> believe I ever knew that about Dirty and Form_Close.
>
> Susan H.
>
> On Thu, Jul 23, 2015 at 6:45 AM, Darryl Collins < 
> darryl at whittleconsulting.com.au> wrote:
>
> > Thanks Gustav,
> >
> > I am always happy to listen to the experience and advice of those 
> > more talented than I. Appreciate your thoughts on this issue
> >
> > Cheers
> > Darryl.