At 11:30 AM 28/10/2008, you wrote:

>In fact, this is one of my customers that is having this problem. So,
>I'm not on site to test it by myself.
>
>So, since this problem occurs only on the client side and not on the
>server side, I thought that it could be a problem with available
>space on the client workstation.
>
>Now, since you told me that this is a problem that is returned by the
>server itself, and since this problem occurs only on the client side
>(and not on the server side) do you have any idea of what the problem
>could be?

When the Firebird engine (v.1.5 and above) has to do a sort operation, it will use the server's memory to store the intermediate stacks of retrieved data. If the server does not have enough memory available, then it will write these stacks to its temporary sort space on disk. Perhaps your remote client is the first user to have a sort operation whose stacks are too large to fit into memory; or perhaps it is getting this problem at a time when other activities on the server are consuming more memory than usual.

You said the error reported was like this:
/O error for file "C:\WINDOWS\TEMP\fb_sort_o2rmq3"
Error while trying to open file
The data is invalid.

The "invalid data" is probably a path that does not exist - so check that first.

The next [sensible] thing to do (whether C:\WINDOWS\TEMP exists or not) is to explicitly configure sort space for Firebird that is *NOT* going to be shared by other applications and is *NOT* going to be locked (ever) by any server tools like backup or SystemRestore when databases are online. Really, the default to the expected temp space is at best a gamble.

If the server's resources are often being sucked away by some other application, or you have a number of clients all trying to do big sorts concurrently, then consider adding more RAM and/or installing a fast secondary disk to use for sort space.

And watch those darned automated M$ tools. Make sure you shield all your database server components from their arbitrary actions.

./heLen