Values in fields getting switched around

We aren't sure what is triggering it yet, but I have a suspicion, and am hoping y'all can help me figure out where in the code to look and test this. The situation is:

The values of one field (a tax ID field) in our Profiles table is getting overwritten by values of another field (USUALLY Email, but it doesn't appear to be only the Email field). My first inclination was that because these two textboxes are right next to each other on the user's Profile Edit page in our website, users were fatfingering and putting the wrong thing in the wrong box.

However, it's happening to too many folks for that to be believable.

My husband mentioned that a few weeks ago (when this switcheroo started happening) he had been in the Admin interface, and was "using the Builders/Profile Field builder to move things around and make some tweaks.  One of the little boxes I messed with was the email box.  Also moved the Tax ID box too.   Perhaps somehow in my moving things around I did something that is now causing this overwrite problem (or whatever it is). "

He then mentioned the advanced settings on the Email field and asked what the heck the preg_match function in there was (it's a pattern match for XX@YY.ZZZZ email format). He's not a coder.

This was a big clue for me, and at least gave me a starting point about what might have triggered this odd behavior. I checked in the sys_profile_fields table just to be certain and yeah the Email field is the only one with the XX@YY.ZZ regex match. HOWEVER, there are rows in the Profiles table with Email values that do NOT have the @ symbol, so I am convinced that the source of the problem is not from a web-based interface. Otherwise it would have failed the input pattern match.

So now I'm wondering where else there would be UPDATE statements that do NOT rely on the pattern matches for making changes to the database.

Anyone have ideas on where I can start looking? Right now, I'm just brute-force searching through the files with a grep on the command line. It's not very efficient, so ideas are most welcome.

Thanks!!

Quote · 5 Aug 2011

Still totally stumped on this. Anyone have hints on where to start looking?

Quote · 12 Aug 2011

yeah that is a weird one. 

 

 

so i would venture to say that the regular expression that is listed on that block, is not being triggered for one reason or another. as for the data from one block being inserted into another block, that is way wacked, and not sure how that would be happening. 

 

so my suggestion would be to create another field, --> verify email or verify Tax ID, and force it to be compared there, where you could trap fat-fingers, but first thing you have to do is get validation working, on all fields if you require validation. 

When a GIG is not enough --> Terabyte Dolphin Technical Support - Server Management and Support
Quote · 12 Aug 2011
 
 
Below is the legacy version of the Boonex site, maintained for Dolphin.Pro 7.x support.
The new Dolphin solution is powered by UNA Community Management System.