Re: Distributed Access references

• Previous message: Douglas J. Steele: "Re: Runtime and ActiveX controls"
• In reply to: Bruce M. Thompson: "Re: Distributed Access references"
• Next in thread: Bruce M. Thompson: "Re: Distributed Access references"
• Reply: Bruce M. Thompson: "Re: Distributed Access references"
• Messages sorted by: [ date ] [ thread ]

Date: Tue, 16 Mar 2004 15:44:10 -0800

Bruce,

What you are saying would seem inconsistent w/ what the
packaging wizard does. And for sure its not what I
understand from trying to package an app and working w/
no less than 3 MS access professionals who helped create
my first distributed access.

Although it appears that the excel does get packaged by
the wizard, as I said it will not run on the target
computer. So my app relies on the user having their own
excel to be run from my app. My understanding was I was
not shipping excel so much as library functions that
would only work if the user had their own working copy.

About the other libraries, if I cannot include them, then
that would mean I can only distribute the simplest of
applications. This is not the message I got working w/
MS pros.

So relative to the files below you say I should not
package, I do not understand what my recourse is ? I
cannot use them ? So a huge chunk of my application will
not work ?

Bottom line relative to all my references is if I do not
reference them, my app won't compile. And if I do not
ship them my app will not run on target computer.

I am following the suggestion to late bind excel. Since
I really do not use any special functionality that would
not be in excel 95, I guess that means any target
computer that has excel should be able to run ok.

As for the other references I am not sure what to do ?
Can they all be late binded ?

I would like to hear someone from MS explain why they
would build a software package and allow it to illegally
package their own software to re-distribute w/ access,
which I paid over $1000 for the right to re-distribute.

Thanks for the discourse
its more than I can get out of MS anymore.
I have used up my two free helps, and now I would have to
pay to have them explain how their software works. That
lights me up every time I even think about it. I liked
the old days when you got a manual !

Bob

>-----Original Message-----
>> >What kinds of "reference files" do you speak of? Are
>> these custom controls?
>> >Custom libraries? Or is this just where Access stores
>> the information about the
>> >references that you have set? I've never changed any
>> locations from their
>> >defaults, so I'm not sure what you mean here.
>> >
>>
>> Here are some:
>>
>> 1) Path_to_package/MyApp.mde
>
>***That one's okay - it's your application file.
>
>> 2) C:\ Windows\system\scrrun.dll
>
>***You shouldn't be distributing this one, it's a
windows file and should
>already exist on the client machine.
>
>> 3) Path_to_package/MyApp_data.mdb
>> 4) Path_to_package/MyAppIcon.bmp
>
>***These are okay - they, again, are related strictly to
your application.
>
>> 5) C:\Program Files\Common Files\Microsoft
Shared\VBA\VBA6
>> \VBE6.DLL
>> 6) C:\Program Files\Common Files\Microsoft
>> Shared\DAO\dao360.dll
>> 7) D:\Program files\msofficexp\Office10\MSACC.OLB
>> 8) D:\Program files\msofficexp\Office10\EXCEL.EXE
>> 9) C:\Program Files\Common Files\SYSTEM\ADO\msado15.dll
>> 10) C:\Program Files\Common Files\SYSTEM\ADO\msadox.dll
>> 11) C:\Program Files\Common Files\Microsoft
>> Shared\Office10\Mso.dll
>
>***No, No, No!! You have no license to distribute these
files. They are Office
>files and can only be installed by the client from their
Office install disks.
>
>>
>> 2 above supports:
>> Dim fs As FileSystemObject
>
>***All versions of Windows that will run Office 10
(XP/2002) will have the
>necessary files to run scripts that support the
FileSystemObject.
>
>> 8 above supports references to excel goodies
>
>***If they don't already have Excel, then that's a
problem, but you have no
>license to distribute any such files.
>
>> 9-11 were to support tools I was trying to implement to
>> do upgrades on myapp_data.mdb
>
>***Access already includes the basic development
capabilies - you don't need to
>(and aren't licensed to) copy them from your machine to
theirs.
>
>> >You *cannot* legally distribute Excel with your
>> project!! If you are
>> >implementing features from other Office programs, then
>> your client must have MS
>> >Office installed separately on the systems that will
use
>> your application. I
>> >suspect that, if you are copying anything Excel-
related,
>> it is just the
>> >executable, which will not run on its own. Any
>> references that you have set in
>> >your project will carry over to the client install,
but
>> doesn't, by virtue of a
>> >reference alone, cause a copy of any other program to
be
>> copied over to the
>> >install package.
>> >
>>
>> well, w/o the ref, the excel stuff would not work, but
if
>> the client does not have excel, they are still out of
>> luck cuz the one that I attach can't run on the target
so
>> I guess I really am not distributing it.
>
>***The reference is not the problem. Copying Excel files
from your machine to
>theirs *is* the problem. If they don't have Excel on
their workstations, then
>you will need to either code for this possibility or see
that they put a legal
>copy of it on the workstations from their Office install
disks. If they don't
>own MS Office, then they will need to buy it.
>
>--
>Bruce M. Thompson, Microsoft Access MVP
>bthmpson@mvps.org (See the Access FAQ at
http://www.mvps.org/access)
>>> NO Email Please. Keep all communications
> within the newsgroups so that all might benefit.<<
>
>
>.
>

• Previous message: Douglas J. Steele: "Re: Runtime and ActiveX controls"
• In reply to: Bruce M. Thompson: "Re: Distributed Access references"
• Next in thread: Bruce M. Thompson: "Re: Distributed Access references"
• Reply: Bruce M. Thompson: "Re: Distributed Access references"
• Messages sorted by: [ date ] [ thread ]