Subject | Re: [ib-support] FB 1.0 Problem |
---|---|
Author | David R. Robinson |
Post date | 2001-10-19T19:17:14Z |
Sorry for the slow reply. The atkin news mirror missed this as a
followed thread.
http://ibinstall.defined.net/papers.htm
I'll do whatever the concensus is, but without knowing what Ann's "hack"
that she referred to is I wouldn't want to make any decisions on it.
version #, but I don't know what the FB chiefs all decided to do.
were replaced during the installation in that folder.
I'd prefer doing something like asking if they want their existing
InterBase files to be overwritten or not and go from there. The problem
is not just for the gds32.dll file, it's ALL of the files. When you are
installing the server, you are talking about a lot more files. Having
special logic for dealing with how and when to overwrite files
complicates the installation script logic significantly since this is
something that you don't normally have to deal with since it is logic
that is build into the install software that you don't usually have to
do anything with.
David R.
followed thread.
> Abort the install? Isn't that a little harsh?Yes, probably. :)
> As a consultant/contractor/computer guy, I would like to have theoption
> of including the install file in my setup, and then my install simplyI
> runs that program to make sure that the client is installed
> correctly, without having to reinvent the wheel. If it simply aborts,
> can't do that.I agree.
> Could you document the process untaken by theEverything related to installing IB/FB is documented at:
> installer so that it could be merged into another install process.
http://ibinstall.defined.net/papers.htm
> Here are a few other options, they are all correct actions, itI can make the Wise installer do just about anything we want to do.
> depends on what the Wise Installer is capable of. It should be
> documented as to which one you decide to use, there may also be
> others, feel free to use any of these, or come up with another.
I'll do whatever the concensus is, but without knowing what Ann's "hack"
that she referred to is I wouldn't want to make any decisions on it.
> 1) Rename the existing gds32.dll to gds32_dll.old and write theThis is possible.
> new one. If this isn't what the user wants, the user can simple
> delete the FB one, and rename the old one back.
> 2) Change gds32.dll so it reflects the same version number as theThis would be my prefernece, use 6.2 or something like that as the
> Borland one, with a different build number. Since it now checks as
> V6 it should not be a problem. The version resource would have
> other information that reflects the true version number.
version #, but I don't know what the FB chiefs all decided to do.
> 3) Give the installing person a pop-up that asks if they want toThat's possible.
> overwrite it or not. Could be combined with 1and/or 5 or 6..
> 4) Add an install option, that asks if the user wants to skip thePossible, although I'm not as fond of that as an option.
> version check for gds32.dll, during the install. Could be combined
> with 1and/or 5 or 6.
> 5) Store the new gds32.dll as gds32_dll.fb and let the user renamePossible, but probably not desirable.
> it themselves.
> 6) Create a directory called \windows\system\fbbackup move theThe Wise script ALWAYS creates a backup folder and puts any files that
> old gds32.dll to this directory and write the new one in the correct
> place.
were replaced during the installation in that folder.
I'd prefer doing something like asking if they want their existing
InterBase files to be overwritten or not and go from there. The problem
is not just for the gds32.dll file, it's ALL of the files. When you are
installing the server, you are talking about a lot more files. Having
special logic for dealing with how and when to overwrite files
complicates the installation script logic significantly since this is
something that you don't normally have to deal with since it is logic
that is build into the install software that you don't usually have to
do anything with.
David R.