Thanks for yor help Stuart.

Regards  Don

On Jun 2, 2:27 pm, Stuart Redmann <[email protected]> wrote:
> On 1 Jun., 01:57, donvreug <[email protected]> wrote:
>
> > The environment this is occuring in is a corporate one where there are
> > a number of Excel workbooks each with VBA modules that are deisgned
> > for different tasks.  Occassionally someone tells me a macro has
> > failed, and when I check they usually have two or more Excel workbooks
> > open.  
>
> Who is "they"? Usually one knows which workbooks one has opened and
> particularly why. Or is this some kind of environment thing, such as
> "that is just some stuff that appears automatically when I boot my
> machine".
>
> What are the tasks that these workbooks are designed for? Although an
> Excel workbook normally just sits there and does pretty much nothing,
> one can design workbooks that regularly do some system maintenance
> jobs like back-ups. That would make debugging quite hard (you would
> first have to determine which Excel application is giving the error
> message). Or do you mean that when you perform some action you get
> "occassionally" an error message (in contrast to the scenario where
> you do something else and suddenly an error message pops up)? And what
> is the exact text of the error message? Please elaborate.
>
> > Closing all workbooks and then reopening just the one which
> > failed usually lets it run successfully. So there must be some kind of
> > interaction at the macro level between these workbooks.
>
> It could be very well be that different worksheets are trying to
> operate on the same set of files. This would lead to Access Denied
> errors.
>
> > Some of the
> > modules occur in more than one Excel workbook and there may be common
> > sheet names as well.  I was wondering if there is a way to isolate the
> > macro, in either code or some other way, so it only interacts with its
> > parent workbook or whether this should be happening anyway?  
>
> I don't think that it is possible to restrict Excel's macro processor
> in such a way that macros can only manipulate the worksheet that they
> belong to (I'm not an expert in these matters, maybe Office 2007 and
> later offer such functionality). As far as I know, any macro can
> manipulate any workbook (and even the code in other workbooks, see my
> previous answer).
>
> > Perhaps a
> > better way of implmenting workbooks in such an environment is
> > required? VSTO perhaps?
>
> I can imagine that VSTO should make anything better with regard to
> your problem. I just guess that you'll have to find out what is going
> wrong by yourself (which is usually the hardest part of programming).
>
> Good luck,
> Stuart

-- 
----------------------------------------------------------------------------------
Some important links for excel users:
1. Follow us on TWITTER for tips tricks and links : 
http://twitter.com/exceldailytip
2. Join our LinkedIN group @ http://www.linkedin.com/groups?gid=1871310
3. Excel tutorials at http://www.excel-macros.blogspot.com
4. Learn VBA Macros at http://www.quickvba.blogspot.com
5. Excel Tips and Tricks at http://exceldailytip.blogspot.com
 
To post to this group, send email to [email protected]

<><><><><><><><><><><><><><><><><><><><><><>
HELP US GROW !!

We reach over 7000 subscribers worldwide and receive many nice notes about the 
learning and support from the group.Let friends and co-workers know they can 
subscribe to group at http://groups.google.com/group/excel-macros/subscribe

Reply via email to