At 01:56 AM 18/08/2003 +0000, you wrote:

>well, it could have been something to do with FB closing the
>connection because of some timeout.

FB will (eventually) time out when it fails to get responses for packet
requests for a long enough time. When it gives up, the log will show a
(Client) type error, with an error code. So it's worth seeing what
Firebird messages were in the log before the TCP/IP message shows
up. Still, it's not by any means a *given* that Firebird will have an
exception before you see the network error in the log. If there was
nothing there, then you can be pretty certain that all was OK vis-a-vis the
database connection until the network cut the pipes.

>I could not really keep from
>thinking about that, I've been on the case for the last 6 days, and
>at that point, anything and everything can be suspicious, including
>what you know is working well. You suddenly start to even be
>suspicious about yourself and your abilities to solve problems...

It's an international plot by network admins to assert their
superiority. You're not exactly the first DBA to get burned by them, you
know. :-)

>I only hope I did not offend you or any other FB advocates by saying
>such a thing :-)

Offend? goodness me, no. We're glad to hear about problems that are
genuinely down to the software, cos then we can fix them.

On another tack entirely - have you considered this as an opportunity to
alter the architecture of your app? Storing large numbers of massive media
files in a database isn't necessarily a Good Thing to Do. In these cases,
it's usually better to save them as filesystem files and, in the database,
store a pathname to a file or just a filename with a path key that your app
can use to get the full path. It's then feasible to do backups and
restores. There's a fairly high degree of pointlessness in continually
backing up static blobs...even small ones.

heLen