Sean -
-Original Message-
Very odd situation.
Are the data types of the account_id columns the same for all tables?
No one asked if you:
- which FB version you are running?
- are you performing backup/restore using the same FB version (ie. not trying
to perform an ODS/version
-Original Message-
That is weird.
The SQL which Karol provided should have found the problem/missing values
from the Account table.
I can only think of 2 options of the top of my head:
1- Try a slightly different SQL query, though it should be the same as
Karol's (Select * from
Thank you Karol for your post.
However, your query did not yield any results either. I’m not sure what the
difference would have been between using the left join and the subselect, but
I’ll take any advice right now.
Thank you,
Bob M..
From: firebird-support@yahoogroups.com
I received an error during a restore process today, where multiple FKs could
not be restored. The restore log messages look like this:
gbak:cannot commit index FK_ZIP_CODE_ACCT_TO_ACCOUNT
gbak: ERROR:violation of FOREIGN KEY constraint FK_ZIP_CODE_ACCT_TO_ACCOUNT
on table ZIP_CODE_ACCOUNT
-Original Message-
From: firebird-support@yahoogroups.com
[mailto:firebird-support@yahoogroups.com] On Behalf Of Dmitry Kuzmenko
Sent: Saturday, October 12, 2013 12:36 AM
To: firebird-support@yahoogroups.com
Subject: Re[2]: [firebird-support] Restore error during unique index
creation
I am using FB version 2.5.2 (64bit) on a Windows 2008 server.
When trying to restore a database, I am receiving the following error
message in the restore log:
gbak:activating and creating deferred index
FK_USER_DASHBOARD_ELEMENT_TO_US
gbak:cannot commit index
-Original Message-
From: firebird-support@yahoogroups.com
[mailto:firebird-support@yahoogroups.com] On Behalf Of Bob Murdoch
Sent: Monday, September 17, 2012 10:27 AM
I have an FB 2.1.5 Classic server running on a Windows 2003 server,
with a single hard drive for the operating system
Alexey
From: Alexey Kovyazin [mailto:a...@ib-aid.com]
Is there any way to tell if the sweep was successful other than
all of the markers
matching? Is there any way to tell why a sweep would have failed?
No. You should manually check transactions' markers difference, or
Here's a related question for you - as I looked at our script for
doing nightly backups, I see a note that says:
do not use garbage collection (gbak -g) since we run a manual sweep
every night
Do you know if that's true - we don't need to do garbage collection
via gbak if we are running gfix
From: firebird-support@yahoogroups.com
[mailto:firebird-support@yahoogroups.com] On Behalf Of Thomas
Steinmaurer
Here's a related question for you - as I looked at our script for
v doing nightly backups, I see a note that says:
do not use garbage collection (gbak -g) since we run a manual
I have an FB 2.1.5 Classic server running on a Windows 2003 server,
with a single hard drive for the operating system, and a 3 disk raid 5
array for the database. We have one database on this machine, which
is a dialect 1 database that was started on IB6.0 many years ago,
currently at 90GB. We
Alexey -
Alexey Kovyazin [mailto:a...@ib-aid.com]
Seems like you do correct things, but do you check that sweep is
really successful?
Look at the transactions' markers log in IBTM (IBSurgeon
Transaction Monitor), gathered from Profitmed
database (120Gb, 400 clients, 2mln transactions
Thomas -
-Original Message-
From: firebird-support@yahoogroups.com
[mailto:firebird-support@yahoogroups.com] On Behalf Of Thomas
Steinmaurer
1): The most obvious thing according to the header page is a very
large
gap between the oldest active transaction and the next transaction.
Michael -
-Original Message-
From: firebird-support@yahoogroups.com
[mailto:firebird-support@yahoogroups.com] On Behalf Of Michael Ludwig
Sent: Thursday, June 07, 2012 1:12 PM
To: firebird-support@yahoogroups.com
Subject: Re: [firebird-support] Dealing with inserts from multiple
Doug -
On June 07, 2012 6:08 PM Doug Chamberlin wrote:
Yes. On further thought I think I would make the whole ETL process a
two-pass affair. First pass check for existence of all needed
entities
and creates ones that are missing. Second pass should do the
inserting
proper without errors.
Set,
-Original Message-
From: firebird-support@yahoogroups.com
[mailto:firebird-support@yahoogroups.com] On Behalf Of Svein Erling
Tysvær
Sent: Friday, August 19, 2011 2:18 AM
To: firebird-support@yahoogroups.com
Subject: RE: [firebird-support] Oldest transaction stuck
16 matches
Mail list logo
