I will post the log file content tomorrow when I am back on site now that I know where to find it.
We were using Interbase superserver. Our applications have not been changed in what they do, so no, they have not been set up for Firebird. That sounds as if you are saying we should stick with the Superserver model of Firebird. We have no problem switching to that model. The only conversion we did to move to Firebird was to backup the databases with Interbase gak, restore them with Firebird 2.5 gak, and bring up the Firebird server on Mint. One change we did have to make in our applications was to explicitly select the db dataset for each query dataset whereas with Interbase we were just using the default and Interbase knew which to use. Firebird barfed on the default. We could be doing quite a few things wrong for Firebird 2.5, but how would we know? We have been told all we needed to do was the backup and restore and everything should run correctly under Firebird. There obviously was one thing that did not fly right that we had to fix, so there could be others. However, we don't do anything complicated, just searches, reads, writes, and generators. No stored procedures, no non-Firebird access, etc. If it makes any difference, we are using Delphi 7 with IBOjects 4.99 library for access. Your reference to running out of memory makes sense. In reading all the descriptions of each Firebird model, I figured we needed some form of superserver but may have picked the wrong one. Perhaps the log will show what happened. Thanks for your response. --- In firebird-support@yahoogroups.com, Mark Rotteveel <mark@...> wrote: > > On 24-2-2013 00:43, jackmason17@... wrote: > > We converted from Windows 7 Interbase 6.02 last Monday by backing up the > > databases then restoring them to SuperClassic under Mint. The hardware is > > an Intel I3 with 8GB of memory, a hardware RAID (2 SSDs), and a system SSD. > > All 5 Firebird databases are on the RAID, a shared drive with Windows 7. > > > > All 6 users are on Windows 7. Everything seemed to be running fine until > > this afternoon. The first indication was a temporary server disconnect for > > one user. We restarted his program and all seemed well. About an hour > > later, all users failed, unable to write to the database. In over 12 years > > of using Interbase 6 on Windows, we have not encountered this problem. > > What were the specific errors received? > > > When we rebooted the Firebird server, everything returned to normal > > operation. At the time, we did not know the correct name for the Firebird > > process so we could not tell if it was still running before the reboot. We > > do not know where the Firebird logs are located, so cannot check them to > > see what went wrong. > > It sounds like this transition wasn't really tested (both from the > perspective of the application and operations). > > > Should we be using a different Firebird server for this setup? Can we > > determine the cause of the failure after having rebooted? We were having > > to reboot the Windows 7 Interbase server at least once a week and do not > > want to have to return to that scenario. We expected Firebird to run for > > many months without a reboot. > > Most likely with Interbase 6.02 you were using SuperServer, which shares > a single page cache for all connections to the same database. Now with > SuperClassic each connection has its own page cache. If you used to have > an extremely large page cache configured then you could simply be > running out of memory. > > Also a lot has changed between Interbase and Firebird 2.5, maybe your > application is doing things 'wrong' (== incompatible with Firebird 2.5), > but without specific errors that is impossible to tell. > > Mark > -- > Mark Rotteveel >
