Results 1 to 12 of 12
  1. #1
    ProvPC is offline Advanced Beginner
    Windows 10 Access 2016
    Join Date
    Jun 2016
    Posts
    37

    Validation rule that disallows identical text entries in two fields of the same table?

    I apologize in advance for my ignorance - I'm a neophyte, but if you use small words, I'll do my best to keep up!

    A bit of background data, which may or may not be useful to the actual question:
    I'm working on creating a database that stores information about resources available in the event of an emergency within a local community organization. The database is comprised of three tables:
    1) People (members of the organization who have volunteered to make themselves and/or their assets available in the event of an emergency).
    2) Resources (physical assets - everything from backhoes to wet-dry vacuums).
    3) Skill Sets (proficiencies in various callings - everything from appliance repair to welding)

    I've created a joined table that ties them all together in a "many to many" relationship, and created a couple of queries that seem to be doing what I want it to at this stage of the project (which, essentially, is keeping track of which person(s) have which asset(s) and which skillset(s).

    The end result I'm working towards is a set of entry forms. The first form feeds the People table with basic information. A button on that form will enter the data and then open a table based on a query to enter the resources (which are primarily simple "yes / no" check boxes - do you have a heavy duty truck? Do you have an extensive first aid kit? etc). And ditto with the skill sets.

    Now for what I'm sure will be the first of many questions:
    I seek to avoid duplication of entries for individual members in a community with multiple family members with the same names. In doing so, I've created a simple calculated field which takes entries from other fields and joins them together. In this case, it's based on individual name fields, out of which it creates a "complete name", so that individual fields of "Mickey" "M" "Mouse" and "Minnie" "Q" "Mouse" becomes "Mouse, Mickey M & Minnie Q" - and that calculated field I hope to make unique (that's a problem for another day).

    My admittedly minor problem is what to do when Mr. Mouse meets a fiercely independent Daisy Duck. Or rather, when he doesn't.



    The calculated field is simple - but it's based on NOT entering a last name for the spouse unless it differs from the head of house. In our example here, the calculation would return "Mouse, Mickey M & Daisy D Duck". That's perfectly fine with me. However "Mouse, Mickey M & Minnie Q Mouse" is not.

    I can fairly easily achieve the results I'm looking for in the calculation in a couple of different ways that I can think of - but the table will also be printed from time to time, so I'd prefer to not have the spouse's last name entered at all, if it's the same as the head of house's. I just can't figure out a validation rule that prevents someone from actually entering it.

    I've tried things like "<>[HoHLastName] or is NULL" (which to me means, "has to be different than the head of house last name, or empty"), but I get an error "Invalid SQL syntax - cannot use multiple columns in a column-level CHECK constraint" (which I interpret as meaning "Sorry - you can't use any other fields in this table as the basis for a validation rule")

    So - am I on the right track at all? Or should I simply let the duplicate last name be entered and manipulate it out in a query later on?

    And is this a really, really stupid question?

  2. #2
    CJ_London is offline VIP
    Windows 10 Access 2010 32bit
    Join Date
    Mar 2015
    Posts
    11,837
    It's not a stupid question, avoiding duplication is a good thing to do, However

    1. calculated fields cannot be indexed, so you will not be able to make them unique except by some sort of query - so you might as well calculate the unique name in a query


    and then issues that need to be addressed include
    2. duplication of names also relies on consistent spelling - what if you have Mickey and Mick or Mike?
    3. what if you have two or more families with the surname of Mouse?
    4. you still have the Daisy Duck issue
    5. what about a father and son situation where they both have the same first name?

    Why not just base the duplication on the postal address and name/initials? on your entry form, have user enter address first, then pull up a list of people living at the address in a listbox or subform. If the name is already there use selects, if not, user adds. If you have the Mickey/Mike situation, raise a question to the user to clarify.

    Many systems include a 'salutation' field which can be calculated but also overridden (e.g. Dear Mr Mouse, Dear Mickey) - depending on the relationship of the person. You could adapt this to be a calculated field in a query for your form or report based on address

  3. #3
    ProvPC is offline Advanced Beginner
    Windows 10 Access 2016
    Join Date
    Jun 2016
    Posts
    37
    Thanks for your reply!

    Quote Originally Posted by Ajax View Post
    It's not a stupid question, avoiding duplication is a good thing to do, However

    1. calculated fields cannot be indexed, so you will not be able to make them unique except by some sort of query - so you might as well calculate the unique name in a query
    Good point! And probably ultimately the approach I need to use, for several reasons. Thank you!

    Quote Originally Posted by Ajax View Post
    and then issues that need to be addressed include
    2. duplication of names also relies on consistent spelling - what if you have Mickey and Mick or Mike?
    I hadn't actually considered that. Typically, the same person would be entering the data at each location, based on interviews with people known to them at the time, so I rather think that won't happen too often, but you never know. I'm liking your address idea more and more (though it shares this same problem doesn't it? Is 1234 Main St the same as 1234 Main Street, for example? Gary's Lane or Garys Lane? Is it Apt 101, Apt#101, #101, Unit 101 or Unit #101?)

    Quote Originally Posted by Ajax View Post
    3. what if you have two or more families with the surname of Mouse?
    I didn't think that would be a problem, since it's unlikely that all those families share middle initials and married spouses with the same first name and middle initials. The idea was that the whole name - spouses names and initials included - had to be unique

    Quote Originally Posted by Ajax View Post
    4. you still have the Daisy Duck issue
    True. I'd like to avoid entering the last name at all, if it's the same as the head of household. I can filter it out after the fact, of course, or ignore it completely inside the calculation, but I'd much prefer it didn't get entered in the first place, even if we decide to switch to the address as the index, as the "complete name" calculation will be used in printing (which is why I thought it might as well do double-duty as the deduplication device as well!) Even if we switch to using the address, is there some way to prevent a name being entered in the Spouse-LastName field, if it matches the name in the HoH-LastName field of the same record?

    Quote Originally Posted by Ajax View Post
    5. what about a father and son situation where they both have the same first name?
    That happens quite a lot! But unless the father and son each have the same middle initial, and each married spouses with the same first name and middle initials, I think they would still be considered unique.

    Quote Originally Posted by Ajax View Post
    Why not just base the duplication on the postal address and name/initials? on your entry form, have user enter address first, then pull up a list of people living at the address in a listbox or subform. If the name is already there use selects, if not, user adds. If you have the Mickey/Mike situation, raise a question to the user to clarify.
    So... your idea is to use a combination of the address and name to create a unique key? The idea certainly has merits - among which is that it allows for multiple entrants who share the same property or dwelling, should there be any. But doesn't it further complicate #2 above? Wouldn't any variation of either address or name result in a non-match and allow for duplication? I'm imagining a scenario in which, instead of just:

    Mouse, Mickey M 111 Disneyland Lane
    Mouse, Mick M 111 Disneyland Lane

    We now have

    Mouse, Mickey M 111 Disneyland Lane
    Mouse, Mick M 111 Disneyland Lane
    Mouse, Mickey M 111 Disney Land Lane
    Mouse, Mick M 111 Disney Land Lane
    Mouse Mickey M 111 Disneyland Ln
    Mouse, Mick M 111 Disneyland Ln

    I really, REALLY like the idea of pulling up the name or address in a subform or listbox! That, all by itself, should help eliminate duplications no matter what we use for a key! Thanks for that - I'll begin exploring that idea later today!

    Quote Originally Posted by Ajax View Post
    Many systems include a 'salutation' field which can be calculated but also overridden (e.g. Dear Mr Mouse, Dear Mickey) - depending on the relationship of the person. You could adapt this to be a calculated field in a query for your form or report based on address

  4. #4
    CJ_London is offline VIP
    Windows 10 Access 2010 32bit
    Join Date
    Mar 2015
    Posts
    11,837
    one other thought - not sure where you are based, but mobile numbers are generally unique to the individual

  5. #5
    ProvPC is offline Advanced Beginner
    Windows 10 Access 2016
    Join Date
    Jun 2016
    Posts
    37
    Quote Originally Posted by Ajax View Post
    one other thought - not sure where you are based, but mobile numbers are generally unique to the individual
    True - but not everyone has one, so I would think that would pretty much rule it out (I don't think you can have a field be both blank and indexed, can you?)

    Dang! In my enthusiasm over your suggestion about pulling up entries based on addresses, I got side-tracked from my original question! The whole notion of using it to prevent duplication aside, is there a way to prevent a name being entered in the Spouse-LastName field, if it matches the name in the HoH-LastName field of the same record?

  6. #6
    CJ_London is offline VIP
    Windows 10 Access 2010 32bit
    Join Date
    Mar 2015
    Posts
    11,837
    is there a way to prevent a name being entered in the Spouse-LastName field, if it matches the name in the HoH-LastName field of the same record?
    sure - in the afterupdate of the Spouse-LastName have some code that compares the two and if the same deletes it. - something like

    if Spouse-LastName=HoH-LastName then Spouse-LastName=null

  7. #7
    ProvPC is offline Advanced Beginner
    Windows 10 Access 2016
    Join Date
    Jun 2016
    Posts
    37
    That's a great suggestion - Can you provide a sample of such code? I'm afraid I wasn't able to come up with it - and the one in your previous post doesn't see to work (likely because I'm doing it wrong!)

  8. #8
    CJ_London is offline VIP
    Windows 10 Access 2010 32bit
    Join Date
    Mar 2015
    Posts
    11,837
    the code in my last post is the code to use. 'doesn't work' isn't very helpful - you get a wrong result? a compile error?

    Also having none alphanumeric characters in field names is a bad idea and can produce unexpected errors

  9. #9
    ProvPC is offline Advanced Beginner
    Windows 10 Access 2016
    Join Date
    Jun 2016
    Posts
    37
    Apologies, sir or madam, I did not mean to cause offense, or to imply that there as anything wrong with the code.

    I made several attempts to use the code above, all of which failed. I'll get the specifics of those attempts in a moment. I then realized that your post said, "something like..." which led me to believe that there were two possibilities at play: either you had intended that the code be simply a generalization, and I was to use it as a guide to creating my own, or I was using it incorrectly. By saying that it didn't seem to work, I was merely trying to indicate that I did try it (and that it's failing was likely my own fault).

    This is what I tried (some of which I fairly certain would NOT work, but attempted anyway in the interest of being thorough before letting you know itiasking for additional assistance:

    1) I pasted the text you provided directly into the "AfterUpdate" line of the Spouse-LastName field.
    Result: On update, the following message appeared: "Microsoft Access cannot find the object 'if Spouse-LastName=HoH-LastName then Spouse-LastName=null.' If 'if Spouse-LastName=HoH-LastName then Spouse-LastName=null' is a new macro group, make sure you have saved it and that you have its name correctly."

    2) I selected the "build" option, chose "code builder," and pasted the text you provided into the resulting window, between the "Private Sub Spouse_LastName_AfterUpdate()" and "End Sub" lines.
    Result: On update, no error messages of any kind were created. However, on examning the table afterwards, the contents of the Spouse-LastName field had not been removed.

    3) I selected the "build" option, chose "macro builder," click on "if" in the right hand pane and pasted the text you provided into the line provided.
    Result: On attempting to save the macro, the following message appeared: "Microsoft Access cannot parse the expression: 'if Spouse-LastName=HoH-LastName then Spouse-LastName=null.' Click OK to return to the action argument or conditional expression where this expression appears and then correct the syntax.

    4) I selected the "build" option, chose "expression builder," then pasted the text you provided into the resulting window.
    Result: On attempting to exit the builder, the following message appeared: "The expression you entered contains invalid syntax. You may have entered an operand without an operator.


    About this time, I realized that you had used the expression, "something like..." in your response, so I opted to make a few adjustments and try it on my own. Here are those results.


    5) I added brackets around the field names (since it seems to be an access convention). Instead of using the text you provided, I used if [Spouse-LastName]=[HoH-LastName] then [Spouse-LastName]=null
    Result: The same as above, in all 4 cases.

    6) I attempted to create my own expression, following your example. I used: Iif([Spouse-LastName]=[HoH-LastName],[Spouse-LastName]="",[Spouse-LastName])
    Result: On update, no error messages of any kind were created. However, on examning the table afterwards, the contents of the Spouse-LastName field had not been removed.

    Finally, I surrendered and posted here, asking for assistance in formulating the code, and freely admitting that I was probably not using it correctly.

    I hope this additional information proves useful. I apologize for not having provided it earlier.

  10. #10
    CJ_London is offline VIP
    Windows 10 Access 2010 32bit
    Join Date
    Mar 2015
    Posts
    11,837
    Apologies, sir or madam, I did not mean to cause offense, or to imply that there as anything wrong with the code.
    no offence taken, but we provide suggestions rather than solutions and unless you provide us with the code you are actually using, together with other things like table names, field types, we can only provide 'something like'.

    What you did here is the right thing to do - but you need to check names are correct etc

    2) I selected the "build" option, chose "code builder," and pasted the text you provided into the resulting window, between the "Private Sub Spouse_LastName_AfterUpdate()" and "End Sub" lines.
    Result: On update, no error messages of any kind were created. However, on examning the table afterwards, the contents of the Spouse-LastName field had not been removed
    So you should have had this

    Code:
    Private Sub Spouse_LastName_AfterUpdate()
    
        if Spouse-LastName=HoH-LastName then Spouse-LastName=null
    
    End Sub
    and if it didn't work, rather that just saying it didn't work, post the code you had actually used plus this comment

    Result: On update, no error messages of any kind were created. However, on examning the table afterwards, the contents of the Spouse-LastName field had not been removed.
    I'm going to have to guess from here as to what is wrong.

    You will notice that the sub name is not Spouse-LastName_AfterUpdate(), but Spouse_LastName_AfterUpdate() - vba has replaced the - with a _.

    One of the problems with using non alpha numeric characters is they can cause unexpected errors. In this case when you pasted the code directly into the vba window, I'm guessing the - sign was reinterpreted and spaces added (i.e. vba assumed it was a calculation) so

    Spouse-LastName
    became
    Spouse - LastName

    and similarly for the other field. As explained their use can cause unexpected errors, and I guess this is one of them.

    my other guess is that you do not have Option Explicit set in your code window (just below Option Compare Database) which would have picked this up as an error.

    I'm guessing again, that you then put some brackets round the name, but now it has spaces - so still not valid, and without Option Explicit, VBA just treats as an undeclared variable, executes the line but it does nothing.

    As I said, this is guesswork as to why it is not working. Please let me know if my guesses are correct by repeating the copy paste and the subsequent steps if necessary. If correct, remove the spaces from the resultant names and try again, if that doesn't work, change the - to a _ and try again. better still, remove the - from your field and control names, use an _ instead if you have to.

    Once you've done that, if it is still not working, come back with the code used and confirm the names of your table fields and form controls - in your first post you said

    I've tried things like "<>[HoHLastName]
    and in subsequent post you used HoH-LastName

  11. #11
    ProvPC is offline Advanced Beginner
    Windows 10 Access 2016
    Join Date
    Jun 2016
    Posts
    37
    I apologize, again, for not having provided adequate information in previous posts. I'd like to assure you that it won't happen again, but, alas, I had thought that by saying that I had "pasted the text you provided", I was posting the code I had actually used, so my explanations remain lacking, and I'm not sure how to improve upon them. As for the field name in my original post, it was merely a typo (for which I apologize).

    The good news, however, is that your guesses were perfectly accurate. VBA did insert spaces where none were intended, and replacing the hyphen with an underscore resolved the issue, and the duplicate name is eliminated on update. I will begin the process of renaming all the fields to eliminate non-alpha numeric characters (there are a lot of fields that will require renaming).

    As I indicated from the outset, I am a complete novice. I will doubtless have many more questions. I can't promise to be wise enough to phrase them correctly, or that the information I provide will be accurate, but I will certainly try to improve. In the meantime, thank you for your kind attention to my post - as well as for affording what ultimately proved to be the solution!

  12. #12
    CJ_London is offline VIP
    Windows 10 Access 2010 32bit
    Join Date
    Mar 2015
    Posts
    11,837
    No need to apologise - the problem is you just said
    and the one in your previous post doesn't see to work (likely because I'm doing it wrong!)
    For all I knew, you had posted it in a wrong event, when copying you had missed a bit off, perhaps the spelling was different (you had spelt it differently in your posts). Also I asked what 'didn't work' meant. Perhaps you had a compile error for example.

    The tips for posting questions are (and this is not a criticism )

    • always use your real field and control names - many newbies do not know about reserved words (date, name, group, time are 'popular' ones) which can cause unexpected errors
    • if posting code, always surround with the code tags - the # button - to preserve indenting - and copy and paste it, don't retype it and paraphrase - the syntax is important and you may not transpose the real issue or create non issues.
    • when your receive a response, check the thread for other responses. You only receive one notification, but more than one person may have responded - and there is nothing more irritating than providing the correct solution for it to be ignored and seeing 15 more posts trying to resolve the issue
    • don't assume you know what the solution is, just not quite sure how to get to it - many times the solution is completely different to the one envisaged


    Good luck with your project

Please reply to this thread with any new information or opinions.

Similar Threads

  1. Puzzling validation rule for text only
    By bwelton in forum Database Design
    Replies: 4
    Last Post: 12-03-2015, 09:08 AM
  2. Replies: 2
    Last Post: 06-16-2015, 03:52 AM
  3. Replies: 2
    Last Post: 12-27-2013, 07:32 AM
  4. Validation on identical text question
    By edrahl in forum Database Design
    Replies: 1
    Last Post: 02-26-2008, 09:38 AM
  5. Validation rule for a text field
    By wasim_sono in forum Forms
    Replies: 4
    Last Post: 03-14-2006, 11:39 PM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
Other Forums: Microsoft Office Forums