Subject | Re: Corruptions to our Mac data files |
---|---|
Author | phil_hhn |
Post date | 2006-02-02T12:36:03Z |
--- In firebird-support@yahoogroups.com, Helen Borrie <helebor@...> wrote:
encountered is always the same error (shortly after that same 2 or 3
queries on startup). Yes we know the FB process has been killed but
just were emphasising the fact that of course this means our
application cannot run.
situation. We cannot get into the database with IBExpert either (until
the database is fixed - if backup/restore or gfix is able to fix it),
so java is incidental.
So the main factors seem to be FB Classic and/or Mac OSX. Java isn't
really involved (unless it has a hand in creating the corruption in
the first place - but that would surely have to be something that the
FB engine itself had a part in, anyway).
One other factor that may have a bearing: We do the odd meta data
update (eg add a column or two as standard sql, via jdbc), no more
often that once a month. Could this be failing on some of the Macs?
When we have to perform such an update we literally have 100's of
sites (75% windows 23% Mac 2% linux) that perform these updates
successfully. I can't see how this could be related since performing
these updates does not correlate with corruption, but worth
mentioning. We have careful error checking and Exception handling
around this code but could something be failing silently? (No message
from the FB engine or the jdbc driver?)
Phil
>application.
> At 05:08 PM 2/02/2006, you wrote:
> >We are having a few problems with corruptions to our Mac data files
> >What we see is:
> >java.lang.ArrayIndexOutOfBoundsException: 1034
> >This is followed by 'GDS Exception. 335544726. Error reading data from
> >the connection.' as the FB process on the server has been killed.
> >Once this happens the database is effectively unusable by our
>I should have made that first bit a little clearer... the first error
> As it would be, since it is no longer connected to the
> database. However, your Java application doesn't know that the
> connection is gone; so finding the exact point at which the crash
> occurred would be hard.
encountered is always the same error (shortly after that same 2 or 3
queries on startup). Yes we know the FB process has been killed but
just were emphasising the fact that of course this means our
application cannot run.
> >Currently we are running the 1.5.1 Classic server installer andJava is not really the issue here - it was used to demonstrate our
> >connecting using Jaybird 1.5.5.
> >All our Macs are running at least OSX 10.3.4.
> >
> >We have not seen this problem on any of our Windows sites running
> >1.5.2 SuperServer.
> >
> >In some cases doing a backup and restore seems to get the database
> >running again but in other cases not.
> >We have one client datafile here that exhibits this problem. gfix
> >reports that there is one error but when it is told to repair it just
> >gives a segmentation fault.
> >
> >Unfortunately this is happening randomly at some sites so it isn't
> >something that we can easily replicate. These are 'live' sites so it's
> >not a good situation.
> >
> >Is this familiar to anyone?
> No; and because it isn't happening on your Windows/Superserver
> installations it's happening either (or both) because it's Classic
> and because it's Java.
situation. We cannot get into the database with IBExpert either (until
the database is fixed - if backup/restore or gfix is able to fix it),
so java is incidental.
So the main factors seem to be FB Classic and/or Mac OSX. Java isn't
really involved (unless it has a hand in creating the corruption in
the first place - but that would surely have to be something that the
FB engine itself had a part in, anyway).
One other factor that may have a bearing: We do the odd meta data
update (eg add a column or two as standard sql, via jdbc), no more
often that once a month. Could this be failing on some of the Macs?
When we have to perform such an update we literally have 100's of
sites (75% windows 23% Mac 2% linux) that perform these updates
successfully. I can't see how this could be related since performing
these updates does not correlate with corruption, but worth
mentioning. We have careful error checking and Exception handling
around this code but could something be failing silently? (No message
from the FB engine or the jdbc driver?)
Phil