On Thursday, July 17, 2014 at 11:17:09 AM UTC-7, GS wrote:
That's a nice theory, Garry. Can you explain then why a system that
was installed originally with Windows 7 and Office 2010, and has code
originally developed on it in Excel 2010, would suddenly start
spitting out this error? Steve's solution is the only one I found
that resolved it.

I suspect that an app developed in VB installed/replaced the default
version of the DLL with the one that the VB app uses. Often happens
when users migrate older software to be used on newer OSs. The best way
to tell is to see if any installers replaced the default runtime
component, and/or if you do have older app[s] installed then see if
they work properly. Then 'undo' the changes you made and see if the
older app works. If it doesn't work the 1st time but does the 2nd time
then that DLL was replaced by the app's installer.

Note that the current runtime for msvbvm60.dll is SP6 (file version
created 06/10/2009 at 5:38PM. Version# is/sb 6.0.98.15. If this isn't
what's in your SysWOW64 folder then it's not what was installed with
your OS!

--
Garry

Free usenet access at http://www.eternal-september.org
Classic VB Users Regroup!
comp.lang.basic.visual.misc
microsoft.public.vb.general.discussion

I had the same problem with a brand new workbook that I had just started writing macros in today. I am using Office 2010 on a 64-bit windows install, and this was the only way that I was able to update the references in my workbook to point to something other than msvbvm60.dll. I also, didn't have a VBA6.DLL at all, but did have a VBE7.DLL. I performed the copy and rename using VBE7.DLL instead of VBE6.DLL and it worked like a champ.