[firebird-support] Restore fails due to "duplicate Value in unique Index"
Hello there, i have a problem with my 27Gb FB2.5 Database. Doing a backup is workíng fine. Doing a restore is failing due to the following error: gbak: ERROR:attempt to store duplicate value (visible to active transactions) in unique index "RDB$INDEX_20" gbak:Exiting before completion due to errors Here`s the clue: The database is working fine. There are no duplicated roles, no duplicated datasets, index-reorg is working fine, gfix could`t find ANY errors. I tried to find out, which relation "RDB$INDEX_20" has. It refers to a table named "Abrechnung", Column named "RUECKBUCHUNG". But there are no duplicated values. In fact, Column "RUECKBUCHUNG" is always empty (IS NULL). Any Ideas? Kind regards from Germany (and please excuse my bad english!) Maik Sommer IT-Systemadministrator [Non-text portions of this message have been removed]
Re: [firebird-support] Restore fails due to "duplicate Value in unique Index"
> i have a problem with my 27Gb FB2.5 Database. Doing a backup is workíng fine. > Doing a restore is failing due to the following error: > > gbak: ERROR:attempt to store duplicate value (visible to active transactions) > in > unique index "RDB$INDEX_20" > gbak:Exiting before completion due to errors > > Here`s the clue: The database is working fine. There are no duplicated roles, > no duplicated datasets, index-reorg is working fine, gfix could`t find ANY > errors. > > I tried to find out, which relation "RDB$INDEX_20" has. It refers to a table > named "Abrechnung", Column named "RUECKBUCHUNG". But there are no duplicated > values. In fact, Column "RUECKBUCHUNG" is always empty (IS NULL). > > Any Ideas? IMHO, RDB$INDEX_20 is an index on the RDB$COLLATIONS system table. This can be proved by: select i.rdb$relation_name , s.rdb$field_name from rdb$indices i join rdb$index_segments s on (i.rdb$index_name = s.rdb$index_name) where i.rdb$index_name = 'RDB$INDEX_20' So, basically this means, there are duplicate values in RDB$COLLATIONS.RDB$COLLATION_NAME. What do you get by executing the following query? select rdb$collation_name from rdb$collations group by rdb$collation_name having count(*) > 1 Greetings from Austria (lost 1:2 unlucky). ;-) Regards, Thomas
Re-2: [firebird-support] Restore fails due to "duplicate Value in unique Index"
Hello there! Thanks for your quick response. The query "select rdb$collation_name from rdb$collations group by rdb$collation_name having count(*) > 1" results in: RDB$COLLATION_NAME Greetings from Lutherstadt Wittenberg :-) Maik Sommer IT-Systemadministrator processed by David.fx Subject: Re: [firebird-support] Restore fails due to "duplicate Value in unique Index" (13-Sep-2012 14:03) From:Thomas Steinmaurer To: firebird-support@yahoogroups.com > i have a problem with my 27Gb FB2.5 Database. Doing a backup is workíng fine. > Doing a restore is failing due to the following error: > > gbak: ERROR:attempt to store duplicate value (visible to active transactions) > in > unique index "RDB$INDEX_20" > gbak:Exiting before completion due to errors > > Here`s the clue: The database is working fine. There are no duplicated roles, > no duplicated datasets, index-reorg is working fine, gfix could`t find ANY > errors. > > I tried to find out, which relation "RDB$INDEX_20" has. It refers to a table > named "Abrechnung", Column named "RUECKBUCHUNG". But there are no duplicated > values. In fact, Column "RUECKBUCHUNG" is always empty (IS NULL). > > Any Ideas? IMHO, RDB$INDEX_20 is an index on the RDB$COLLATIONS system table. This can be proved by: select i.rdb$relation_name , s.rdb$field_name from rdb$indices i join rdb$index_segments s on (i.rdb$index_name = s.rdb$index_name) where i.rdb$index_name = 'RDB$INDEX_20' So, basically this means, there are duplicate values in RDB$COLLATIONS.RDB$COLLATION_NAME. What do you get by executing the following query? select rdb$collation_name from rdb$collations group by rdb$collation_name having count(*) > 1 Greetings from Austria (lost 1:2 unlucky). ;-) Regards, Thomas [Non-text portions of this message have been removed]
Re-4: [firebird-support] Restore fails due to "duplicate Value in unique Index"
The Result is: RDB$RELATION_NAMERDB$FIELD_NAME RDB$COLLATIONSRDB$COLLATION_NAME Regards Maik Sommer IT-Systemadministrator processed by David.fx Subject: Re: Re-2: [firebird-support] Restore fails due to "duplicate Value in unique Index" (13-Sep-2012 14:13) From:Thomas Steinmaurer To: firebird-support@yahoogroups.com > Thanks for your quick response. > The query > "select > rdb$collation_name > from > rdb$collations > group by > rdb$collation_name > having > count(*) > 1" > > results in: > > RDB$COLLATION_NAME > And what's the result of: select i.rdb$relation_name , s.rdb$field_name from rdb$indices i join rdb$index_segments s on (i.rdb$index_name = s.rdb$index_name) where i.rdb$index_name = 'RDB$INDEX_20' Regards, Thomas > Greetings from Lutherstadt Wittenberg :-) > Maik Sommer > IT-Systemadministrator > > > > processed by David.fx > Subject: Re: [firebird-support] Restore fails due to "duplicate Value in > unique Index" (13-Sep-2012 14:03) > From: Thomas Steinmaurer > To: firebird-support@yahoogroups.com > > > >> i have a problem with my 27Gb FB2.5 Database. Doing a backup is workíng >> fine. Doing a restore is failing due to the following error: >> >> gbak: ERROR:attempt to store duplicate value (visible to active >> transactions) in >> unique index "RDB$INDEX_20" >> gbak:Exiting before completion due to errors >> >> Here`s the clue: The database is working fine. There are no duplicated >> roles, no duplicated datasets, index-reorg is working fine, gfix could`t >> find ANY errors. >> >> I tried to find out, which relation "RDB$INDEX_20" has. It refers to a table >> named "Abrechnung", Column named "RUECKBUCHUNG". But there are no duplicated >> values. In fact, Column "RUECKBUCHUNG" is always empty (IS NULL). >> >> Any Ideas? > > IMHO, RDB$INDEX_20 is an index on the RDB$COLLATIONS system table. This > can be proved by: > > select > i.rdb$relation_name > , s.rdb$field_name > from > rdb$indices i join rdb$index_segments s on (i.rdb$index_name = > s.rdb$index_name) > where > i.rdb$index_name = 'RDB$INDEX_20' > > So, basically this means, there are duplicate values in > RDB$COLLATIONS.RDB$COLLATION_NAME. What do you get by executing the > following query? > > select > rdb$collation_name > from > rdb$collations > group by > rdb$collation_name > having > count(*) > 1 > > Greetings from Austria (lost 1:2 unlucky). ;-) > > Regards, > Thomas > > > > > [Non-text portions of this message have been removed] > > > > > > ++ > > Visit http://www.firebirdsql.org and click the Resources item > on the main (top) menu. Try Knowledgebase and FAQ links ! > > Also search the knowledgebases at http://www.ibphoenix.com > > ++ > Yahoo! Groups Links > > > [Non-text portions of this message have been removed]
Re-6: [firebird-support] Restore fails due to "duplicate Value in unique Index"
Hello Thomas, the querys are executed in a copy of that db. On tuesday, i recognized the issue (that came without any reason). After a gbak, i stopped programs that were using the database, stopped the default instance and made a copy to a different volume, so i have a database i can Analyse. Currently, i made another copy, that i use to Analyse it with IBFirstAid 2.6. I think this is a very weird issue Mit freundlichen Grüßen aus der Lutherstadt Maik Sommer IT-Systemadministrator processed by David.fx Subject: Re: Re-4: [firebird-support] Restore fails due to "duplicate Value in unique Index" (13-Sep-2012 14:29) From:Thomas Steinmaurer To: firebird-support@yahoogroups.com > The Result is: > > RDB$RELATION_NAMERDB$FIELD_NAME > RDB$COLLATIONSRDB$COLLATION_NAME Thought so and that's weird. And you have executed both queries in the database the faulty backup is based on? Regards, Thomas > Regards > Maik Sommer > IT-Systemadministrator > > > > processed by David.fx > Subject: Re: Re-2: [firebird-support] Restore fails due to "duplicate Value > in unique Index" (13-Sep-2012 14:13) > From: Thomas Steinmaurer > To: firebird-support@yahoogroups.com > > > >> Thanks for your quick response. >> The query >> "select >> rdb$collation_name >> from >> rdb$collations >> group by >> rdb$collation_name >> having >> count(*) > 1" >> >> results in: >> >> RDB$COLLATION_NAME >> > > And what's the result of: > > select > i.rdb$relation_name > , s.rdb$field_name > from > rdb$indices i join rdb$index_segments s on (i.rdb$index_name = > s.rdb$index_name) > where > i.rdb$index_name = 'RDB$INDEX_20' > > Regards, > Thomas > >> Greetings from Lutherstadt Wittenberg :-) >> Maik Sommer >> IT-Systemadministrator >> >> >> >> processed by David.fx >> Subject: Re: [firebird-support] Restore fails due to "duplicate Value in >> unique Index" (13-Sep-2012 14:03) >> From: Thomas Steinmaurer >> To: firebird-support@yahoogroups.com >> >> >> >>> i have a problem with my 27Gb FB2.5 Database. Doing a backup is workíng >>> fine. Doing a restore is failing due to the following error: >>> >>> gbak: ERROR:attempt to store duplicate value (visible to active >>> transactions) in >>> unique index "RDB$INDEX_20" >>> gbak:Exiting before completion due to errors >>> >>> Here`s the clue: The database is working fine. There are no duplicated >>> roles, no duplicated datasets, index-reorg is working fine, gfix could`t >>> find ANY errors. >>> >>> I tried to find out, which relation "RDB$INDEX_20" has. It refers to a >>> table named "Abrechnung", Column named "RUECKBUCHUNG". But there are no >>> duplicated values. In fact, Column "RUECKBUCHUNG" is always empty (IS NULL). >>> >>> Any Ideas? >> >> IMHO, RDB$INDEX_20 is an index on the RDB$COLLATIONS system table. This >> can be proved by: >> >> select >> i.rdb$relation_name >> , s.rdb$field_name >> from >> rdb$indices i join rdb$index_segments s on (i.rdb$index_name = >> s.rdb$index_name) >> where >> i.rdb$index_name = 'RDB$INDEX_20' >> >> So, basically this means, there are duplicate values in >> RDB$COLLATIONS.RDB$COLLATION_NAME. What do you get by executing the >> following query? >> >> select >> rdb$collation_name >> from >> rdb$collations >> group by >> rdb$collation_name >> having >> count(*) > 1 >> >> Greetings from Austria (lost 1:2 unlucky). ;-) >> >> Regards, >> Thomas >> >> >> >> >> [Non-text portions of this message have been removed] >> >> >> >> >> >> ++ >> >> Visit http://www.firebirdsql.org and click the Resources item >> on the main (top) menu. Try Knowledgebase and FAQ links ! >> >> Also search the knowledgebases at http://www.ibphoenix.com >> >> ++ >> Yahoo! Groups Links >> >> >> > > > > > > [Non-text portions of this message have been removed] > > > > > > ++ > > Visit http://www.firebirdsql.org and click the Resources item > on the main (top) menu. Try Knowledgebase and FAQ links ! > > Also search the knowledgebases at http://www.ibphoenix.com > > ++ > Yahoo! Groups Links > > > [Non-text portions of this message have been removed]
Re-8: [firebird-support] Restore fails due to "duplicate Value in unique Index"
Hi, the Result is Question: An index-reorg should fix this, right? Because i`ve done so tuesday night... Mit freundlichen Grüßen aus der Lutherstadt Maik Sommer IT-Systemadministrator processed by David.fx Subject: Re: Re-6: [firebird-support] Restore fails due to "duplicate Value in unique Index" (13-Sep-2012 15:20) From:Thomas Steinmaurer To: firebird-support@yahoogroups.com > the querys are executed in a copy of that db. On tuesday, i recognized the > issue (that came without any reason). After a gbak, i stopped programs that > were using the database, stopped the default instance and made a copy to a > different volume, so i have a database i can Analyse. Currently, i made > another copy, that i use to Analyse it with IBFirstAid 2.6. > > I think this is a very weird issue I wonder if index RDB$INDEX_20 is corrupt. What's the result of: select rdb$collation_name || '' from rdb$collations group by rdb$collation_name || '' having count(*) > 1 Regards, Thomas > Mit freundlichen Grüßen aus der Lutherstadt > Maik Sommer > IT-Systemadministrator > > > > processed by David.fx > Subject: Re: Re-4: [firebird-support] Restore fails due to "duplicate Value > in unique Index" (13-Sep-2012 14:29) > From: Thomas Steinmaurer > To: firebird-support@yahoogroups.com > > > >> The Result is: >> >> RDB$RELATION_NAMERDB$FIELD_NAME >> RDB$COLLATIONSRDB$COLLATION_NAME > > Thought so and that's weird. And you have executed both queries in the > database the faulty backup is based on? > > Regards, > Thomas > >> Regards >> Maik Sommer >> IT-Systemadministrator >> >> >> >> processed by David.fx >> Subject: Re: Re-2: [firebird-support] Restore fails due to "duplicate Value >> in unique Index" (13-Sep-2012 14:13) >> From: Thomas Steinmaurer >> To: firebird-support@yahoogroups.com >> >> >> >>> Thanks for your quick response. >>> The query >>> "select >>> rdb$collation_name >>> from >>> rdb$collations >>> group by >>> rdb$collation_name >>> having >>> count(*) > 1" >>> >>> results in: >>> >>> RDB$COLLATION_NAME >>> >> >> And what's the result of: >> >> select >> i.rdb$relation_name >> , s.rdb$field_name >> from >> rdb$indices i join rdb$index_segments s on (i.rdb$index_name = >> s.rdb$index_name) >> where >> i.rdb$index_name = 'RDB$INDEX_20' >> >> Regards, >> Thomas >> >>> Greetings from Lutherstadt Wittenberg :-) >>> Maik Sommer >>> IT-Systemadministrator >>> >>> >>> >>> processed by David.fx >>> Subject: Re: [firebird-support] Restore fails due to "duplicate Value in >>> unique Index" (13-Sep-2012 14:03) >>> From: Thomas Steinmaurer >>> To: firebird-support@yahoogroups.com >>> >>> >>> >>>> i have a problem with my 27Gb FB2.5 Database. Doing a backup is workíng >>>> fine. Doing a restore is failing due to the following error: >>>> >>>> gbak: ERROR:attempt to store duplicate value (visible to active >>>> transactions) in >>>> unique index "RDB$INDEX_20" >>>> gbak:Exiting before completion due to errors >>>> >>>> Here`s the clue: The database is working fine. There are no duplicated >>>> roles, no duplicated datasets, index-reorg is working fine, gfix could`t >>>> find ANY errors. >>>> >>>> I tried to find out, which relation "RDB$INDEX_20" has. It refers to a >>>> table named "Abrechnung", Column named "RUECKBUCHUNG". But there are no >>>> duplicated values. In fact, Column "RUECKBUCHUNG" is always empty (IS >>>> NULL). >>>> >>>> Any Ideas? >>> >>> IMHO, RDB$INDEX_20 is an index on the RDB$COLLATIONS system table. This >>> can be proved by: >>> >>> select >>> i.rdb$relation_name >>> , s.rdb$field_name >>> from >>> rdb$indices i join rdb$index_segments s on (i.rdb$index_name = >>> s.rdb$index_name) >>> where >>> i.rdb$index_name = 'RDB$INDEX_20' >>> >>> So, basically this means, there are duplicate values in >>> RDB$COLLATIONS.RDB$COLLATION_NAME. What do you get by executing the >>> following query? >>> >>> se
Re-10: [firebird-support] Restore fails due to "duplicate Value in unique Index"
We`ve got a CRM-System here, therefore is the database. Within this software, you`re abled to do a check of the database structure, optional with reorganisation of the indexes. Mit freundlichen Grüßen aus der Lutherstadt Maik Sommer IT-Systemadministrator processed by David.fx Subject: Re: Re-8: [firebird-support] Restore fails due to "duplicate Value in unique Index" (13-Sep-2012 15:55) From:Thomas Steinmaurer To: firebird-support@yahoogroups.com > the Result is > > Question: An index-reorg should fix this, right? Because i`ve done so tuesday > night... How did you do that? Regards, Thomas [Non-text portions of this message have been removed]
Re-8: [firebird-support] Restore fails due to "duplicate Value in unique Index"
Hello Alexey, copying a database that has no accessing instances is the recommended way, i read. Why is it a database corruption? What happened there? FBFirstAid 2.6 said everything`s fine! Here`s a snippet of it`s LOG: 13.09.2012 13:04:53 INFO: Open database files: A:\ams4database\DB0.FDB 13.09.2012 13:04:53 INFO: Analyzing database low-level structures... 13.09.2012 13:04:53 INFO: Process database file #1 of 1 files. 13.09.2012 18:43:13 INFO: Actual PageCount: 6894935 found in database 13.09.2012 18:43:13 INFO: Found 17371 reserved and/or undefined pages. 13.09.2012 18:43:13 INFO: == DATABASE IS READY FOR DIAGNOSING AND REPAIRING. 13.09.2012 18:43:13 INFO: == Now choose "Diagnose" or "Repair". 14.09.2012 09:17:21 INFO: --- Starting diagnose 14.09.2012 09:17:21 INFO: Running procedure: Header page check 14.09.2012 09:17:21 INFO: ODS Major = 11 (32779) 14.09.2012 09:17:21 INFO: ODS Minor = 2 14.09.2012 09:17:21 INFO: Next transaction = 68793348 14.09.2012 09:17:21 INFO: Oldest transaction = 68793346 14.09.2012 09:17:21 INFO: Oldest active = 68793347 14.09.2012 09:17:21 INFO: Oldest snapshot = 68793347 14.09.2012 09:17:21 INFO: PageSize is Ok = 4096 14.09.2012 09:17:21 INFO: Running procedure: Checking of RDB$Pages consistency 14.09.2012 09:18:58 INFO: Checking of RDB$Pages consistency: Ok 14.09.2012 09:18:58 INFO: Running procedure: Low-level check of all relations 14.09.2012 09:18:58 INFO: Relation RDB$PAGES (0) is OK 14.09.2012 09:18:58 INFO: Relation RDB$DATABASE (1) is OK 14.09.2012 09:18:58 INFO: Relation RDB$FIELDS (2) is OK 14.09.2012 09:18:58 INFO: Relation RDB$INDEX_SEGMENTS (3) is OK 14.09.2012 09:18:59 INFO: Relation RDB$INDICES (4) is OK 14.09.2012 09:18:59 INFO: Relation RDB$RELATION_FIELDS (5) is OK 14.09.2012 09:18:59 INFO: Relation RDB$RELATIONS (6) is OK 14.09.2012 09:18:59 INFO: Relation RDB$VIEW_RELATIONS (7) is OK 14.09.2012 09:18:59 INFO: Relation RDB$FORMATS (8) is OK 14.09.2012 09:18:59 INFO: Relation RDB$SECURITY_CLASSES (9) is OK 14.09.2012 09:18:59 INFO: Relation RDB$FILES (10) is OK 14.09.2012 09:18:59 INFO: Relation RDB$TYPES (11) is OK 14.09.2012 09:18:59 INFO: Relation RDB$TRIGGERS (12) is OK 14.09.2012 09:19:00 INFO: Relation RDB$DEPENDENCIES (13) is OK 14.09.2012 09:19:00 INFO: Relation RDB$FUNCTIONS (14) is OK 14.09.2012 09:19:00 INFO: Relation RDB$FUNCTION_ARGUMENTS (15) is OK 14.09.2012 09:19:00 INFO: Relation RDB$FILTERS (16) is OK 14.09.2012 09:19:00 INFO: Relation RDB$TRIGGER_MESSAGES (17) is OK 14.09.2012 09:19:00 INFO: Relation RDB$USER_PRIVILEGES (18) is OK 14.09.2012 09:19:00 INFO: Relation RDB$TRANSACTIONS (19) is OK 14.09.2012 09:19:00 INFO: Relation RDB$GENERATORS (20) is OK 14.09.2012 09:19:00 INFO: Relation RDB$FIELD_DIMENSIONS (21) is OK 14.09.2012 09:19:00 INFO: Relation RDB$RELATION_CONSTRAINTS (22) is OK 14.09.2012 09:19:00 INFO: Relation RDB$REF_CONSTRAINTS (23) is OK 14.09.2012 09:19:00 INFO: Relation RDB$CHECK_CONSTRAINTS (24) is OK 14.09.2012 09:19:00 INFO: Relation RDB$LOG_FILES (25) is OK 14.09.2012 09:19:00 INFO: Relation RDB$PROCEDURES (26) is OK 14.09.2012 09:19:00 INFO: Relation RDB$PROCEDURE_PARAMETERS (27) is OK 14.09.2012 09:19:00 INFO: Relation RDB$CHARACTER_SETS (28) is OK 14.09.2012 09:19:00 INFO: Relation RDB$COLLATIONS (29) is OK 14.09.2012 09:19:00 INFO: Relation RDB$EXCEPTIONS (30) is OK 14.09.2012 09:19:00 INFO: Relation RDB$ROLES (31) is OK 14.09.2012 09:19:00 INFO: Relation RDB$BACKUP_HISTORY (32) is OK . . . . 14.09.2012 09:42:05 INFO: Low-level check of all relations: Ok 14.09.2012 09:42:05 INFO: --- Finished diagnose regards Maik Sommer IT-Systemadministrator processed by David.fx Subject: Re: Re-6: [firebird-support] Restore fails due to "duplicate Value in unique Index" (13-Sep-2012 17:46) From:Alexey Kovyazin To: firebird-support@yahoogroups.com Hello Maik, >database, stopped the default instance and made a copy to a different volume, so i have a database i can Analyse. Currently, i made another copy, that i use >to Analyse it with IBFirstAid 2.6. This is a database corruption, but our IBFirstAID will not help in this case, since it's a system index problem. You can contact support at ib-aid.com to get professional recovery support through remote desktop. Regards, Alexey Kovyazin IBSurgeon (www.ib-aid.com) > > > database, stopped the default instance and made a copy to a different > volume, so i have a database i can Analyse. Currently, i made another > copy, that i use to Analyse it with IBFirstAid 2.6. > > I think this is a very weird issue > > Mit freundlichen Grüßen aus der Lutherstadt > Maik Sommer > IT-Systemadministrator > > processed by David.fx > Subject: Re: Re-4: [firebird-support] Restore fails due to "duplicate > Value in unique
Re-8: [firebird-support] Restore fails due to "duplicate Value in unique Index"
Hello there, the problem persists. WTF is this? - doing a GBAK backup shows NO ERRORS! - GFIX shows NO ERRORS! - FBFirstAid shows NO ERRORS! - validating the Database via IBExpert shows NO ERRORS! - the Database is working fine! - there are NO duplicated Values in that RDB$COLLATIONS Table (i took an old Backup, restored it, and there were 148 entrys in that table, just like now) - Backup/Restore via nbackup is working fine! This problem is really getting very anoying! btw: Doing a restore in IBExpert shows a bit more information: IBE: Creating log file R:\RESTORE_VERBOSE.txt IBE: Starting restore. Current time: 12:59:34 IBE: Invalid insert or update value(s): object columns are constrained - no 2 table rows can have duplicate column values. attempt to store duplicate value (visible to active transactions) in unique index "RDB$INDEX_20". IBE: Restore completed. Current time: 12:59:36. Elapsed time: 00:00:02 Is there any helpful information? btw2: dropping that RDB$INDEX_20 didn`t help anything. Mit freundlichen Grüßen aus der Lutherstadt Maik Sommer IT-Systemadministrator processed by David.fx Subject: Re: Re-6: [firebird-support] Restore fails due to "duplicate Value in unique Index" (13-Sep-2012 17:46) From:Alexey Kovyazin To: firebird-support@yahoogroups.com Hello Maik, >database, stopped the default instance and made a copy to a different volume, so i have a database i can Analyse. Currently, i made another copy, that i use >to Analyse it with IBFirstAid 2.6. This is a database corruption, but our IBFirstAID will not help in this case, since it's a system index problem. You can contact support at ib-aid.com to get professional recovery support through remote desktop. Regards, Alexey Kovyazin IBSurgeon (www.ib-aid.com) > > > database, stopped the default instance and made a copy to a different > volume, so i have a database i can Analyse. Currently, i made another > copy, that i use to Analyse it with IBFirstAid 2.6. > > I think this is a very weird issue > > Mit freundlichen Grüßen aus der Lutherstadt > Maik Sommer > IT-Systemadministrator > > processed by David.fx > Subject: Re: Re-4: [firebird-support] Restore fails due to "duplicate > Value in unique Index" (13-Sep-2012 14:29) > From: Thomas Steinmaurer <mailto:ts%40iblogmanager.com>> > To: firebird-support@yahoogroups.com > <mailto:firebird-support%40yahoogroups.com> > > > The Result is: > > > > RDB$RELATION_NAMERDB$FIELD_NAME > > RDB$COLLATIONSRDB$COLLATION_NAME > > Thought so and that's weird. And you have executed both queries in the > database the faulty backup is based on? > > Regards, > Thomas > > > Regards > > Maik Sommer > > IT-Systemadministrator > > > > > > > > processed by David.fx > > Subject: Re: Re-2: [firebird-support] Restore fails due to > "duplicate Value in unique Index" (13-Sep-2012 14:13) > > From: Thomas Steinmaurer <mailto:ts%40iblogmanager.com>> > > To: firebird-support@yahoogroups.com > <mailto:firebird-support%40yahoogroups.com> > > > > > > > >> Thanks for your quick response. > >> The query > >> "select > >> rdb$collation_name > >> from > >> rdb$collations > >> group by > >> rdb$collation_name > >> having > >> count(*) > 1" > >> > >> results in: > >> > >> RDB$COLLATION_NAME > >> > > > > And what's the result of: > > > > select > > i.rdb$relation_name > > , s.rdb$field_name > > from > > rdb$indices i join rdb$index_segments s on (i.rdb$index_name = > > s.rdb$index_name) > > where > > i.rdb$index_name = 'RDB$INDEX_20' > > > > Regards, > > Thomas > > > >> Greetings from Lutherstadt Wittenberg :-) > >> Maik Sommer > >> IT-Systemadministrator > >> > >> > >> > >> processed by David.fx > >> Subject: Re: [firebird-support] Restore fails due to "duplicate > Value in unique Index" (13-Sep-2012 14:03) > >> From: Thomas Steinmaurer <mailto:ts%40iblogmanager.com>> > >> To: firebird-support@yahoogroups.com > <mailto:firebird-support%40yahoogroups.com> > >> > >> > >> > >>> i have a problem with my 27Gb FB2.5 Database. Doing a backup is > workíng fine. Doing a restore is failing due to the following error: > >>> > >>> gbak: ERROR:attempt to store duplicate value (visible to active > transactions) in > >>> unique index "RDB$INDEX_20" >
Re-8: [firebird-support] Restore fails due to "duplicate Value in unique Index"
Hello Alexey, as if i tried different things i found an unusal way to solve that problem. Now i wanted to ask you (and the whole group) what side-effects can (or will) be caused by this procedure. - i dropped the idexes (INDEX_20 & INDEX_26) - i modified the RDB$RELATIONS table to remove the SYSTEMFLAG off of the RDB$COLLATIONS - after that i was abled to drop that corrupt RDB$COLLATIONS table - i disconnected the database - i reconnected the database and received an error (missing table / some relations) - i executed a script to rebuild the RDB$COLLATIONS table ant its indexes - i modified the RDB$COLLATIONS table to add the SYSTEMFLAGS for that table and its indexes - then i re-inserted the 148 datasets that were originally in the COLLATIONS-table Now, backup/restore/everything else is working fine. Or it seems so. All of that has been done in an testing-environment! Now i need to know if there is anything that i should be worried about. If so: where`s my mistake? Greetings from Germany! Maik Sommer IT-Systemadministrator processed by David.fx Subject: Re: Re-6: [firebird-support] Restore fails due to "duplicate Value in unique Index" (13-Sep-2012 17:46) From:Alexey Kovyazin To: firebird-support@yahoogroups.com Hello Maik, >database, stopped the default instance and made a copy to a different volume, so i have a database i can Analyse. Currently, i made another copy, that i use >to Analyse it with IBFirstAid 2.6. This is a database corruption, but our IBFirstAID will not help in this case, since it's a system index problem. You can contact support at ib-aid.com to get professional recovery support through remote desktop. Regards, Alexey Kovyazin IBSurgeon (www.ib-aid.com) > > > database, stopped the default instance and made a copy to a different > volume, so i have a database i can Analyse. Currently, i made another > copy, that i use to Analyse it with IBFirstAid 2.6. > > I think this is a very weird issue > > Mit freundlichen Grüßen aus der Lutherstadt > Maik Sommer > IT-Systemadministrator > > processed by David.fx > Subject: Re: Re-4: [firebird-support] Restore fails due to "duplicate > Value in unique Index" (13-Sep-2012 14:29) > From: Thomas Steinmaurer <mailto:ts%40iblogmanager.com>> > To: firebird-support@yahoogroups.com > <mailto:firebird-support%40yahoogroups.com> > > > The Result is: > > > > RDB$RELATION_NAMERDB$FIELD_NAME > > RDB$COLLATIONSRDB$COLLATION_NAME > > Thought so and that's weird. And you have executed both queries in the > database the faulty backup is based on? > > Regards, > Thomas > > > Regards > > Maik Sommer > > IT-Systemadministrator > > > > > > > > processed by David.fx > > Subject: Re: Re-2: [firebird-support] Restore fails due to > "duplicate Value in unique Index" (13-Sep-2012 14:13) > > From: Thomas Steinmaurer <mailto:ts%40iblogmanager.com>> > > To: firebird-support@yahoogroups.com > <mailto:firebird-support%40yahoogroups.com> > > > > > > > >> Thanks for your quick response. > >> The query > >> "select > >> rdb$collation_name > >> from > >> rdb$collations > >> group by > >> rdb$collation_name > >> having > >> count(*) > 1" > >> > >> results in: > >> > >> RDB$COLLATION_NAME > >> > > > > And what's the result of: > > > > select > > i.rdb$relation_name > > , s.rdb$field_name > > from > > rdb$indices i join rdb$index_segments s on (i.rdb$index_name = > > s.rdb$index_name) > > where > > i.rdb$index_name = 'RDB$INDEX_20' > > > > Regards, > > Thomas > > > >> Greetings from Lutherstadt Wittenberg :-) > >> Maik Sommer > >> IT-Systemadministrator > >> > >> > >> > >> processed by David.fx > >> Subject: Re: [firebird-support] Restore fails due to "duplicate > Value in unique Index" (13-Sep-2012 14:03) > >> From: Thomas Steinmaurer <mailto:ts%40iblogmanager.com>> > >> To: firebird-support@yahoogroups.com > <mailto:firebird-support%40yahoogroups.com> > >> > >> > >> > >>> i have a problem with my 27Gb FB2.5 Database. Doing a backup is > workíng fine. Doing a restore is failing due to the following error: > >>> > >>> gbak: ERROR:attempt to store duplicate value (visible to active > transactions) in > >>> unique index "RDB$INDEX_20" > >>> gbak:Exiting before completion due to errors >
Re: Re-2: [firebird-support] Restore fails due to "duplicate Value in unique Index"
> Thanks for your quick response. > The query > "select > rdb$collation_name > from > rdb$collations > group by > rdb$collation_name > having > count(*) > 1" > > results in: > > RDB$COLLATION_NAME > And what's the result of: select i.rdb$relation_name , s.rdb$field_name from rdb$indices i join rdb$index_segments s on (i.rdb$index_name = s.rdb$index_name) where i.rdb$index_name = 'RDB$INDEX_20' Regards, Thomas > Greetings from Lutherstadt Wittenberg :-) > Maik Sommer > IT-Systemadministrator > > > > processed by David.fx > Subject: Re: [firebird-support] Restore fails due to "duplicate Value in > unique Index" (13-Sep-2012 14:03) > From:Thomas Steinmaurer > To: firebird-support@yahoogroups.com > > > >> i have a problem with my 27Gb FB2.5 Database. Doing a backup is workíng >> fine. Doing a restore is failing due to the following error: >> >> gbak: ERROR:attempt to store duplicate value (visible to active >> transactions) in >> unique index "RDB$INDEX_20" >> gbak:Exiting before completion due to errors >> >> Here`s the clue: The database is working fine. There are no duplicated >> roles, no duplicated datasets, index-reorg is working fine, gfix could`t >> find ANY errors. >> >> I tried to find out, which relation "RDB$INDEX_20" has. It refers to a table >> named "Abrechnung", Column named "RUECKBUCHUNG". But there are no duplicated >> values. In fact, Column "RUECKBUCHUNG" is always empty (IS NULL). >> >> Any Ideas? > > IMHO, RDB$INDEX_20 is an index on the RDB$COLLATIONS system table. This > can be proved by: > > select > i.rdb$relation_name > , s.rdb$field_name > from > rdb$indices i join rdb$index_segments s on (i.rdb$index_name = > s.rdb$index_name) > where > i.rdb$index_name = 'RDB$INDEX_20' > > So, basically this means, there are duplicate values in > RDB$COLLATIONS.RDB$COLLATION_NAME. What do you get by executing the > following query? > > select > rdb$collation_name > from > rdb$collations > group by > rdb$collation_name > having > count(*) > 1 > > Greetings from Austria (lost 1:2 unlucky). ;-) > > Regards, > Thomas > > > > > [Non-text portions of this message have been removed] > > > > > > ++ > > Visit http://www.firebirdsql.org and click the Resources item > on the main (top) menu. Try Knowledgebase and FAQ links ! > > Also search the knowledgebases at http://www.ibphoenix.com > > ++ > Yahoo! Groups Links > > >
Re: Re-4: [firebird-support] Restore fails due to "duplicate Value in unique Index"
> The Result is: > > RDB$RELATION_NAMERDB$FIELD_NAME > RDB$COLLATIONSRDB$COLLATION_NAME Thought so and that's weird. And you have executed both queries in the database the faulty backup is based on? Regards, Thomas > Regards > Maik Sommer > IT-Systemadministrator > > > > processed by David.fx > Subject: Re: Re-2: [firebird-support] Restore fails due to "duplicate Value > in unique Index" (13-Sep-2012 14:13) > From:Thomas Steinmaurer > To: firebird-support@yahoogroups.com > > > >> Thanks for your quick response. >> The query >> "select >> rdb$collation_name >> from >> rdb$collations >> group by >> rdb$collation_name >> having >> count(*) > 1" >> >> results in: >> >> RDB$COLLATION_NAME >> > > And what's the result of: > > select > i.rdb$relation_name > , s.rdb$field_name > from > rdb$indices i join rdb$index_segments s on (i.rdb$index_name = > s.rdb$index_name) > where > i.rdb$index_name = 'RDB$INDEX_20' > > Regards, > Thomas > >> Greetings from Lutherstadt Wittenberg :-) >> Maik Sommer >> IT-Systemadministrator >> >> >> >> processed by David.fx >> Subject: Re: [firebird-support] Restore fails due to "duplicate Value in >> unique Index" (13-Sep-2012 14:03) >> From: Thomas Steinmaurer >> To: firebird-support@yahoogroups.com >> >> >> >>> i have a problem with my 27Gb FB2.5 Database. Doing a backup is workíng >>> fine. Doing a restore is failing due to the following error: >>> >>> gbak: ERROR:attempt to store duplicate value (visible to active >>> transactions) in >>> unique index "RDB$INDEX_20" >>> gbak:Exiting before completion due to errors >>> >>> Here`s the clue: The database is working fine. There are no duplicated >>> roles, no duplicated datasets, index-reorg is working fine, gfix could`t >>> find ANY errors. >>> >>> I tried to find out, which relation "RDB$INDEX_20" has. It refers to a >>> table named "Abrechnung", Column named "RUECKBUCHUNG". But there are no >>> duplicated values. In fact, Column "RUECKBUCHUNG" is always empty (IS NULL). >>> >>> Any Ideas? >> >> IMHO, RDB$INDEX_20 is an index on the RDB$COLLATIONS system table. This >> can be proved by: >> >> select >> i.rdb$relation_name >> , s.rdb$field_name >> from >> rdb$indices i join rdb$index_segments s on (i.rdb$index_name = >> s.rdb$index_name) >> where >> i.rdb$index_name = 'RDB$INDEX_20' >> >> So, basically this means, there are duplicate values in >> RDB$COLLATIONS.RDB$COLLATION_NAME. What do you get by executing the >> following query? >> >> select >> rdb$collation_name >> from >> rdb$collations >> group by >> rdb$collation_name >> having >> count(*) > 1 >> >> Greetings from Austria (lost 1:2 unlucky). ;-) >> >> Regards, >> Thomas >> >> >> >> >> [Non-text portions of this message have been removed] >> >> >> >> >> >> ++ >> >> Visit http://www.firebirdsql.org and click the Resources item >> on the main (top) menu. Try Knowledgebase and FAQ links ! >> >> Also search the knowledgebases at http://www.ibphoenix.com >> >> ++ >> Yahoo! Groups Links >> >> >> > > > > > > [Non-text portions of this message have been removed] > > > > > > ++ > > Visit http://www.firebirdsql.org and click the Resources item > on the main (top) menu. Try Knowledgebase and FAQ links ! > > Also search the knowledgebases at http://www.ibphoenix.com > > ++ > Yahoo! Groups Links > > >
Re: Re-6: [firebird-support] Restore fails due to "duplicate Value in unique Index"
> the querys are executed in a copy of that db. On tuesday, i recognized the > issue (that came without any reason). After a gbak, i stopped programs that > were using the database, stopped the default instance and made a copy to a > different volume, so i have a database i can Analyse. Currently, i made > another copy, that i use to Analyse it with IBFirstAid 2.6. > > I think this is a very weird issue I wonder if index RDB$INDEX_20 is corrupt. What's the result of: select rdb$collation_name || '' from rdb$collations group by rdb$collation_name || '' having count(*) > 1 Regards, Thomas > Mit freundlichen Grüßen aus der Lutherstadt > Maik Sommer > IT-Systemadministrator > > > > processed by David.fx > Subject: Re: Re-4: [firebird-support] Restore fails due to "duplicate Value > in unique Index" (13-Sep-2012 14:29) > From:Thomas Steinmaurer > To: firebird-support@yahoogroups.com > > > >> The Result is: >> >> RDB$RELATION_NAMERDB$FIELD_NAME >> RDB$COLLATIONSRDB$COLLATION_NAME > > Thought so and that's weird. And you have executed both queries in the > database the faulty backup is based on? > > Regards, > Thomas > >> Regards >> Maik Sommer >> IT-Systemadministrator >> >> >> >> processed by David.fx >> Subject: Re: Re-2: [firebird-support] Restore fails due to "duplicate Value >> in unique Index" (13-Sep-2012 14:13) >> From: Thomas Steinmaurer >> To: firebird-support@yahoogroups.com >> >> >> >>> Thanks for your quick response. >>> The query >>> "select >>> rdb$collation_name >>> from >>> rdb$collations >>> group by >>> rdb$collation_name >>> having >>> count(*) > 1" >>> >>> results in: >>> >>> RDB$COLLATION_NAME >>> >> >> And what's the result of: >> >> select >> i.rdb$relation_name >> , s.rdb$field_name >> from >> rdb$indices i join rdb$index_segments s on (i.rdb$index_name = >> s.rdb$index_name) >> where >> i.rdb$index_name = 'RDB$INDEX_20' >> >> Regards, >> Thomas >> >>> Greetings from Lutherstadt Wittenberg :-) >>> Maik Sommer >>> IT-Systemadministrator >>> >>> >>> >>> processed by David.fx >>> Subject: Re: [firebird-support] Restore fails due to "duplicate Value in >>> unique Index" (13-Sep-2012 14:03) >>> From: Thomas Steinmaurer >>> To: firebird-support@yahoogroups.com >>> >>> >>> >>>> i have a problem with my 27Gb FB2.5 Database. Doing a backup is workíng >>>> fine. Doing a restore is failing due to the following error: >>>> >>>> gbak: ERROR:attempt to store duplicate value (visible to active >>>> transactions) in >>>> unique index "RDB$INDEX_20" >>>> gbak:Exiting before completion due to errors >>>> >>>> Here`s the clue: The database is working fine. There are no duplicated >>>> roles, no duplicated datasets, index-reorg is working fine, gfix could`t >>>> find ANY errors. >>>> >>>> I tried to find out, which relation "RDB$INDEX_20" has. It refers to a >>>> table named "Abrechnung", Column named "RUECKBUCHUNG". But there are no >>>> duplicated values. In fact, Column "RUECKBUCHUNG" is always empty (IS >>>> NULL). >>>> >>>> Any Ideas? >>> >>> IMHO, RDB$INDEX_20 is an index on the RDB$COLLATIONS system table. This >>> can be proved by: >>> >>> select >>> i.rdb$relation_name >>> , s.rdb$field_name >>> from >>> rdb$indices i join rdb$index_segments s on (i.rdb$index_name = >>> s.rdb$index_name) >>> where >>> i.rdb$index_name = 'RDB$INDEX_20' >>> >>> So, basically this means, there are duplicate values in >>> RDB$COLLATIONS.RDB$COLLATION_NAME. What do you get by executing the >>> following query? >>> >>> select >>> rdb$collation_name >>> from >>> rdb$collations >>> group by >>> rdb$collation_name >>> having >>> count(*) > 1 >>> >>> Greetings from Austria (lost 1:2 unlucky). ;-) >>> >>> Regards, >>> Thomas >>> >>> >>> >>> >>> [Non-text portio
Re: Re-8: [firebird-support] Restore fails due to "duplicate Value in unique Index"
> the Result is > > Question: An index-reorg should fix this, right? Because i`ve done so tuesday > night... How did you do that? Regards, Thomas
Re: Re-6: [firebird-support] Restore fails due to "duplicate Value in unique Index"
Hello Maik, >database, stopped the default instance and made a copy to a different volume, so i have a database i can Analyse. Currently, i made another copy, that i use >to Analyse it with IBFirstAid 2.6. This is a database corruption, but our IBFirstAID will not help in this case, since it's a system index problem. You can contact support at ib-aid.com to get professional recovery support through remote desktop. Regards, Alexey Kovyazin IBSurgeon (www.ib-aid.com) > > > database, stopped the default instance and made a copy to a different > volume, so i have a database i can Analyse. Currently, i made another > copy, that i use to Analyse it with IBFirstAid 2.6. > > I think this is a very weird issue > > Mit freundlichen Grüßen aus der Lutherstadt > Maik Sommer > IT-Systemadministrator > > processed by David.fx > Subject: Re: Re-4: [firebird-support] Restore fails due to "duplicate > Value in unique Index" (13-Sep-2012 14:29) > From: Thomas Steinmaurer <mailto:ts%40iblogmanager.com>> > To: firebird-support@yahoogroups.com > <mailto:firebird-support%40yahoogroups.com> > > > The Result is: > > > > RDB$RELATION_NAMERDB$FIELD_NAME > > RDB$COLLATIONSRDB$COLLATION_NAME > > Thought so and that's weird. And you have executed both queries in the > database the faulty backup is based on? > > Regards, > Thomas > > > Regards > > Maik Sommer > > IT-Systemadministrator > > > > > > > > processed by David.fx > > Subject: Re: Re-2: [firebird-support] Restore fails due to > "duplicate Value in unique Index" (13-Sep-2012 14:13) > > From: Thomas Steinmaurer <mailto:ts%40iblogmanager.com>> > > To: firebird-support@yahoogroups.com > <mailto:firebird-support%40yahoogroups.com> > > > > > > > >> Thanks for your quick response. > >> The query > >> "select > >> rdb$collation_name > >> from > >> rdb$collations > >> group by > >> rdb$collation_name > >> having > >> count(*) > 1" > >> > >> results in: > >> > >> RDB$COLLATION_NAME > >> > > > > And what's the result of: > > > > select > > i.rdb$relation_name > > , s.rdb$field_name > > from > > rdb$indices i join rdb$index_segments s on (i.rdb$index_name = > > s.rdb$index_name) > > where > > i.rdb$index_name = 'RDB$INDEX_20' > > > > Regards, > > Thomas > > > >> Greetings from Lutherstadt Wittenberg :-) > >> Maik Sommer > >> IT-Systemadministrator > >> > >> > >> > >> processed by David.fx > >> Subject: Re: [firebird-support] Restore fails due to "duplicate > Value in unique Index" (13-Sep-2012 14:03) > >> From: Thomas Steinmaurer <mailto:ts%40iblogmanager.com>> > >> To: firebird-support@yahoogroups.com > <mailto:firebird-support%40yahoogroups.com> > >> > >> > >> > >>> i have a problem with my 27Gb FB2.5 Database. Doing a backup is > workíng fine. Doing a restore is failing due to the following error: > >>> > >>> gbak: ERROR:attempt to store duplicate value (visible to active > transactions) in > >>> unique index "RDB$INDEX_20" > >>> gbak:Exiting before completion due to errors > >>> > >>> Here`s the clue: The database is working fine. There are no > duplicated roles, no duplicated datasets, index-reorg is working fine, > gfix could`t find ANY errors. > >>> > >>> I tried to find out, which relation "RDB$INDEX_20" has. It refers > to a table named "Abrechnung", Column named "RUECKBUCHUNG". But there > are no duplicated values. In fact, Column "RUECKBUCHUNG" is always > empty (IS NULL). > >>> > >>> Any Ideas? > >> > >> IMHO, RDB$INDEX_20 is an index on the RDB$COLLATIONS system table. This > >> can be proved by: > >> > >> select > >> i.rdb$relation_name > >> , s.rdb$field_name > >> from > >> rdb$indices i join rdb$index_segments s on (i.rdb$index_name = > >> s.rdb$index_name) > >> where > >> i.rdb$index_name = 'RDB$INDEX_20' > >> > >> So, basically this means, there are duplicate values in > >> RDB$COLLATIONS.RDB$COLLATION_NAME. What do you get by executing the > >> following query? > >> > >> select > >> rdb$collation_name > >> from
Re: Re-8: [firebird-support] Restore fails due to "duplicate Value in unique Index"
Hello Maik, I think this is Ok to use such workaround, since everything is Ok. Regards, Alexey Kovyazin IBSurgeon (www.ib-aid.com) > Hello Alexey, > > as if i tried different things i found an unusal way to solve that > problem. Now i wanted to ask you (and the whole group) what > side-effects can (or will) be caused by this procedure. > > - i dropped the idexes (INDEX_20 & INDEX_26) > - i modified the RDB$RELATIONS table to remove the SYSTEMFLAG off of > the RDB$COLLATIONS > - after that i was abled to drop that corrupt RDB$COLLATIONS table > - i disconnected the database > - i reconnected the database and received an error (missing table / > some relations) > - i executed a script to rebuild the RDB$COLLATIONS table ant its indexes > - i modified the RDB$COLLATIONS table to add the SYSTEMFLAGS for that > table and its indexes > - then i re-inserted the 148 datasets that were originally in the > COLLATIONS-table > > Now, backup/restore/everything else is working fine. Or it seems so. > All of that has been done in an testing-environment! > > Now i need to know if there is anything that i should be worried > about. If so: where`s my mistake? > > Greetings from Germany! > Maik Sommer > IT-Systemadministrator > > processed by David.fx > Subject: Re: Re-6: [firebird-support] Restore fails due to "duplicate > Value in unique Index" (13-Sep-2012 17:46) > From: Alexey Kovyazin mailto:ak%40ib-aid.com>> > To: firebird-support@yahoogroups.com > <mailto:firebird-support%40yahoogroups.com> > > Hello Maik, > > >database, stopped the default instance and made a copy to a different > volume, so i have a database i can Analyse. Currently, i made another > copy, that i use >to Analyse it with IBFirstAid 2.6. > > This is a database corruption, but our IBFirstAID will not help in this > case, since it's a system index problem. > You can contact support at ib-aid.com to get professional recovery > support through remote desktop. > > Regards, > Alexey Kovyazin > IBSurgeon (www.ib-aid.com) > > > > > > > database, stopped the default instance and made a copy to a different > > volume, so i have a database i can Analyse. Currently, i made another > > copy, that i use to Analyse it with IBFirstAid 2.6. > > > > I think this is a very weird issue > > > > Mit freundlichen Grüßen aus der Lutherstadt > > Maik Sommer > > IT-Systemadministrator > > > > processed by David.fx > > Subject: Re: Re-4: [firebird-support] Restore fails due to "duplicate > > Value in unique Index" (13-Sep-2012 14:29) > > From: Thomas Steinmaurer <mailto:ts%40iblogmanager.com> > > <mailto:ts%40iblogmanager.com>> > > To: firebird-support@yahoogroups.com > <mailto:firebird-support%40yahoogroups.com> > > <mailto:firebird-support%40yahoogroups.com> > > > > > The Result is: > > > > > > RDB$RELATION_NAMERDB$FIELD_NAME > > > RDB$COLLATIONSRDB$COLLATION_NAME > > > > Thought so and that's weird. And you have executed both queries in the > > database the faulty backup is based on? > > > > Regards, > > Thomas > > > > > Regards > > > Maik Sommer > > > IT-Systemadministrator > > > > > > > > > > > > processed by David.fx > > > Subject: Re: Re-2: [firebird-support] Restore fails due to > > "duplicate Value in unique Index" (13-Sep-2012 14:13) > > > From: Thomas Steinmaurer <mailto:ts%40iblogmanager.com> > > <mailto:ts%40iblogmanager.com>> > > > To: firebird-support@yahoogroups.com > <mailto:firebird-support%40yahoogroups.com> > > <mailto:firebird-support%40yahoogroups.com> > > > > > > > > > > > >> Thanks for your quick response. > > >> The query > > >> "select > > >> rdb$collation_name > > >> from > > >> rdb$collations > > >> group by > > >> rdb$collation_name > > >> having > > >> count(*) > 1" > > >> > > >> results in: > > >> > > >> RDB$COLLATION_NAME > > >> > > > > > > And what's the result of: > > > > > > select > > > i.rdb$relation_name > > > , s.rdb$field_name > > > from > > > rdb$indices i join rdb$index_segments s on (i.rdb$index_name = > > > s.rdb$index_name) > > > where > > > i.rdb$index_name = 'RDB$INDEX_20' > > > > > > Rega
