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