We need more information. Like what is the structure of the fields you are copying etc.

For copying within the same form, it can be as simple as Duplicate Record and followed up with Duplicate Record Macro Broken.

Being in separate forms and sub forms may increase the difficulty a bit. It would depend on your comfort level with vba or macros.

But the next question that begs to be asked since we can't see exactly what you are trying to do:  Why are you trying to duplicate data instead of using a relational query to just pull the data into both sub forms?

Two options: 1) good old copy and paste; 2) add a command button to the source parent or sub form and write some VBA code to move the data to the target sub form. Writing such a copy routine isn't for the faint of heart.

(Notice I avoided asking why you have two sets of identical forms in the first place.)

Yeah, that's a really good question, Roy. Why do you have two identical parent forms and two identical subforms? In most cases, if both forms need to display the same underlying information, you should have one set of forms and use queries, filters, or different views to show the appropriate records.

If you truly need to copy records from one detail table to another, then a command button with an append query is usually much easier and more reliable than trying to copy controls from one subform to another. But the correct approach depends entirely on how the two tables are related and which fields should be copied versus left alone, such as primary keys and foreign keys.

Can you give us a little more detail about what each parent form represents, what table each subform is bound to, and why the data needs to exist in both places?

Richard One reason I've seen in some Access apps, is that the person wants the user to be able to open the same form again, and start something new, like a sales transaction while the customer wanders off to look for some forgotten item in the store. The problem with that is, if the developer has "helper" routines in modules for the forms (both of us like those), we risk module and global variable corruption from the second form into the first. We've mentioned the problems instancing forms, the same thing happens. DoEvents makes this scenario even more probable. Have you seen anything to prevent this other than starting a whole new Access session using a COPY of the .accdb/e ?

You can use the trick I showed before: create a shortcut that points to the Access executable and passes your ACCDB file as a parameter. That opens a completely separate Access session, with its own memory space, without having to make an actual copy of the ACCDB file.

Multiple form instancing is a pain in the butt. I've covered it in some Developer lessons, and it isn't pretty. If you have helper routines in standard modules, global variables, or other shared state, a second instance of the same form can definitely interfere with the first one.

For the sales example, though, I think there are usually better ways to handle it. I'd put an On Hold checkbox on the OrderF. If the customer wanders off to find their wallet, save the order, mark it On Hold, close it, and start the next transaction. When the customer comes back, open the held order and continue. That is much simpler and safer than trying to keep multiple copies of the same form open.

I run into a similar situation in my own database when someone accidentally creates two customer accounts with different email addresses. Since email is the key field in my CustomerT, I sometimes have to merge the records. I have a button that handles most merges automatically, but occasionally there is information on one record that I need to manually copy to the other.

For that, I made a "Go To Last Customer" button. I open Customer 1, then Customer 2, and clicking the button takes me back to Customer 1. Click it again, and it returns to Customer 2. It lets me bounce between the two records without needing multiple instances of CustomerF.

But yes, if you truly need two independent copies of the same form at the same time, launching a separate Access session is probably the cleanest approach.