[firebird-support] Forced write

2013-07-17 Thread rddymanohar
Hi,
We are on Firebird 1.56 and recently encountered database corruption problem 
with a customer. Found that forced write was turned off on the database and 
after the database was restored turned it on. However on checking the next day 
forced write was again turned off. We do daily sweep, reindex and backup on the 
database as maintenance at the the eod. Will any of this cause forced write to 
be turned off.

Thanks




[firebird-support] Re: Forced write

2013-07-17 Thread rddymanohar
We found it the ibo components was set to forced write no and that was causing 
the problem.

Thanks

--- In firebird-support@yahoogroups.com, Helen Borrie helebor@... wrote:

 At 08:55 a.m. 18/07/2013, rddymanohar wrote:
 Hi,
 We are on Firebird 1.56 and recently encountered database corruption problem 
 with a customer. Found that forced write was turned off on the database and 
 after the database was restored turned it on. However on checking the next 
 day forced write was again turned off. We do daily sweep, reindex and backup 
 on the database as maintenance at the the eod. Will any of this cause forced 
 write to be turned off.
 
 None of the above will change the Forced Write setting.  However, in the very 
 ancient version of Firebird that you are using, a client can do it, via the 
 connection API.  The very first thing I would recommend is to examine closely 
 the connection settings on all client applications.  
 
 A common source of this problem is Delphi applications that provide 
 properties and/or arrays of properties in the connection component 
 (connection alone, or database component).  If this is your case, look at 
 *both* the property in question (ForcedWrites TRUE/FALSE) and *also* the 
 Params property of the connection/database component.
 
 
 Helen Borrie, Support Consultant, IBPhoenix (Pacific)
 Author of The Firebird Book and The Firebird Book Second Edition
 http://www.firebird-books.net
 __





[firebird-support] Forced Write turning off

2013-02-12 Thread rddymanohar
We recently had database corruptions and had turned on forced write on our 
databases on windows environment but we found that after we run our client 
application gstat was no more showing the forced write status. We are using 
Delphi and IBO components but not sure what in the application is resetting 
this status. Has anyone come across this problem or know what could be doing 
this.

thanks
 



[firebird-support] URGENT : Corrupt Firebird dabase

2013-01-22 Thread rddymanohar
Hi,

One of our clients has a corrupted database (we are getting internal gds 
error). Its a Firebird Database version 1.5.6, the files size is almost 7.5GB, 
we are unable to recover it with the normal tools, we have run the Repair 
procedure in IBFIRST aid and followed the recommended steps following that, 
using GFIX and GBAK command lines. Backup fails with the following error on a 
table 
gbak: ERROR: Internal gds software consistency check (wrong record length (183))
gbak: ERROR: gds_$receive failed

We are not able to even delete the table or its data to continue with the 
backup.

The client is down for the last one day. I would really appreciate if any one 
can help me in find a way to get this database up and running. 

Thanks



[firebird-support] Index Corruption Firebird 1.5

2012-11-21 Thread rddymanohar
Hi,
Recently we have started noticing problems at many of our customers
where the index on certain tables are either corrupted or inactive.
These are three different scenarios that we have and I hope you can give
me some info on what is causing this.
1. Index's are in the inactive state.2. Index whose definition was
changed and also in inactive state.3. Indexes are active but the select
using that index was not returning any results but once we inactivate
and reactivate the indexes it starts to work properly.
We are using Firebird 1.5.5.4926 and IBO components.  We do a background
process at night to inactivate and reactivate all indexes but this
hasn't really helped the cause.  We have checked to make sure that no
person is playing with the database and causing this issue and its
something in the program or some other factor which is causing this
issue. We have checked the code around the tables where these problems
exist and couldn't find anything that could cause the problem.
I hope that some of you can let me know what to look for to fix this
issue.
Thanks


[Non-text portions of this message have been removed]