[AccessD] Set references via automation

Mark Simms marksimms at verizon.net
Sun Jan 1 19:11:14 CST 2012


Interesting idea John.
My latest Excel project has 12 references....so the chance for object
duplicity is high.

> -----Original Message-----
> From: accessd-bounces at databaseadvisors.com [mailto:accessd-
> bounces at databaseadvisors.com] On Behalf Of jwcolby
> Sent: Sunday, January 01, 2012 2:55 PM
> To: Access Developers discussion and problem solving
> Subject: Re: [AccessD] Set references via automation
>
> http://www.trigeminal.com/usenet/usenet026.asp
>
> Notice if you fully path all functions you can avoid all of that stuff.
>
> 2) Make every function call to the VBA or Access libraries explicit so
> that VBA never needs to
> disambiguate. To do this, always use Access.*, Access.Application.*,
> VBA.*, etc. in front every call
> (e.g. VBA.Left$ instead of Left$, VBA.Trim instead of Trim).
>
> John W. Colby
> Colby Consulting
>
> Reality is what refuses to go away
> when you do not believe in it
>
> On 1/1/2012 11:20 AM, Charlotte Foust wrote:
> > The problem is as mentioned above:  if the references are not
> modified
> > before any other code is loaded, they will be broken and will stay
> that
> > way.  However,  if you are opening the database remotely, I have no
> idea of
> > the sequence of events.  I would suspect you'd run into the same
> issues.
> > To make it work in a 2002/2003 version, you had to reference the VBE
> > library and use its methods because you can't use DAO or ADO and VBA
> to fo
> > this.
> >
> > Charlotte
>
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com




More information about the AccessD mailing list