After reading and experiencing the phenomenon of installing MS Office
2000 on a system that already has MS Office 97, or for that matter
just Access 97 Runtime, I saw the ugliness that ensues. If one elects
the standard installation, then Office 2000 deletes a large percentage
of the older files. Of course, if one happens to choose Custom
installation and elects not to uninstall prior versions, then things
are happier. Yes, the archives are nearly replete with related
information, but is it possible that something new has emerged on this
subject?
I have done my own custom installation scripts of Access 97 Runtime
and place the files in a new, separate folder under Program Files. If
installed after Office 2000, there is no problem, except that each
takes a bit of time to reregister itself at startup. I believe that I
read somewhere about modifying the .srg files for Access 97 to
overcome this issue. Is this true? And what steps are needed to
accomplish it?
Also, does installing Office XP and/or Office 2003 onto a system that
has a prior version (well, specifically 97) cause the same havoc as
Office 2000 noted above? Or was Microsoft more circumspect with the
development and deployment of the later two versions?
Not that I want to augment the finances of SageKey, but I have read
that their Wise installation scripts for Access 97 have been designed
to prevent later versions of Office from removing earlier ones. This
is an interesting twist, but how did they do it? Is there a way to
conceal the identity of the older Office files? Has anyone insight
into this matter? Although logic may not be in an abundance at
Microsoft, why would they not have taken the reverse approach to this
issue with the installation of later Office versions - default of not
removing and optional custom of removing? Or if the later version,
after finding the older version in a folder other than Program
Files\Microsoft Office, does not remove?
Most Access developers might remark that they have control over their
installations, and therefore, the above issue is not significant.
However, for those of us where that method does not apply, then what
options or workarounds do we have, besides the pricey SageKey scripts
(not to mention the Wise installer) and the basic just disclose it
method?
Thanks for your anticipated answers and opinions. Dalan 4 2246
Dalan, see what michka has to say on the coexistence of A97 and 2000 at: http://www.trigeminal.com/usenet/usenet019.asp?1033
The later versions are similar.
--
Allen Browne - Microsoft MVP. Perth, Western Australia.
Tips for Access users - http://allenbrowne.com/tips.html
Reply to group, rather than allenbrowne at mvps dot org.
"Dalan" <ot***@safe-mail.net> wrote in message
news:50**************************@posting.google.c om... After reading and experiencing the phenomenon of installing MS Office 2000 on a system that already has MS Office 97, or for that matter just Access 97 Runtime, I saw the ugliness that ensues. If one elects the standard installation, then Office 2000 deletes a large percentage of the older files. Of course, if one happens to choose Custom installation and elects not to uninstall prior versions, then things are happier. Yes, the archives are nearly replete with related information, but is it possible that something new has emerged on this subject?
I have done my own custom installation scripts of Access 97 Runtime and place the files in a new, separate folder under Program Files. If installed after Office 2000, there is no problem, except that each takes a bit of time to reregister itself at startup. I believe that I read somewhere about modifying the .srg files for Access 97 to overcome this issue. Is this true? And what steps are needed to accomplish it?
Also, does installing Office XP and/or Office 2003 onto a system that has a prior version (well, specifically 97) cause the same havoc as Office 2000 noted above? Or was Microsoft more circumspect with the development and deployment of the later two versions?
Not that I want to augment the finances of SageKey, but I have read that their Wise installation scripts for Access 97 have been designed to prevent later versions of Office from removing earlier ones. This is an interesting twist, but how did they do it? Is there a way to conceal the identity of the older Office files? Has anyone insight into this matter? Although logic may not be in an abundance at Microsoft, why would they not have taken the reverse approach to this issue with the installation of later Office versions - default of not removing and optional custom of removing? Or if the later version, after finding the older version in a folder other than Program Files\Microsoft Office, does not remove?
Most Access developers might remark that they have control over their installations, and therefore, the above issue is not significant. However, for those of us where that method does not apply, then what options or workarounds do we have, besides the pricey SageKey scripts (not to mention the Wise installer) and the basic just disclose it method?
Thanks for your anticipated answers and opinions. Dalan
Thanks Allen for the tip, but I have read the same article twice
before. I haven't attempted modifying the .srg files yet. So, no new
news on the subject - hey? You said "similar" regarding later versions
of MS Access and their installation protocols. So yes, if a custom
installation is not selected, then the older files are removed? And
what is so unique about SageKey's scripts that they can automatically
prevent this occurrence? Any additional insight will be appreciated.
Dalan
"Allen Browne" <Al*********@SeeSig.Invalid> wrote in message news:<3f**********************@freenews.iinet.net. au>... Dalan, see what michka has to say on the coexistence of A97 and 2000 at: http://www.trigeminal.com/usenet/usenet019.asp?1033
The later versions are similar.
-- Allen Browne - Microsoft MVP. Perth, Western Australia. Tips for Access users - http://allenbrowne.com/tips.html Reply to group, rather than allenbrowne at mvps dot org.
"Dalan" <ot***@safe-mail.net> wrote in message news:50**************************@posting.google.c om... After reading and experiencing the phenomenon of installing MS Office 2000 on a system that already has MS Office 97, or for that matter just Access 97 Runtime, I saw the ugliness that ensues. If one elects the standard installation, then Office 2000 deletes a large percentage of the older files. Of course, if one happens to choose Custom installation and elects not to uninstall prior versions, then things are happier. Yes, the archives are nearly replete with related information, but is it possible that something new has emerged on this subject?
I have done my own custom installation scripts of Access 97 Runtime and place the files in a new, separate folder under Program Files. If installed after Office 2000, there is no problem, except that each takes a bit of time to reregister itself at startup. I believe that I read somewhere about modifying the .srg files for Access 97 to overcome this issue. Is this true? And what steps are needed to accomplish it?
Also, does installing Office XP and/or Office 2003 onto a system that has a prior version (well, specifically 97) cause the same havoc as Office 2000 noted above? Or was Microsoft more circumspect with the development and deployment of the later two versions?
Not that I want to augment the finances of SageKey, but I have read that their Wise installation scripts for Access 97 have been designed to prevent later versions of Office from removing earlier ones. This is an interesting twist, but how did they do it? Is there a way to conceal the identity of the older Office files? Has anyone insight into this matter? Although logic may not be in an abundance at Microsoft, why would they not have taken the reverse approach to this issue with the installation of later Office versions - default of not removing and optional custom of removing? Or if the later version, after finding the older version in a folder other than Program Files\Microsoft Office, does not remove?
Most Access developers might remark that they have control over their installations, and therefore, the above issue is not significant. However, for those of us where that method does not apply, then what options or workarounds do we have, besides the pricey SageKey scripts (not to mention the Wise installer) and the basic just disclose it method?
Thanks for your anticipated answers and opinions. Dalan
Yes, later versions also remove previous Office products unless you do a
Custom install.
Can't comment on SageKey: not something I use.
--
Allen Browne - Microsoft MVP. Perth, Western Australia.
Tips for Access users - http://allenbrowne.com/tips.html
Reply to group, rather than allenbrowne at mvps dot org.
"Dalan" <ot***@safe-mail.net> wrote in message
news:50**************************@posting.google.c om... Thanks Allen for the tip, but I have read the same article twice before. I haven't attempted modifying the .srg files yet. So, no new news on the subject - hey? You said "similar" regarding later versions of MS Access and their installation protocols. So yes, if a custom installation is not selected, then the older files are removed? And what is so unique about SageKey's scripts that they can automatically prevent this occurrence? Any additional insight will be appreciated. Dalan
"Allen Browne" <Al*********@SeeSig.Invalid> wrote in message
news:<3f**********************@freenews.iinet.net. au>... Dalan, see what michka has to say on the coexistence of A97 and 2000 at: http://www.trigeminal.com/usenet/usenet019.asp?1033
The later versions are similar.
-- Allen Browne - Microsoft MVP. Perth, Western Australia. Tips for Access users - http://allenbrowne.com/tips.html Reply to group, rather than allenbrowne at mvps dot org.
"Dalan" <ot***@safe-mail.net> wrote in message news:50**************************@posting.google.c om... After reading and experiencing the phenomenon of installing MS Office 2000 on a system that already has MS Office 97, or for that matter just Access 97 Runtime, I saw the ugliness that ensues. If one elects the standard installation, then Office 2000 deletes a large percentage of the older files. Of course, if one happens to choose Custom installation and elects not to uninstall prior versions, then things are happier. Yes, the archives are nearly replete with related information, but is it possible that something new has emerged on this subject?
I have done my own custom installation scripts of Access 97 Runtime and place the files in a new, separate folder under Program Files. If installed after Office 2000, there is no problem, except that each takes a bit of time to reregister itself at startup. I believe that I read somewhere about modifying the .srg files for Access 97 to overcome this issue. Is this true? And what steps are needed to accomplish it?
Also, does installing Office XP and/or Office 2003 onto a system that has a prior version (well, specifically 97) cause the same havoc as Office 2000 noted above? Or was Microsoft more circumspect with the development and deployment of the later two versions?
Not that I want to augment the finances of SageKey, but I have read that their Wise installation scripts for Access 97 have been designed to prevent later versions of Office from removing earlier ones. This is an interesting twist, but how did they do it? Is there a way to conceal the identity of the older Office files? Has anyone insight into this matter? Although logic may not be in an abundance at Microsoft, why would they not have taken the reverse approach to this issue with the installation of later Office versions - default of not removing and optional custom of removing? Or if the later version, after finding the older version in a folder other than Program Files\Microsoft Office, does not remove?
Most Access developers might remark that they have control over their installations, and therefore, the above issue is not significant. However, for those of us where that method does not apply, then what options or workarounds do we have, besides the pricey SageKey scripts (not to mention the Wise installer) and the basic just disclose it method?
Thanks for your anticipated answers and opinions. Dalan
I believe SageKeys scripts are for Wise Installer and InstallShield. I know
of them primarily in regard to installing runtime support, although one of
my colleagues used his own Wise scripts to install Access 2.0 remotely.
If you simply mean the installation of retail Access, I have, on this
machine, Access 97, Access 2002, and Access 2003 all happily coexisting.
Yes, each was installed into a separte folder, and in each case, I told the
install not to replace the previous version. As best I remember, I installed
them in chronological order, but I might have installed Access 97 after one
of the others. If you get the "no license" message, take a look at Article
141373 in the Knowledge Base at http://support.microsoft.com.
I don't know if there is a SageKey newsgroup, but that would be a good
source for detail information, or SageKey's website. One would think they
would be prompt to answer questions from a potential customer.
Larry Linson
Microsoft Access MVP
"Dalan" <ot***@safe-mail.net> wrote in message
news:50**************************@posting.google.c om... Thanks Allen for the tip, but I have read the same article twice before. I haven't attempted modifying the .srg files yet. So, no new news on the subject - hey? You said "similar" regarding later versions of MS Access and their installation protocols. So yes, if a custom installation is not selected, then the older files are removed? And what is so unique about SageKey's scripts that they can automatically prevent this occurrence? Any additional insight will be appreciated. Dalan
"Allen Browne" <Al*********@SeeSig.Invalid> wrote in message
news:<3f**********************@freenews.iinet.net. au>... Dalan, see what michka has to say on the coexistence of A97 and 2000 at: http://www.trigeminal.com/usenet/usenet019.asp?1033
The later versions are similar.
-- Allen Browne - Microsoft MVP. Perth, Western Australia. Tips for Access users - http://allenbrowne.com/tips.html Reply to group, rather than allenbrowne at mvps dot org.
"Dalan" <ot***@safe-mail.net> wrote in message news:50**************************@posting.google.c om... After reading and experiencing the phenomenon of installing MS Office 2000 on a system that already has MS Office 97, or for that matter just Access 97 Runtime, I saw the ugliness that ensues. If one elects the standard installation, then Office 2000 deletes a large percentage of the older files. Of course, if one happens to choose Custom installation and elects not to uninstall prior versions, then things are happier. Yes, the archives are nearly replete with related information, but is it possible that something new has emerged on this subject?
I have done my own custom installation scripts of Access 97 Runtime and place the files in a new, separate folder under Program Files. If installed after Office 2000, there is no problem, except that each takes a bit of time to reregister itself at startup. I believe that I read somewhere about modifying the .srg files for Access 97 to overcome this issue. Is this true? And what steps are needed to accomplish it?
Also, does installing Office XP and/or Office 2003 onto a system that has a prior version (well, specifically 97) cause the same havoc as Office 2000 noted above? Or was Microsoft more circumspect with the development and deployment of the later two versions?
Not that I want to augment the finances of SageKey, but I have read that their Wise installation scripts for Access 97 have been designed to prevent later versions of Office from removing earlier ones. This is an interesting twist, but how did they do it? Is there a way to conceal the identity of the older Office files? Has anyone insight into this matter? Although logic may not be in an abundance at Microsoft, why would they not have taken the reverse approach to this issue with the installation of later Office versions - default of not removing and optional custom of removing? Or if the later version, after finding the older version in a folder other than Program Files\Microsoft Office, does not remove?
Most Access developers might remark that they have control over their installations, and therefore, the above issue is not significant. However, for those of us where that method does not apply, then what options or workarounds do we have, besides the pricey SageKey scripts (not to mention the Wise installer) and the basic just disclose it method?
Thanks for your anticipated answers and opinions. Dalan This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Max M |
last post by:
I would like to install several copies of Python 2.4.2 on my machine,
but it doesn't seem to be possible.
If I allready has a version installed, the installer only gives the
options to:
-...
|
by: wolftor |
last post by:
1) Is there a free runtime version of Access available that is more recent
than the one for Access 2000?
2) If I create an application (MDE) in A2K, will it run on all later
versions of Access?...
|
by: Ecohouse |
last post by:
I have a computer with XP on it. I loaded Office 97 first because I
needed Access 97 for some work. I then loaded Office 2000.
Everything seemed to be running fine. But I have come across a few...
|
by: Squirrel |
last post by:
I've developed an Access 2002 database which will be deployed with the
backend on
a server and frontend on the users' PCs. I've now been advised that new
employees will
be given laptops with...
|
by: ken |
last post by:
I may need to have front ends configured for Access 2002 and 2000 and
have one access 2000 backend. I think it might work? Right now I have
access 97 and 2k on my computer and when I tried linking...
|
by: ken |
last post by:
I just opened up an access database that works both in 2k3 and 2k. How
is this possible? Usually access would pop up with a window that says
you have to convert this database to the latest version....
|
by: learnet |
last post by:
Hi,
I have a question about using different versions of same assembly from
GAC....
I have created a assembly "testlib" and created a strong name for that
assembly. Installed the assembly in...
|
by: Drazen Gemic |
last post by:
How long will PHP4 be supported ? When is PHP4 end of life scheduled ?
DG
|
by: bluejack |
last post by:
A recent post asking for help with unions reminded me of this
component of the C language that I have only used a couple of times,
and those almost entirely out of personal whim -- Unions for the...
|
by: Rina0 |
last post by:
Cybersecurity engineering is a specialized field that focuses on the design, development, and implementation of systems, processes, and technologies that protect against cyber threats and...
|
by: isladogs |
last post by:
The next Access Europe meeting will be on Wednesday 2 August 2023 starting at 18:00 UK time (6PM UTC+1) and finishing at about 19:15 (7.15PM)
The start time is equivalent to 19:00 (7PM) in Central...
|
by: erikbower65 |
last post by:
Using CodiumAI's pr-agent is simple and powerful. Follow these steps:
1. Install CodiumAI CLI: Ensure Node.js is installed, then run 'npm install -g codiumai' in the terminal.
2. Connect to...
|
by: kcodez |
last post by:
As a H5 game development enthusiast, I recently wrote a very interesting little game - Toy Claw ((http://claw.kjeek.com/))。Here I will summarize and share the development experience here, and hope it...
|
by: DJRhino1175 |
last post by:
When I run this code I get an error, its Run-time error# 424 Object required...This is my first attempt at doing something like this. I test the entire code and it worked until I added this -
If...
|
by: lllomh |
last post by:
Define the method first
this.state = {
buttonBackgroundColor: 'green',
isBlinking: false, // A new status is added to identify whether the button is blinking or not
}
autoStart=()=>{
|
by: lllomh |
last post by:
How does React native implement an English player?
|
by: Mushico |
last post by:
How to calculate date of retirement from date of birth
|
by: DJRhino |
last post by:
Was curious if anyone else was having this same issue or not....
I was just Up/Down graded to windows 11 and now my access combo boxes are not acting right. With win 10 I could start typing...
| |