It is usually the code that the code writer writes that creates the problem.
However, Excel can be finicky and turn corrupt on the best of code writers.
Your basic blocking and tackling should come first...

Use Option Explicit as the top of each module.
Declare all variables and don't use Variants unless necessary.
Use error handling and avoid the use of on error resume next.
Keep your code modules under 64 kb. You can export a module to
a folder and check the size there. If you have 5,000 lines in a module
you are probably in trouble.
Keeping functions in one module and subs in another is one way to organize.
Sub divide those as appropriate.
Retain daily copies (or at more frequent intervals) of your code.
If you run into a problem it is easy then to go back to a non-problem version.
Make sure each procedure runs before starting another.
(with the on error resume statements commented out)
Develop your code in the oldest version of Excel expected to be used.
Test your code on all Excel versions that will be using it.
----
Jim Cone
San Francisco, USA


wrote in message
Nothing came up with the Error Handling added to the code. However
after multiple testings (after each of which I closed without saving),
open the file gave me this message:

"Damage to the file was so extensive that repairs were not possible.
Excel attempted to recover your formulas and values, but some datamay
have been lost or corrupted."

What could my macros be doing to damage the file? Is there a maximum
amount of macros that can be run before a file becomes corrupt?

Thanks!
-Teilen