>>>Hi,
>>>
>>>I am considering a feature for my app that would allow user combining two records into one. For example, say in the parts table they have two pars "1234" and "1234A" and at some point (after years of use) they realize that this is one and the same part. They can't rename one into the other because another record of unique entry already exists. They can't delete one because it has child records (transactions, P.O.s etc.). So I am thinking of writing a routine that would do it in code. Does it make sense? What I mean is, do others (as other developers on this message board) have routines that allow combining two records with different values in unique field into one? TIA.
>>
>>Hi Dmitry,
>>
>>I have the same problem in the POS/Inventory app I sell. What I did was give the users a form (see attached jpg) that allows then to select each of the products and then designate the one they want to keep. Then I have code that replaces the new primary key to all of the child records.
>>
>>My solution is neither elegant nor generic because the code is specific to my data structure and, if I decided someday that another child table is needed, my assimilation code would need to be changed. But it works for me now.
>>
>>Hope this helps,
>>
>>Ken
>
>Thank you very much, Ken. My code most likely won't be a generic but rather specific to the table structure. I like how you created this window for merging the records. I will use the term "merge" too as it is easier to understand for a user than a technical term. And thank you for sharing the screen!

Hi Dmitry,

I attached another view of the form. By pressing the Set Up button (which is visible only by permission) the user then has some control over what is actually done in the "merge"

All does not always go smooth.... I sometimes have cases where the two products have identical names thus making it difficult to make the selections. In those cases, I instruct the user to slightly modify the name of the product that will go away such as "PRODUCT123 BAD"

Hope this helps,

Ken