Eso debería estar controlado a nivel del sistema gestor de bases de datos. Dicho de otra forma, no debes subir el archivo de base de datos, sino un script con los cambios a realizar en la base principal, me explico:
Ususario 1: modifca la base de datos y sube el script (puro sql):
Código SQL
[-]
insert into clientes (nombre, id) values ('pepe', 33);
delete from clientes where idcliente = 64
Ahora llega el Usuario 2: que ejecuta:
Código SQL
[-]
update clientes set apellido " gonzález" where idcliente = 64
error: el cliente 64 ha sido borrado previamente por otro usuario. La base de datos genera una excepción y ese usuario queda enterado del asunto.
Si te limitas a subir el archivo de bases de datos (el .fdb, .db o lo que sea), siempre será inconsistente, porque tendrá las modificaciones realizadas por el último usuario.
Lo que planteas creo es muy engorroso, lo ideal sería trabajar directamente por internet con la base principal, Firebird te puede servir perfectamente. Si no puedes hacerlo así, te recomiendo otro método:
- bajas a local la base principal
- cuando el usuario hace una modificación en la local, guardas esos cambios traducidos a sql en un archivo de texto (los scripts esos de que hablo)
- Cuando el usuario quiera actualizar la base principal, sólo tienes que enviar ese archivo de texto y ejecutarlo en la base principal. Controlando los posibles errores que pueda dar.
Saludos y espero te sirva de algo esta parrafada.