Subject Re: [firebird-support] Problem with FB 2.0.5.13206 32 bit on SBS2008x64
Author Helen Borrie
At 03:10 PM 20/03/2009, you wrote:

>> >(FB has been running absolutely rock solid with my applications on this
>> >client for the last 5 years until now.)
>>
>> So something here is different. ;-) And not as it ought to be. "Last 5
>> years" indicates that they've been running v.1.5 previously - is this
>> first time up with 2.0.x?
>>
>
>No embedded server apps and only one FB server installed that I can see.
>
>We upgraded to FBv2.0 12 months ago with no problems. Only change to the
>installation has been their recent move to 64bit SBS on the main server.
>
>They do have a workstation acting as an accounting server running FBv2.0
>on it. If someone using that workstation accesses the database on the
>main server could it confuse FB. I open each database with the correct
>server name so hope that each FB server is kept separate. Have I just
>been very very lucky with this for the past years :)

There's no way that Fbservers on different host machines can get in each other's way. Applications connect to servers which connect to databases. A database can't be on a different physical host to the server's host (unlike one is silly enough to employ that Unmentionable Parameter!)

>I did have a copy of fbclient.dll in the gbak folder. I have since
>deleted it but 3 out of 4 databases backed up fine even when it was there.

"gbak folder" - a utilities folder at a remote machine? Do take care that remote clients are using the correct versions of utilities and library.

>Have you heard of antivirus scanning getting in the way maybe.

Yes. And - as others have pointed out - SystemRestore (noisily documented in the Installation notes, repetitively, tiresomely) - which targets *.gdb files specifically and there's no escaping it. But renaming the database file won't be enough if the server is set up to do image backups of everything on the C-drive by default. Database files have to be excluded from *everything* that tries to get a write lock on them (and don't forget security2.fdb, which probably *is* going to stay on the C-drive).

While you're talking to the Admins at these sites, point out how ill-advised it is to have anything as dynamic as a database on the system disk.

./hb