> We have in the meantime made the following test:
>
> - copied DB to another machine (always under VB 2.1.4) and
> on that machine:
>
> - validate => Error
>
> - dropped a number of fields, but did not change primary
> index definition in any way. The original table was
> described in one of my
We have in the meantime made the following test:
- copied DB to another machine (always under VB 2.1.4) and
on that machine:
- validate => Error
- dropped a number of fields, but did not change primary
index definition in any way. The original table was
described in one of my previous messages.
Sorry for my long silence too (also buzy...). We have done a few tests,
everything with FB 2.1.4.
The problem was reproducible: each restore (from the one and the same
backup) produced the same problem. (BTW, we are regularly updating this
DB/table weekly. After each backup/restore we are getting
Sorry for long silense, i'm a buzy with other things...
> Thank you for your time Vlad. You wrote:
>
>> Interesting. Could you provide DDL of table and index ?
>
> CREATE TABLE MATBEW
> (
> MSEG_MATNR Varchar(18) NOT NULL,
> MSEG_WERKS Varchar(4) NOT NULL,
> MSEG_LGORT Varchar(4) NOT
I think I'm getting a bit out of my depth with helping on this one, but here's
some more info that may be of some use:
I took a backup of one of the databases that get indices corrupted often (at
least once a week) when using 2.1.3 and restored it onto our FB 2.1.4 server.
I then did a validati
Thank you for your time Vlad. You wrote:
> Interesting. Could you provide DDL of table and index ?
CREATE TABLE MATBEW
(
MSEG_MATNR Varchar(18) NOT NULL,
MSEG_WERKS Varchar(4) NOT NULL,
MSEG_LGORT Varchar(4) NOT NULL,
MSEG_MBLNR Varchar(10) NOT NULL,
MSEG_MJAHR Varchar(4) NOT NULL,
> However, the important thing to note is, that backing up and restoring
> does not rectify the problem! Backing up and restoring finish their
> respective jobs without problems, but the validation problem is
> *immediately* there (i.e. without any usage of the DB between restoring
> and validating
Thank you for your suggestion Nick:
> 1 Drop the primary key constraint of the table in question
> 2 create index on the 6 fields
> 3 validate
I have tried this during the night: no, that does not help either, i.e.
the fact that index is being built as a secondary one and without
unique-constrain
Have you tried making an index only
1 Drop the primary key constraint of the table in question
2 create index on the 6 fields
3 validate
if that's ok, do it again but create an unique index and see what that does
--
Bene
Thank you for your time Maya. You wrote:
> Just some more info here. When you restore a database, it looks at your
> index definitions, and current data, and builds the indices from that.
> That is why backing up and restoring will rectify the problem
> (temporarily, till a new corruption occurs)
From: Borut Maricic [mailto:borut.mari...@borut.eu]
>Oh, yes, unfortunately we have.
>In fact, we became aware of this for the first time under 2.1.4
Just some more info here. When you restore a database, it looks at your index
definitions, and current data, and builds the indices from that. T
Oh, yes, unfortunately we have.
In fact, we became aware of this for the first time under
2.1.4 and hence thought about the unlikely possibility that
it might be some kind of degradation. Since we have not done
such validations before, we then validated a long list of
backups of this DB (here not
>> Index 1 is corrupt (missing entries) in table (128)
Have you tried Firebird 2.1.4? Apparently that is supposed to have sorted this
problem out...
--
Benefiting from Server Virtualization: Beyond Initial Workload
13 matches
Mail list logo
