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.

As of v2010 all M$ Office apps use VBA7! This has no effect on earlier
projects written with VBA6, ..they still work fine running under VBA7!

--
Garry

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