Copy date from one workbook into other workbooks located in another folder, there is a common reference no. between them

[Raceman]

I need to pull the date from one workbook called “log” (the date is in column B) and display it in another workbook (one of which is) called “MrepoA” .
I will have approx 8 workbooks in a folder called: MrepoA, MrepoB, MrepoC , etc. that need to receive date information from the “log” workbook (which is located in another folder).
We can relate the 2 different types of workbooks (log and Mrepo) with a number that is common between them. This number is called “log number”. The log number in the “log” file in column B. And the log number in all of the “Mrepo” files is in column E

After the macro is run I should find that the date from the “log” has now been copied into all of the Mrepo files in a newly inserted column just before column F, based on the reference of “log number” which is common between files.

I don't mind introducing a 3rd workbook in the folder where the "Mrepo" files are located and putting an "execute" button in this "Execute" workbook to start the macro. I will be introducing new Mrepo files in this folder each month so having a 3rd workbook which can stay in the folder might be helpful.

 

[brian.wethington]

My code used .xls I don't see anything that would keep you from being able to use it; however, you have already mentioned that it did not work for you before. I tested mine and JLG's code and mine worked with xls files and JLG's worked with xlsx for me (did have to make a tweak on JLG's but it was likely a copy paste error.

 

[JLGWhiz]

The only reason for it to kick out on the 'For Each c In Msh' would be mispelled words, variables empty or equal blank, or hidden characters. Each would give a different type of error message. If you are still getting the 'Object Defined or Application Defined error' it would most likely be related to spelling or something other than the variables. Have you tried walking through the code using F8 to step one line at a time? To do that, you open the VBE and left click anywhere in the body of the procedure. Then just press F8 to start walking through. If and when the error occurs, click Debug on the error dialog box and it will leave the line of code with the problem highlighted. Hover the mouse pointer over each part of that line and look at the tool tips text that pops up. It will help you locate the part that is causing the problem. The .xls should not be a problem with any of the code in the procedure, so long as the files are actually .xls files. That should be easy enough to verify. Problems of this type usually turn out to be something that should have been obvious to everybody, but we keep overlooking it. For instance, all this time the title line for the code should have been.

Private Sub CommandButton1_Click()

And the code should be run from the Worksheet module that contains the command button. It really irritates me when I miss something like that for so many days. The problem is that the code will run from the standard module without the Click event, so I didn't catch it. That is an easy correction to make.