Changes to ldap made w/ ldap and/or dscl commands are not saved

Question

driving me completely buggy.
Currently running 10.6.5 build 10H575
dscl syntax was a little .. annoying. but now that's sorted. I connect to ldap master using either ssh or dscl in from my terminal on my client. Issue command to delete user. All goes perfectly, I poll for the user - no such user exists. Awesome. I exit out, then read ldap db and user still exists. Not awesome.
I cannot interact with user account using WGM gui as my boss already removed that user using WGM, but user exists on the backend - I need to re-enable the user's account because he was mistakenly deleted. And yes, I tried ldapmodify, ldapdelete, dscl - it always "works" but then I go and check and the user persists.
So I've gone from trying to set disable/enable user switch to attempting to delete outright and add user back. I have searched through all data stores to remove him, checked through all groups. I authenticate w/ dscl command so I have the proper permissions to do a deletion.
/LDAPv3/127.0.0.1/Users > read tmartin
<dscl_cmd> DS Error: -14136 (eDSRecordNotFound)
This is what I want. If I exit out of the interactive dscl session, and go back in, user exists. If I open another connection to that ldap master w/out exiting, user exists. If I try to reuse the short or long name through WGM - user exists error pops up.
What am I missing? How do I get this change to stick? Any change? I cannot even get a character appended to the long name (it works but only for that current connection to the ldap master - checking from another session or another client shows old long name in use).
Let me know if this is as clear as mud.
Thank you in advance for any help.
Sincerely,
struggling n00b

Answer 1

I found the answer: OD master #2 that was being moved to the colo, and therefore would have been kept from writing back to OD master 1, was still on the office LAN and accessible from the OD master 1. So all modified records on OD1 were being modified and restored to their original state by OD2 and pretty **** near instantaneously as well. Good to know replication is working so well. So basically, I am ******** and did not notice that of all the OD servers 2 masters were present w/ read-write access to the records. All is fixed and working now.