thank you helen.

I found this link
https://www.firebirdsql.org/pdfmanual/html/fbint-structure.html#fbint-structure-multi
this information:

Multiple File Databases
A multiple file Firebird database is almost identical to the single file
database except it has more than one file on the underlying file system.
Each file has the same page size as the initial file, and each file has
a header page (page type 0x01) at the start of the file.

So i think that this scenario happened.

Any additional suggestions?

Thank you!!!!

Cualquier duda o comentario adicional, quedo a sus órdenes.

Excelente día.



Joel de Jesús Moo Arguelles

Administrador de Base de Datos

VERTICAL KNITS S.A DE C.V

Tel. (991) 9 13 00 57 ext. 159 Fax: (991) 9 13 02 52

joel.moo@...

www.verticalknits.com



------ Mensaje original ------
De: "Geoff Worboys geoff@... [firebird-support]"
<firebird-support@yahoogroups.com>
Para: firebird-support@yahoogroups.com
Enviado: 07/05/2019 03:28:21 a. m.
Asunto: Re: [firebird-support] insert data two databases different

>
>07-May-2019 12:16 Helen Borrie helebor@... [firebird-support]
>wrote:
> >Joel Moo wrote:
> >>
> >> Hi guys, i have a situation, I work with a database name
>database1.fdb,
> >> and so, i do maintanance over this databases weekly.
> >>
> >> I backup this database before maintenance, but the maintenance
>failed,
> >> so the .fdb file in which the maintenance failed will rename it to
> >> database_2, and then restore the database1.fdb file.
> >> 2 days later for some reason the information was inserted in
>database
> >> database_2 and not in database1.fdb. It is worth mentioning that
>these
> >> files and the database.config were not modified again
> >>
> >> Any advice or experience with a similar situation?
> >
> > Well, first of all, there is no way that the Firebird engine can
> > perform any operation on a database to which it is not connected. If
> > your application seems to have updated database_2 then, some
> > unplanned things occurred.
> >
> > The best guess (from the information you have given) is that
> > the renaming of the original copy of database1.fdb to database_2 did
> > not happen.
> >
> > How could that be? Well, if you ask the operating system to
> > rename a file that is open, it will not work. A database file is open
> > if any application is connected to it. Your script has not
> > picked up that error condition so it continued onward, with the
>original
> > database1.fdb still named "database1.fdb". So, the restore from the
> > backup also failed, since gbak restore will not overwrite an existing
> > database file of the same name unless you specify OVERWRITE
>explicitly
> > with the -r[ecreate_database] switch.
> >
> > Meanwhile, at some point during thos two days, after someone had
> > inserted some data into database1.fdb, someone else came along and
> > renamed the database to database_2. Gremlins, maybe?
> >
> > Helen
>
>If I may correct an assumption here...
>
>It is indeed possible, at least in some circumstances, to rename
>an open file. (Note that move-to-the-same-volume and rename are
>effectively the same operation in most systems.) I knew this
>worked with *nix and its mv and rm commands, but recently had
>hard-earned proof that it also sometimes works in Windows...
>
>Under a Windows NTFS volume on a SAN, a scanner was creating a
>file. At the same time a utility of mine issued a MoveFileEx
>call against that file and this succeeded. My program then
>tried to issue an OpenFile (share_deny_none) on the moved file
>intending to get a hash of the contents and the open failed
>because the scanner had not yet finished writing the file and so
>retained its exclusive access.
>
>It's easy to see how this must work (names are just pointers to
>the actual storage locations), but it is certainly surprising
>when some external user/program plays around with a file you
>thought you had exclusive access to. Under *nix this surprise is
>considered a feature (it allows a program to delete a temporary
>file as soon as it open it, while it still continues to write to
>it), although, IMO, any sensible implementation would have made
>this an explicit/intentional request rather than one that can
>happen easily by accident.
>
>Exactly how this affects the original problem is less clear,
>since the problem copy must surely have been created by something
>other than a simple file copy (we must hope, because if it was
>created by a file copy then that might explain the problem asis).
>But I wanted to make clear that moving and renaming of open files
>remains possible (but not recommended).
>
>--
>Geoff Worboys
>Telesis Computing Pty Ltd
>
>
>

[Non-text portions of this message have been removed]