> There is a central storage for these databases and prior
> to a test-execution, copies of the databases are made into the
> jenkins-workspace.

It would be good to know exactly how those copies are made.. It sounds as
if the copy process may not have released its file locks before Firebird
tries to open the database file.

There are several possibilities how a database is copied. One is a gradle-copy task running several seconds prior to test execution. A second and third one uses Java code. The Java code uses FileOutStreams, which are properly closed prior to usage of the database. In my opinion, this should be sufficient.

Also, check if the Firebird database files (including the security
database) are excluded from your virus scanner.

That's quite an idea. We'll try as soon as possible.

As Firebird SuperServer requires exclusive access, this may result in an
access denied if another process (the copy process or the virus scan)
still has a lock on that file.

One question though: Firebird tells "createFile failed", is this also reported when accessing an existing file? Shouldn't the message be "accessFile failed" or something similar?

> We are using Firebird-Superserver in 2.5.5, the operating System is
> Windows Server 2012 und we ware accessing via jaybird 2.2.10. Firebird
> is running in its default-configuration. We are aware, that this may be
> problematic and are currently trying to establish a suitable
> configuration for our needs.. We are rather free with respect to
> experiments within the firebird configuration.

Consider updating to Firebird 2.5.8; looking at the release notes I
don't really see something similar (except maybe CORE-5067), but it may
help.

We will try. We had hoped to avoid this, as this would be a really painful process given the amount of devices involved (this would not only affect test-servers but also client devices).

> Is SuperServer a suitable architecture for our scenario with several
> client processes or would SuperClassic be better suited?

I don't think it will make a difference, but you could always try. If
you are using (custom) UDFs, it might make sense to use Classic (not
SuperClassic), as in that case, things that might actually crash the
server (eg bugs in UDFs, or in Firebird itself for that matter), only
affect a single connection (usually).

We are not using any UDFs at all, just plain SQL.
I have not gotten the point in the distinction between the three products. My impression is, that roughly SuperServer saves ressources but doesn't scale, Classic scales but soaks up ressources and SuperClassic tries to scale with limited ressources. Would that be a fair abbreviation?

Thanks a lot and kind regards,
Jonathan