We have a 127GB Firebird database that was running on Windows Server 2008 x64
with 16GB of RAM and Firebird SuperClassic v2.5.2.26539. The database has a
page size of 8192 and buffers of 6144, and ODS version 11.2.
Due to time constraints I could not do a backup+restore on the new server,
I had a strange coincidence today, but I'm wondering if it actually may have
been cause/effect instead.
I'm running fb_inet_server.exe 2.5.2.26539 on Windows 2008 Server. Earlier
today I created a simple "for select do update" stored procedure against a
database that may have had 20-25 open
We are moving to a new server and doing a Firebird update will be part of that
process.
I'm glad to hear that compiling like this didn't raise a huge outcry from
everyone, but it sure would have made things easier if it had!
Bob M..
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
account a where
a.account_id + 0 = z.account_id)
This will be slow because it not use index but give you the answer
Regards,
Karol Bieniaszewski
- Reply message -
Od: apos;Bob Murdochapos; mailgro...@murdochfl.com [firebird-support]
firebird-support@yahoogroups.com
Do: firebird-support
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
