| Subject | Re: [firebird-support] Re: Install problem on W2K Firebird 1.5.2.4731 while testing |
|---|---|
| Author | Helen Borrie |
| Post date | 2005-08-23T03:22:54Z |
At 02:46 PM 22/08/2005 +0000, you wrote:
in the expectation of an uninstall. :-)
So, back to your problem: I think perseverance and retesting are likely to
be your best allies in finding out the conditions that caused your
apparently unclean uninstall/install situation. I'm swapping installations
around several servers regularly and never encounter these problems.
Things to watch out for are:
1. When you shut down the Guardian and server services, are you doing a
forced shutdown of databases first? And checking whether the databases
have actually got into a shutdown state (try to rename the database files...)
Don't overlook security.fdb in these checks. As long as something
is communicating with the server in any form or fashion, security.fdb will
be open.
2. Are the two services *really* shut down before you start the
uninstall? You can test that by attempting to rename the exe files.
3. Does a local application still have a loaded client? Test that by
attempting to rename the client library.
4. If you are using the default install paths, do you rename the old
directory, containing the preserved artifacts, before you begin the new
install?
5. If all that is OK, the uninstall and reinstall - at least from my
experience -should go like clockwork. But - don't forget to attend to
essential differences, e.g.
a) Clients can't connect to the Classic server using a local path. As well
as affecting any hard-coded access paths in your apps, it may affect your
settings in some third-party tools. One side of that coin is that the
command-line tools will need to use the services manager.
b) Another possible element in the equation that might have been overlooked
in transition is that a site might be using remote workstation
services. In that case, a non-network local connection to a database under
SS cannot be made at all.
c) Cache size needs to be attended to. The default Classic cache (75
pages) is too small for Superserver; whereas the default for SS (2K pages)
will soon eat up resources on a Classic server.
d) Another "gotcha" that has surfaced from recent threads is that, if you
were depending on a RemoteAuxPort setting for events in SS, it won't work
for Classic (that feature was disabled for Classic in 1.5.2, as it
transpires). It probably doesn't impinge on the connection logic...but it
might be relevant to your application's behaviour...if your application
code uses events, you possibly need to open some ports in the firewall that
Classic can select at random.
Apart from all that, you've got me stumped.
./heLen
>--- In firebird-support@yahoogroups.com, Helen Borrie <helebor@t...>OK, just checking. In the past, people have been known to run uinstall.exe
>wrote:
> > Could you describe what you do when you talk about "a complete
>uninstall"?
>
>Yes'm. Using the W2K Control panel, Add/remove Programs, remove the
>installation of Firebird chosing to completely remove all files when
>prompted.
>
>Then use the Win installer for 1.5.2.4731, and install the full
>installation of SuperServer or Classic. Reboot and check for
>performance increases and resources being used for a day or more.
>
>What I am looking for is the promise that we can install SS on a site
>(which is our default installation) and then, if Classic may be
>better (like in a multi processor environment) change to Classic. If
>it turns out later that Classic is not better, then revert to SS and
>live with a one processor affinity.
in the expectation of an uninstall. :-)
So, back to your problem: I think perseverance and retesting are likely to
be your best allies in finding out the conditions that caused your
apparently unclean uninstall/install situation. I'm swapping installations
around several servers regularly and never encounter these problems.
Things to watch out for are:
1. When you shut down the Guardian and server services, are you doing a
forced shutdown of databases first? And checking whether the databases
have actually got into a shutdown state (try to rename the database files...)
Don't overlook security.fdb in these checks. As long as something
is communicating with the server in any form or fashion, security.fdb will
be open.
2. Are the two services *really* shut down before you start the
uninstall? You can test that by attempting to rename the exe files.
3. Does a local application still have a loaded client? Test that by
attempting to rename the client library.
4. If you are using the default install paths, do you rename the old
directory, containing the preserved artifacts, before you begin the new
install?
5. If all that is OK, the uninstall and reinstall - at least from my
experience -should go like clockwork. But - don't forget to attend to
essential differences, e.g.
a) Clients can't connect to the Classic server using a local path. As well
as affecting any hard-coded access paths in your apps, it may affect your
settings in some third-party tools. One side of that coin is that the
command-line tools will need to use the services manager.
b) Another possible element in the equation that might have been overlooked
in transition is that a site might be using remote workstation
services. In that case, a non-network local connection to a database under
SS cannot be made at all.
c) Cache size needs to be attended to. The default Classic cache (75
pages) is too small for Superserver; whereas the default for SS (2K pages)
will soon eat up resources on a Classic server.
d) Another "gotcha" that has surfaced from recent threads is that, if you
were depending on a RemoteAuxPort setting for events in SS, it won't work
for Classic (that feature was disabled for Classic in 1.5.2, as it
transpires). It probably doesn't impinge on the connection logic...but it
might be relevant to your application's behaviour...if your application
code uses events, you possibly need to open some ports in the firewall that
Classic can select at random.
Apart from all that, you've got me stumped.
./heLen