Metadata writeback question

[vbt]

I have a database (database A) with no pending metadata writebacks and no metadata is stored in sidecar files. Therefore I would have thought all the photos in this database must have all their metadata correctly stored in the photos themselves.

But if I copy some of these photos (via windows explorer) to a new folder, and then read that new folder into a new empty IMatch database (database B) I find some of the photos now have pending metadata writebacks. (The new database does not have any existing files or file relationships set up.)

What causes this behaviour and what can I do in database A to ensure all its photos have their metadata correctly stored so that no further writebacks are required if any of the photos are moved to a new database?

[Mario]

When IMatch imports images it produces a rich XMP record from the (optionally) existing EXIF, IPTC, GPS, XMP metadata in the file.
If the file has no XMP metadata before or the new XMP record created by ExifTool/IMatch has richer metadata or updated digests, checksums or date and time data, the fill will show a pending write-back. Write back once.

[vbt]

"If the file has no XMP metadata before or the new XMP record created by ExifTool/IMatch has richer metadata or updated digests, checksums or date and time data, the fill will show a pending write-back."

I thought this write-back process would then change the data in the photo so that it would not show as needing a write back again not just in this database but in any other database.

The photos I am talking about have already been ingested into another database (database A) and written back in that database so that no pending write back is required. So I thought if these photos were transferred to a new database they would no longer need anything done to their metadata.

Is it the case that even if photos don't need a writeback in one database (and that database is set up to have information recorded in the photos - and not sidecar files) then they may still need a writeback in a new database?

[Mario]

Database B does not know anything about database A. So it is perfectly normal that B thinks it has produced a new genuine record and wants to write it back. There is no special handling for this rather peculiar situation with multiple databases.

Why do you manage the same files in multiple databases? This may all end in tears.

[vbt]

I understand database B won't know anything about database A.

However once database A is fully happy that a photo's metadata is correct and fully written back then I thought the photo's metadata would have been changed such that if it was ever read in again then it would not flag as needing its metadata written back. In other words what is database B now writing back that wasn't previously written back to the photo by database A?

I am only using multiple databases as part of a transition process. (I am significantly changing the folder structure of my photos by separating the raw and sidecar files from my jpgs. And I am in the lucky position of being able to fully duplicate the photos on my pc while I test that the new structure will operate as I hope it will. During the testing period I won't be adding any newly taken photos to either database and once the testing is complete I will only keep one database and one folder structure of photos along obviously with backups.)