Subject | Re: [firebird-support] Problem with FB 2.0.5.13206 32 bit on SBS2008x64 |
---|---|
Author | Helen Borrie |
Post date | 2009-03-20T08:25:05Z |
At 03:10 PM 20/03/2009, you wrote:
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
>> >(FB has been running absolutely rock solid with my applications on thisThere'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!)
>> >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 :)
>I did have a copy of fbclient.dll in the gbak folder. I have since"gbak folder" - a utilities folder at a remote machine? Do take care that remote clients are using the correct versions of utilities and library.
>deleted it but 3 out of 4 databases backed up fine even when it was there.
>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