microsoft excel 11,0 object library

[trevorC via AccessMonster.com]

HI All, My application currently uses a lib reference to the microsoft excel
11,0 object library, the db is on a server and has about 30 people hooked
into it. On one pc the OS is win XP and the lib file is microsoft excel 12,0
object library. When this person runs the db they gat the error message -
object lib not found. I can manualy go and change this as the microsoft excel
11,0 object library is also in the list but the default is 12.0 not 11.0 for
this pc. Do i need to download 11.0 and put it on the pc or is there a better
way ?.

 

[Tom van Stiphout]

HI All, My application currently uses a lib reference to the microsoft excel
11,0 object library, the db is on a server and has about 30 people hooked
into it.

That is a REALLY BAD IDEA and surely to cause a lot of grief over
time. Split the database and deploy the front-end to each workstation
per best practices.

On one pc the OS is win XP and the lib file is microsoft excel 12,0
object library. When this person runs the db they gat the error message -
object lib not found. I can manualy go and change this as the microsoft excel
11,0 object library is also in the list but the default is 12.0 not 11.0 for
this pc. Do i need to download 11.0 and put it on the pc or is there a better
way ?.

Do you need any more evidence of the above statement?

-Tom.
Microsoft Access MVP

 

[trevorC via AccessMonster.com]

Thanks for the reply,
that sounds like an easy option, i guess the front end is just a new copy of
the db but with linked tables ?.
And only required for the problem pc, only one is doing it and it's the MD's,
he likes to fiddle a bit.

 

[dymondjack]

i guess the front end is just a new copy of

the db but with linked tables ?.

Close. The front end is everything except tables and relationships, and the
back end is only tables and relationships. They are quite easy to split
(microsoft provides a handy wizard for this that works well).

As Tom mentioned, you should do this all the time. There are umpteen
different issues that will come up with having everyone link to one file, and
a complete loss of data and/or irrecoverable corruption is one of them.
Always keep your data in a backend, never let your users directly access it.
This will even keep your 'tinkerer' from being able to change any table or
relationship properties.

I could easily write a 5000 word essay on good reasons to use split
databases, but I'll just leave with a strong caution to do this for every
user of your db.

--
Jack Leach
www.tristatemachine.com

- "Success is the ability to go from one failure to another with no loss of
enthusiasm." - Sir Winston Churchill

 

[trevorC via AccessMonster.com]

Thankyou for the extra information on this.

 

[Tony Toews [MVP]]

HI All, My application currently uses a lib reference to the microsoft excel
11,0 object library, the db is on a server and has about 30 people hooked
into it. On one pc the OS is win XP and the lib file is microsoft excel 12,0
object library. When this person runs the db they gat the error message -
object lib not found. I can manualy go and change this as the microsoft excel
11,0 object library is also in the list but the default is 12.0 not 11.0 for
this pc. Do i need to download 11.0 and put it on the pc or is there a better
way ?.

1) Yes, you should split the MDB into a Front End MDB containing the
queries, forms, reports, macros and modules with just the tables and
relationships in the Back End MDB. The FE is copied to each network
users computer. The FE MDB is linked to the tables in the back end
MDB which resides on a server. You make updates to the FE MDB and
distribute them to the users, likely as an MDE.

See the "Splitting your app into a front end and back end Tips" page
at http://www.granite.ab.ca/access/splitapp/ for more info. See the
Auto FE Updater downloads page
http://www.granite.ab.ca/access/autofe.htm to make this relatively
painless.. The utility also supports Terminal Server/Citrix quite
nicely.

2) Late binding means you can safely remove the reference and only
have an error when the app executes lines of code in question. Rather
than erroring out while starting up the app and not allowing the users
in the app at all. Or when hitting a mid, left or trim function call.

This also is very useful when you don't know version of the external
application will reside on the target system. Or if your organization
is in the middle of moving from one version to another.

For more information including additional text and some detailed links
see the "Late Binding in Microsoft Access" page at
http://www.granite.ab.ca/access/latebinding.htm

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/

 

[Tony Toews [MVP]]

only one is doing it and it's the MD's,
he likes to fiddle a bit.

Managing Director? Oh dear.

Is he the standard power user who creates queries and reports to get
out data that just he needs or does he muck with your app?

If a power user given him his own MDB linked to the tables.

If he mucks with the app, well best wishes.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/

 

[Jaek]

I read the threads on splitting the database, all very true, split databases
or no databases... but in fact I'm wondering if this is going to help Trevor
C with his specific problem?

I have a split db and ran into the same problem with one of my users (but
with the Office lib - MSO.dll). He had version 11 and my app points to 12.
When the application (frontend) loads, it looks for the .dll in the user's
local Common Files folder and can't find it -- that's going to be the case
whether the app is split or not, isn't it?

I'm not quite bright enough to follow along on the question of late binding,
I do rely on the blunt-force approach myself, although I got the impression
from the post that late binding only forestalls the issue until the user
trips across the code calling to the .dll file? Again, doesn't Trevor still
have to get his user's local .dll updated one way or another?

I finally just resorted to dropping a copy of the entire Office 12 folder
with the various .dll files on my user's drive - maybe there was a more
elegant way to do it?

These are my notes from the issue I was having:

MSO dll is referenced in Access as 'Microsoft Office 12'. Pete is getting a
broken reference error msg on open and then having weird spotty errors when
he continues.

MSO.dll is located in the OFFICEXX folder in C:\Program Files\Common Files\
Microsoft Shared\

I'm working with OFFICE12 (MSO.dll version 12.0.6320.5000), but Pete has
OFFICE11 file in his directory (MSO.dll version 11.0.6360.0), and this is
apparently the problem.

I dropped a copy of the OFFICE12 folder in Pete's directory and this
appeared to work.

 

[trevorC via AccessMonster.com]

Thakns Jaek,
I've been to busy to get back to this problem for now, so i told the boss he
needs a new pc. this will fix the problem !. But i am still going to try the
various solutions aired here just to get the exrta exprerience.

 

[Tony Toews [MVP]]

I read the threads on splitting the database, all very true, split databases
or no databases... but in fact I'm wondering if this is going to help Trevor
C with his specific problem?

No, splitting the database will not help with his specific problem.
However late binding will.

I have a split db and ran into the same problem with one of my users (but
with the Office lib - MSO.dll). He had version 11 and my app points to 12.
When the application (frontend) loads, it looks for the .dll in the user's
local Common Files folder and can't find it -- that's going to be the case
whether the app is split or not, isn't it?

I'm curious as to what you were using mso.dll for? We can likely
suggest some alternatives.

I'm not quite bright enough to follow along on the question of late binding,
I do rely on the blunt-force approach myself, although I got the impression
from the post that late binding only forestalls the issue until the user
trips across the code calling to the .dll file? Again, doesn't Trevor still
have to get his user's local .dll updated one way or another?

Yes, late binding does not solve the problem where Excel is not
installed on the users system. But at least the rest of his app will
continue to work. If the user has a different version of Excel it
will work very well. Unless, of course, you are using some
functionality in a newer version of Excel than is in the users older
version of Excel.

I finally just resorted to dropping a copy of the entire Office 12 folder
with the various .dll files on my user's drive -

This is likely against the terms of the EULA.

maybe there was a more elegant way to do it?

What were you using the mso.dll for?

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/

 

[Jaek]

Thanks very much Tony -
You know I never even considered that I was violating the EULA by copying
those files, not very cool.
You definitely cut to the heart of the matter though which is that in my
case I did not need the mso.dll at all, and could not tell you why I had
inserted the reference in the first place. This finally dawned on me, I
removed the reference to the library altogether, and so far so good.
However, if I run into something more like Trevor's issue with the Excel
reference it might be a different story because I do some automating to Excel
and one of the main functions of my app is to get stuff out to spreadsheets.
Is the only (legal) answer to this kind of broken reference to have a user up
or downgrade their version of office?
Thanks again to all this is an interesting discussion.

 

[Tony Toews [MVP]]

Thanks very much Tony -

You're welcome.

You definitely cut to the heart of the matter though which is that in my
case I did not need the mso.dll at all, and could not tell you why I had
inserted the reference in the first place. This finally dawned on me, I
removed the reference to the library altogether, and so far so good.

Occasionally, like once a year or two although not recently. You did
compile the code, right?

However, if I run into something more like Trevor's issue with the Excel
reference it might be a different story because I do some automating to Excel
and one of the main functions of my app is to get stuff out to spreadsheets.
Is the only (legal) answer to this kind of broken reference to have a user up
or downgrade their version of office?

No. Again late binding takes care of the different versions of Excel
problem. Do note though that I have one, longish, routine which
takes a recordset and moves it to Excel. I call that one routine
everywhere so I only need to make changes in that one routine when
making it late binding.

(I really need to post that routine to my website as it does a *lot*
of interesting things such as removing primary autonumber fields or
specified fields from the Excel spreadsheet.)

Tony


--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/