Merging duplicate records

[liddlem]

Quite often, my users are too lazy to check whether a patient record exists or not. Consequently, we have a number of duplicate records that I would like to merge.

My problem is finding a way of linking 2 subforms to a parent that is not based upon a query.
On the parent form, I want two Comboboxes called 'Patient_to_Keep' and 'Patient_to_Discard'.
The two subforms called Frm_DUP_Patient1 and Frm_DUP_Patient2 should then display the data of the respective combo boxes.

Once I have this working, I can write the necessary code to compare and update the data as required.

Anybody had a solution to a similar problem? If so, your suggestions are most welcome.


PS: Once again - I find myself posting questions to this forum on a friday afternoon!. I'll probably get to your response on Tuesday or Wednesday next week.

 

[vbaInet]

Quite often, my users are too lazy to check whether a patient record exists or not.

You should be doing the checking for them. Write to code to check for duplicates before a patient is added, prompt the user if duplicates are found and provide a means for verifying the details of the duplicate records.

On the parent form, I want two Comboboxes called 'Patient_to_Keep' and 'Patient_to_Discard'.
The two subforms called Frm_DUP_Patient1 and Frm_DUP_Patient2 should then display the data of the respective combo boxes.

To link the combo box to the subform, have a look at this link from GinaWhipp:
http://www.access-diva.com/f2.html

A word of caution, don't delete the duplicates but rather archive them for a period of time after which they can be deleted.

 

[jdraw]

lidlem,

Just to say I agree with vbaInet --try to capture "common errors" in code/logic so that user can not make them. Many "simple, easy to use interfaces" have taken the time to prevent/reduce errors that user could receive.

There is an interesting video tutorial here that deals with situation where something can be in one list or another. Your Patient_to_Keep/Patient_to_Discard reminded me of it. You can view it and see if it applies to your situation.

Good luck.

 

[liddlem]

Thanks for your suggestions. I think i now have a working solution.

Just to comment on your data validation solutions....I couldn't agree with you more.
Central Australia is an interesting place. Most of the population is nomadic, semi-literate with no fixed address or telephone number. Birth dates are usually an estimated date. Also, people are sometimes known to have different names, depending on what community they are in.
So I do have a 'system' in place for users to search for possible duplicates. The problem is that my users obviously don't use the function.

 

[jdraw]

I hear what you are saying. I worked on a system where citizens could apply for certain loans/grants. Many were in northern Canada and addresses were things like Mile 45 on a certain railway line or by trap line.
You know your situation better than we do. It sounds like the real challenge may be communicating What the system is; How to use/interface with it; Why you as a user should use the system.

Good luck.

PS liddlem - Sorry for dropping a "d" in your name---my bad.

 

[vbaInet]

So I do have a 'system' in place for users to search for possible duplicates. The problem is that my users obviously don't use the function.

Ok, what we're saying is that instead of "having a system in place for searching", move that code to the Before Insert event of the form and do as much validation as you can, prompting the user if there's a possible match. This is what we mean by "doing the check for the user".