// skipped

Though this becomes offtopic for architecture list - I answer...

> I, wise as allways, I thought that
> hardcoding the IP address in the program is a bad thing, so I changed
> this with \\SERVER-A\FDB\ERP.FDB
>
> Can you see it?...
>
> Because on all our workstations we did a full installation of FB SS
> architecture (don't ask why) each workstation when saw the \\SERVER-
> A\FDB\ERP.FDB acted like a local server (because the fbclient.dll
> resolves this as a file for the local server... hummm...
> developers...)

Why do you think so? Client redirects such attachments to server-a, and
this is the reason for:

> not one bit was
> corrupted! No gfix, no mend, no trx in limbo, no need for backup/
> restore, no nothing.


> Reason #2
> A network plier.

///
But again, no problem on

> databases, also no performance degradation on fdb apps.

This once again means that you actually worked with remote server...

> So, IMHO, we
> can safely implement remote shadows.
>

Not sure. Have a look at CreateFile documentation - discussing
FILE_FLAG_NO_BUFFERING they always refer to disk, not network
connection. For example - "Buffer addresses for read and write
operations should be sector aligned, which means aligned on addresses in
memory that are integer multiples of the volume sector size". Please
agree, that this makes no sense for data, read from network.

What about building experimental SS for you - sorry, I don't have now
working win32build environment.