Developer Tools Backwards Compatibility

G

Guest

I have developed an Access application with Access 2003. I have successfully
converted the mdb to Access 2000 format and it will run (as an mdb or mde)
under Office 2000 Access 2000.

My question is: If I use the packaging tool from Visual Studio Tools For
Microsoft Office to create a distributable package, will it run under
different operating systems i.e Win 98, 98SE, 2000, NT

I will assume it would run under XP as that is what I am running when I
create the package.

I used the Packaging and Deployment add in of Visual Studio.net to creat a
package and tried to install it on a Win 98 SE test system and it corrupted
the O so bad I had to reformat and reinstall Win 98 SE.

Any help appreciayed.

Thanks

Ray
 
T

Tony Toews [MVP]

Ray said:
My question is: If I use the packaging tool from Visual Studio Tools For
Microsoft Office to create a distributable package, will it run under
different operating systems i.e Win 98, 98SE, 2000, NT

No. A2003 only runs under Win 2000 SP3, Win XP or newer.
I used the Packaging and Deployment add in of Visual Studio.net to creat a
package and tried to install it on a Win 98 SE test system and it corrupted
the O so bad I had to reformat and reinstall Win 98 SE.

I wouldn't have expected it to corrupt the OS but past postings
indicate that while it will install on older OSs it won't execute.

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
 
D

Douglas J. Steele

Access 2003 will not run on anything earlier than Windows 2000, SP3 (I
think).

It definitely will not work on Win 98, Win 98SE or Win NT.
 
A

Albert D. Kallal

Ray said:
I have developed an Access application with Access 2003. I have
successfully
converted the mdb to Access 2000 format and it will run (as an mdb or mde)
under Office 2000 Access 2000.

My question is: If I use the packaging tool from Visual Studio Tools For
Microsoft Office to create a distributable package, will it run under
different operating systems i.e Win 98, 98SE, 2000, NT

I think you are very much confused as to how the runtime works. The runtime
system is simply a stripped down version of ms-access.

All of the SAME problems of installing multiple versions of ms-access on a
target machine will remain when you use the access runtime. If the runtime
is to be compatible with the full version..then you can well bet that all of
the same problems exist.

Many of us simply install the runtime first, and then you can simply copy
any mde, or mdb onto the machine..and it will run. There is no "special"
case when you use the runtime, or somehow the runtime knows about your
particular mde/mdb. The mde, or mdb you distribute is NOT MODIFIED in any
special way. you simply place that mdb/mde on the target machine..and you
can then double click on it..and ms-access will launch. This is EXACTLY the
same for the runtime.

Since you talking about access 2003, well, access 2003 don't work nor
install in windows 98. So, the exact same case applies for the runtime
system. it is a FULL version of access...but only the design tools are
removed. (the access 2000 runtime used to be 150 megs in size, and requite a
re-boot of your machine during install). Make no assuming, or no mistake
here..you are install a very large version of ms-access on that target
machine. After you install the runtime, then you can copy your mdb, or mde
to that target machine. You don't have use a mde, and further there is no
special relationship between the runtime you install, and the copying of a
mde, or mdb file to run on that machine (it just happens that often people
package the mde/mdb along with the runtime install..but, there is little, or
no requirement to do this).

What is means that virutally ALL OF THE MANY problems that exist when you
install ms-access ona mchine that ALREADY has a verison remains. Remember,
the runtime is the same, and comptable..and that means the SAME probelms. If
you install on an existing mahcine that is runing a differnt verison of
sma-ccess, when they click on a mdb..they will laucning your runtime now. It
is VERY messy to install ms-access on a machine that already has a differnt
version. The mess that is creating by installing ms-access is EXACLTY the
same for the rntime..since it is the SAME program you are intsalling.

You cannot consider installing the access runtime on a target machine that
already has ms-access on it.

If you really must do this, then you need a way to install ms-access without
interfering with the existing version. The only way to do this is to
purchase some install scripts. You can fine some here:

www.sagekey.com
 
G

Guest

Thank you Albert,

You have been helpful.

I am in Terrace BC so we are at least fellow Canadians.

If I understand you corrrectly, I should do the following.

IF I AM DISTRIBUTING MDB OR MDE ONLY TO MACHINES WITH ACCESS ALREADY
INSTALLLED.

Convert my Access database to Access 2000 file format so it will run under
Access 2000 runtime. This would allow it to run on Win 98 machines.
Also it would run on Newer Access 2003 systems because they could load the
mde file as a previous version and use it.

IF I AM DISTRIBUTING RUNTIME TO MACHINES WITH NO ACCESS ALREADY INSTALLLED.

I should use the Package and Deploy Add In from Office 2000 to make a run
time installation that will run on either Win 98 or Win XP or Win 2000.

So what would be the logical way to distribute this application?

... On a CD with multiple install choices?

This is driving me nuts. I already have this sold but if I can't get all
this distribution stuff "legally" worked out the sale will fall through and I
will just have to "give it away free" which will be a real piss off after
developing it for almost a year.

Any help appreciated.

Ray
 
D

Douglas J. Steele

Ironically, all 3 of the people who have responded to you so far are
Canadian! <g>

I think you may has misinterpretted what Albert's told you. The only way you
can "use the Package and Deploy Add In from Office 2000 to make a run time
installation that will run on either Win 98 or Win XP or Win 2000" is if you
own Office 2000 Developer Edition. Office Professional does not give you
this capability.
 
G

Guest

I do own the 2000 developer edition but I think the packaging and deployment
wizard sucks. Thought the new version (2003) had many improvements but I
guess it was a waste of time.

Ray
 
A

Albert D. Kallal

IF I AM DISTRIBUTING MDB OR MDE ONLY TO MACHINES WITH ACCESS ALREADY
INSTALLLED.

Convert my Access database to Access 2000 file format so it will run under
Access 2000 runtime. This would allow it to run on Win 98 machines.
Also it would run on Newer Access 2003 systems because they could load the
mde file as a previous version and use it.

Yes, but I not sure why you mention the a2000 runtime in the above. Since
you are saying that users will already have a version of access, then you
don't want to install he runtime. While the runtime system is smart, and
will NOT install the runtime if access 2000 is already on the machine, no
such luck if that machine has 2002, or 2003 on it...your a2000 runtime will
install. then, from that point on, all users who click on their mdb's on
that machine will not be launching a2000...not their a2002, or a2003 that
they want.

However, yes...I agree that if the user has a2000 to a2003..then you can
give them a a2000 mde..and it should work ok. I would just setup a install
that checks for a version of access (2000-2003)..and if found..ten installs
your a2000 mde (that you plan to distribute to all users).

So, that a2000 mde should install and run fine on machines that have 2000 to
a2003.

IF I AM DISTRIBUTING RUNTIME TO MACHINES WITH NO ACCESS ALREADY
INSTALLLED.

I should use the Package and Deploy Add In from Office 2000 to make a run
time installation that will run on either Win 98 or Win XP or Win 2000.

Yes, the above makes sense. I for my installs and updates always keep the
runtime install separate. This makes the internet download very short. On
the other hand...with just about everyone having high speed, I find
deploying the 34 meg a2003 runtime only takes a few minutes. Usually 2-8
minutes max. Today..it took the client only about 2 minutes (in fact, I just
did that today).

By keeping the mde install separate, then I can easily provide updates to
users in eh field. The end result is the following set of screen shots for
users to update their software:

http://www.kallal.ca/ridestutorialp/upgrade.html

My access routines has a built in download. Since you going to need to
provide updates, then I suggest you build a script that allows the front end
to be installed, setup the shortcuts on the desktop etc. I don't use the
access package wizard, but use the inno installer.

This setup routine should work for a2000 to a2003 users. My setup actually
checks for if the runtime files are installed..and if not..the user is
instructed to download and install a runtime package I made. However, that
runtime is a separate install.
So what would be the logical way to distribute this application?

.. On a CD with multiple install choices?

With a inno script...a cd would work great. I use the web, but that because
I easier then sending out a cd...

note well that just today...I started receiving calls and installs by people
using Vista with my software. Any new computer will have Vista...so, I
assume you been testing for that also...
This is driving me nuts. I already have this sold but if I can't get all
this distribution stuff "legally" worked out the sale will fall through
and I
will just have to "give it away free" which will be a real piss off after
developing it for almost a year.

I use the open source inno installer to setup the desktop shortcuts, and
test if access is installed (the test for full version, or runtime is
actually the SAME test). It would not be that hard to setup a installer to
check for if access is installed, and if not...go ahead and installs the
a2000 runtime. That should cover all your above cases.

I also assume that you split you database...else how are you going to
provide ease updates for you end users? You are split right?

If you don't want to develop some the above ideas..then just go with
sagekey....

www.sagekey.com

Those sagekey scripts actually allow you to install access 2000 runtime on
existing machines..and keep everything separate.
 
T

Tony Toews [MVP]

Ray said:
I am in Terrace BC so we are at least fellow Canadians.

If I'm ever out that way again I'll look you up. I spent a lot of
time up in Stewart, BC about 25 years ago.

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
 
T

Tony Toews [MVP]

Ray said:
I do own the 2000 developer edition but I think the packaging and deployment
wizard sucks. Thought the new version (2003) had many improvements but I
guess it was a waste of time.

No, if anything it has lost one or two features.

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
 
T

Tony Toews [MVP]

Douglas J. Steele said:
Ironically, all 3 of the people who have responded to you so far are
Canadian! <g>

So far an all Canuck thread. Whoohoo.

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
 
G

Guest

This is all so confusing to me. This is my first attempt at distribution
although I have been creating Access databases for years and even teach
Access at NWCC but have never got into the deployment side.

I developed this particular application for our location but when the
regional guy saw it they want to use itthroughout the organization and
offeref to buy it from me.

I was pretty excited about that until I got into all od this.

I am almost ready to just give up on the whole thing.

Ray
 
G

Guest

Albert,

I am also visually impaired and have a hard time reading some of these
posts. Could I contact you by phone.

I dont want to leave numbers here but you can email me direct at
(e-mail address removed) with info.

Thanks a lot.

Ray
 
G

Guest

I had a look at the Sage site. It looks pretty good. I assume I already
have to have a copy of the runtime for Sage to install it. Do you use Sage?

Ray
 
A

Albert D. Kallal

Ray said:
I had a look at the Sage site. It looks pretty good. I assume I already
have to have a copy of the runtime for Sage to install it. Do you use
Sage?

Ray

No, I not used sagekey, but a number of articles state that it keeps your
application separate...even when a existing versions of ms-access is
installed.

By the way, it is assumed you been deploying a split database...right?

else, how do you plan to offer updates and bug fixes in the field?
 
T

Tony Toews [MVP]

Ray said:
I had a look at the Sage site. It looks pretty good. I assume I already
have to have a copy of the runtime for Sage to install it. Do you use Sage?

There have been many favourable comments about Sagekey over the years
in the newsgroups.

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
 
T

Tony Toews [MVP]

Ray said:
25 years ago I cant imagine much was going on in Syewart except mining then?

Exactly. No idea what is going on there now of course. Esso
Resources had purchased the copper mine thirty or forty miles up the
road a few years before and needed changes made to some software. IBM
System/34 and RPG II.

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
 
G

Guest

Hi Tony,

I know this is not the right category but hope you might help me with this
problem.

I have a set of constantly changing tables that are modified by count
queries. My problem is that depending on the underlying data some of the
queries may return 0 recors and as a result leave me with tables that have no
records in them. This causes my reports naturally to return #error messages.

Below is what is currently happening.
=====================================
Here is my problem.

I have a database full of members with a field called [Year Paid]
I used queries that use the Year Paid field to count paid up members.
I have preset a table with a Member Type and a CountOfType preset to 0
1. Because the option is there to run this report based on different years,
I first

1. Run a query that sets all the counts back to zero

This leaves me with a table like this
TYPE COUNTOFTYPE
LF 0

2. Run an append query that filters the database by the year entered into a
form.

This leaves me with a table like this
TYPE COUNTOFTYPE
LF 0
LF 10

3. Run an delete query that deletes the records with a 0 count.

This leaves me with a table like this
TYPE COUNTOFTYPE
LF 10

Which one would think would be perfect for my report BUT

If my Append query returns no results the following happens.

1. My table with presets looks like this,
TYPE COUNTOFTYPE
LF 0

2. Run an append query that filters the database by the year entered into a
form.\
BUT DOES NOT FIND ANY APPLICABLE RECORDS so will not append anything

This leaves me with a table like this (My Original)
TYPE COUNTOFTYPE
LF 0

3. Run an delete query that deletes the records with a 0 count.

This leaves me with a table like this
No Records

Which causes all kinds of errors in my reports and leaves me with only a few
hairs left on my head.

============================

I thought I could resolve this by writing a function that would use DCount
to determine if there were no records in the table and if not just update
with a reset to 0. But I cant seem to get the syntax right. My code is
below:

Function Add_Zero_Record()

Dim MM3
Dim AVTBL3
MM3 = "Member Management"
AVTBL = "Total AV Unpaid"

Set MM3 = CurrentDb
Set AVTBL = MM3.OpenRecordset("Total AV UNPaid")

If DCount("CountOf Type", "Total AV UNPaid",< 1) Then
AVTBL.AddNew
AVTBL("Type").Value = "AV"
AVTBL("CountOfType").Value = "0"
AVTBL.Update
End If

End Function

I am not much of a VB programmer as you can see but I thought this would
work if I called the code at the end of my macro that runs the delete and
append queries just to test for blank tables and reset them to 0. Naturally
I would add all five of them to the function if I could get it to work.

Any help greatly appreciated.

Ray

p.s. As for Stewart .. even the mines are closed now. It is pretty much a
ghost town. BC Northwest is, contrary to what you hear about BC economy, in
the dumps. Here in Terrace our big mill is in the process of being cut up
for scrap. Most of the Forest Industry is gone from the coast as far inland
as Smithers at least, although things are still booming east of that into
Prince George and south.

Take care.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top