Hi First of all thanks for help on the way. After a lot of work (and waiting for restore,backups indexing...) I found out that it actually was as simple as an index that was inactive. The index must have been disabled during my first backup/restore as I am sure I did not do this myself. The index was a normal foreign key. However the table included a blob column.
Anyone that has an idea why this was disable during backup/restore? Anyway one the results of this is that I know both have better understanding of firebird and also have better tools for dealing with situations where I need to take down the database. Best regards Jardar On Thu, Oct 29, 2015 at 11:03 AM, Helen Borrie [email protected] [firebird-support] <[email protected]> wrote: > > > Hello Jardar, > > Thursday, October 29, 2015, 9:55:20 PM, you wrote: > > > > > The comment about "at least rebuild indexes" does that mean that I can > expect this to work or do I risk that I still need to backup/restore? > > A <[email protected]> restore will rebuild all of the indexes. > However, the indexes affected by the v.2.5.1 bug are those that are > compound, i.e., multi-column, so they are the only ones you need to > rebuild. A backup/restore will not be required. > > If you have multi-column primary, foreign or unique key constraints, note > that ALTER INDEX <index-name> INACTIVE will not work on a constraint index; > but ALTER INDEX <index-name> ACTIVE will rebuild those anyway. > > Do I need to say, do this job whilst you have exclusive access as an > administrator of the database or as the owner of the affected tables. > > Helen > > > -- Jardar Maatje Nortek Data Services AS C.J. Hambros Plass 2C 0164 Oslo tlf: +47 95184034
