Eric Knipp wrote: > Its going to be a lot easier to configure your internal system to > reference the new database than to do some kind of replication hack > like you're talking about. I understand the desire to delay the > implementation of the database change, but you need to resist it. > You're asking for a world of pain.
Completely agree. @Mike: the way i'd do what you want to do for the short-term is to put all of the current member profile into hidden fields (as well as use that data to pre-pop the data entry fields), then (on submission) loop through and compare the contents of each of the hidden fields with their counterparts in the form data being returned for the update. Then you only send those that differ via cfmail. But by the time you've coded/debugged all that, i'd guess that those same hours would have gotten you pretty close toward your long-term goal. And for all that, you'd still be introducing human error into a process that is obscured from your members. What happens to their sense of trust in their site when they update the profile and find (1) that it doesn't update right away and/or (2) they come back later and find out that the update they isn't correct (or isn't the update they made) because your internal staff didn't copy/paste into the correct field? My two cents: "World of pain" pretty much sums it up. --- Skipper Pickle 972.978.5807 _______________________________________________ Reply to DFWCFUG: [email protected] Subscribe/Unsubscribe: http://lists1.safesecureweb.com/mailman/listinfo/list List Archives: http://www.mail-archive.com/list%40list.dfwcfug.org/ http://www.mail-archive.com/list%40dfwcfug.org/ DFWCFUG Sponsors: www.instantspot.com/ www.teksystems.com/
