>Seldom wrong and right again, Shawn! Yes, I forgot to cover the >reflexive case. I don't have a magic bullet for that scenario; >you'd just have to check that with application code. > >But on re-reading his original post, it occurred to me that I >had misread it completely. I just sent a note outlining my new >thinking to the list; maybe we can help this guy solve his >problem without having to write a lot of application code ;-)
I have now come to the conclusion. The idea I just posted from the last email is not going to work either because I would have 2 or more people accessing the same table at the same time, so no email addresses will be unique. The same would goes for creating a new table too because of a few reasons. 1) The 2nd person would be unable to update the email if the primary key is set. 2) I would have to use the application code to remove a row if the customer decided not take out the email address, like the secondary email in this case. The reason for all of this email address is I had builted a lost password retrieval webpage. In plain English, if an email address is found then send an email with the lost account number and password to that email address. So, I came up with a plan this morning. I'm going to leave the original table intact and instead I will use the application code to do this... 1) If no email address is found then don't send an email. 2) If duplicate email address is found then don't send an email and the customer would have to call us instead. 3) If an email address (one row) is found then send email to that email address. This is what I going to settle on. It's the best way to go.... It would also help me to avoid having to update the HTML, JavaScript, PHP and SQL code in almost 50 webpages. That's a lot of time when you think about it. Thnaks, Scott -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
