how can I make a runtime version of an access database that uses o

  • Thread starter Thread starter Dr. Koops
  • Start date Start date
D

Dr. Koops

I have an database that uses msoutl.olb, the outlook object library for the
date() objects. It also uses some object from the word library.
I have bought Office 2007, for the sole purpose as to be able to create the
runtime version of my database.
Now it seems that the database can obnly work on systems that do have ms
word and ms outlook installed.

is there any way to compile the office objects into the run time version of
the database?

Thanks in advance for your answer,

Dr. M.C. Koops
 
Not only is it not possible to compile Office objects into an Access
application (regardless of where you're using the run-time), distributing
files like msoutl.olb is illegal.
 
Douglas J. Steele said:
Not only is it not possible to compile Office objects into an Access
application (regardless of where you're using the run-time), distributing
files like msoutl.olb is illegal.
Click to expand...

I understand that, but is it not possible (and legal) to reference the
msoutl.olb that's already on the user's sytem if they have Office/Outlook
already installed? For instance, I'm developing with Access XP (ACC10) so
the Outlook Object Library is located here:

c:\Program Files\Microsoft Office\Office10\msoutl.olb

I'm assuming that if my application is installed on a system that has
Outlook XP already installed it will run "out of the box" if it finds
msoutl.olb in that subdirectory, right? (Btw, I'll be distributing my
application as an MDE front-end and an MDB back-end, in case that makes a
difference?)

This brings up another question... If the user has Access/Outlook 2003 or
2007 installed, is it possible to programmatically search for msoutl.olb on
their system, change the reference to point at that library, and have the
application run properly? Or, will my application *only* run on an
Access/Outlook XP (2002) system? (Btw, I'm assuming that my application will
*not* run on anything earlier than Access/Outlook XP, right?)

If the answer to that last question is that it will run so long as the
reference is changed, can someone explain how to programmatically change the
reference? I'm assuming that'd be a DAO routine, right?

Thanks, in advance, for any advice and assistance given.

Regards, Chris
 
Chris said:
I understand that, but is it not possible (and legal) to reference the
msoutl.olb that's already on the user's sytem if they have
Office/Outlook already installed? For instance, I'm developing with
Access XP (ACC10) so the Outlook Object Library is located here:

c:\Program Files\Microsoft Office\Office10\msoutl.olb

I'm assuming that if my application is installed on a system that has
Outlook XP already installed it will run "out of the box" if it finds
msoutl.olb in that subdirectory, right? (Btw, I'll be distributing my
application as an MDE front-end and an MDB back-end, in case that
makes a difference?)

This brings up another question... If the user has Access/Outlook
2003 or 2007 installed, is it possible to programmatically search for
msoutl.olb on their system, change the reference to point at that
library, and have the application run properly? Or, will my
application *only* run on an Access/Outlook XP (2002) system? (Btw,
I'm assuming that my application will *not* run on anything earlier
than Access/Outlook XP, right?)

If the answer to that last question is that it will run so long as the
reference is changed, can someone explain how to programmatically
change the reference? I'm assuming that'd be a DAO routine, right?
Click to expand...

Search these groups for "Late Binding". It accomplishes exaclty what you
are describing although not in the manner you describe. It is the only
practical way to use external libraries in a distributed app. Basically it
is a way to utilize external code libraries without setting a reference to
them.
 
Rick Brandt said:
Search these groups for "Late Binding". It accomplishes exaclty what you
are describing although not in the manner you describe. It is the only
practical way to use external libraries in a distributed app. Basically
it is a way to utilize external code libraries without setting a reference
to them.
Click to expand...

Tony Toews has some introductory material on Late Binding at
http://www.granite.ab.ca/access/latebinding.htm
 
Thank you Douglas (and Rick) for that information. Tony's material on late
binding was VERY helpful! I'm not doing anything really esoteric... just
using DAO and some basic Outlook automation (create appointment, create
contact, etc.), so late binding is probably the way to go.

Btw, while searching the late/early binding topic, I stumbled upona VERY
helpful article on VBA error handling by Allen Browne that will also be
useful in my application. I mention it here because Allen's error logging
routine will help me track down errors (including those related to library
bindings) much easier.

http://www.allenbrowne.com/ser-23a.html

Thanks, again, for the pointers!

Regards, Chris
 
I spent this evening converting a couple of my Outlook routines to use late
binding. That is REALLY cool!!!! I do hope Dr. Koops is still reading this
thread because even though it doesn't resolve his original problem (i.e. you
still can't bind to an object library that just isn't there) it sure does
make it simpler to deal with multiple versions of a library that is there!

Anyway, I have one more little question regarding the subject of early/late
binding...

In Access 2002/XP, the ADO library is the default and I had to manually
create a reference to the DAO library. I'm assuming I can use late binding
with the DAO library as well, right? If that's the case, then the only
libraries I really need an explicit reference to are the required ones:
Access, VBA, OLE and ADO. Right?

Thanks, again, for all the help! I'm learning SO much! And, someday, I
might actually get this application finished! :D ;)

Regards, Chris
 
While I believe it's possible to use late binding with DAO, realistically I
think it should be added as a reference. It was a stupid decision on the
part of Microsoft not to include it by default in Access 2000 and 2002: they
corrected the error in Access 2003 (and, of course, it's in Access 2007 by
default as well)
 
I'm trying to make my application as "idiot proof" as possible because,
frankly, the target audience of my application is computer illiterates.
(Don't tell them I said that! <grin!>)

Is there *any* scenario where the DAO library is *not* going to be on the
end user's computer, or some other problem where my application will totally
blow-up if I early bind to DAO? Or, is it fairly "safe" to just go ahead and
early bind to it? I just want to be sure that there's as few
install/operating problems as possible for my users.

Thanks, again, for all the patience and help!

Regards, Chris
 
There's definitely no way that DAO won't be on the computer. I suppose it's
possible that you could run into a versioning problem. I know that used to
happen in Access 97 (going from DAO 3.50 to DAO 3.51), but I don't believe
it's an issue in newer versions.
 
Douglas J. Steele said:
There's definitely no way that DAO won't be on the computer. I suppose it's
possible that you could run into a versioning problem. I know that used to
happen in Access 97 (going from DAO 3.50 to DAO 3.51), but I don't believe
it's an issue in newer versions.
Click to expand...

I'm not so much worried about versioning issues, as I'm not doing anything
esoteric and *surely* there aren't many Access 97 systems still out there
(right?). I'm more
worried about the DAO library not being there at all (and you've reassured
me that it likely will be) or that it'll be in a weird place.

If I create a reference in my MDE that points to the directory where the
library resides on my system and an end user has it in another directory, is
that going to blow-up if I use early binding? If so, won't late binding
prevent this as the app will locate the library via the v-table? Is this
scenario likely to even happen, or does the Office/Access install procedure
always put the library in the same place?

I apologize for (maybe?) asking too many questions, but this early and late
binding stuff is very new to me and somewhat confusing. I just want to make
sure I "get it right" so there won't be problems down the road.

Thanks, again, for your patience and answers.

Regards, Chris

P.S. Btw, I took a look at your site on accessmvp.com today. Looks like
some *really* interesting stuff on there that I'll have to take a look at in
the next few days. Thanks fo contributing so much to the Access community!
 
Oh, I think you might be surprised at how many Access 97 databases are out
there.

In a lot of cases you see
"It works and I don't want to muck with it."
In some cases, you see
"I'm not spending any money to upgrade my software."
In some case, you see
"I'm not spending any money to buy new hardware."

John Spencer
Access MVP 2002-2005, 2007-2008
The Hilltop Institute
University of Maryland Baltimore County

Chris O''''Neill wrote:
 
We're still using Access 97. We've got approximately 100,000 desktops
world-wide...
 
Chris O''''Neill said:
I'm more worried about the DAO library not being there at all (and you've
reassured
me that it likely will be) or that it'll be in a weird place.

If I create a reference in my MDE that points to the directory where the
library resides on my system and an end user has it in another directory,
is
that going to blow-up if I use early binding? If so, won't late binding
prevent this as the app will locate the library via the v-table? Is this
scenario likely to even happen, or does the Office/Access install
procedure
always put the library in the same place?
Click to expand...

DAO is a system file: the user can't put it somewhere else. By default,
it'll be in C:\Program Files\Common Files\Microsoft Shared\DAO, although if
the system has Program Files defined to be somewhere else, it will
(obviously) be somewhere else. However, Access will find it if it was
installed somewhere else.
 
John (and Douglas):

I was just kidding about there probably not being many Access 97
installations out there in the real world. I'm a classic example of the "if
it ain't broke don't fix it" crowd... I've been using Pegasus Mail since the
MS-DOS days. Even though it's now orphaned (too bad!) I continue to use the
last version because it works, it does what I want/need, and I'm used to it.

Now that I'm creating this application which uses Outlook (like 99% of the
rest of the world), I'll probably bite the bullet and switch, as it's not
practical to use Outlook for this app and Pegasus for everything else.
However, I'm still agonizing about finally leaving my precious Pegasus
behind. :(

Regards, Chris
 
Douglas J. Steele said:
DAO is a system file: the user can't put it somewhere else. By default,
it'll be in C:\Program Files\Common Files\Microsoft Shared\DAO, although if
the system has Program Files defined to be somewhere else, it will
(obviously) be somewhere else. However, Access will find it if it was
installed somewhere else.
Click to expand...

Okay, you've put my mind to rest. I'll leave the reference to DAO and early
bind to it, and hope there's no problems.

Thanks, again, for all your help and advice. You've been VERY helpful!

Regards,

Chris

P.S. I finally took a wander through your "Access Answers" column
subdirectory on accessmvp.com and found a *bunch* of stuff that's gonna be
helpful to me... Thanks!!!!
 
Back
Top