I have an extensively programmed workbook that gets deployed to multiple locations. One of the users discovered a few programming errors that were not discovered in testing and they need to be corrected. The corrections need to occur at the remote locations as opposed to them sending their books to me. I created a workbook to update the books in the remote locations. The method I am using is to open the book to be fixed, rename the main module, delete all of the procedures from the renamed main module, import a new (corrected) main module. Now, one would ask, why is he doing it that way, just delete the original module and import the new. I tried that. The delete of the module seemed to work properly but only after I slowed down the program or else the import seemd to occur before the delete was complete which caused duplicate procedure names and cause VBA to blow up. Thought I had this resolved but when I sent out the fix it still did not delete the original module out in the field and caused the duplicate procedures. This is why I chose to just rename the original module and delete all of the procedures. It works fine except----I like to keep track of updates so when I open the book to be fixed I unhide a particular sheet, change an unused cell to indicate that the update has been performed, hide the sheet, replace the code, save the book, and then excel blows up on the ActiveWorkbook.Close. If I remove the code that unhides the sheet and changes the cell content, everything works fine. Anyone have any idea why just changing a sheet's cell value would cause excel to croak following module/procedure replacement?