# Database recreation not really starting?

**URL:** <https://forum.duplicati.com/t/database-recreation-not-really-starting/16948>\
**Category:** Support\
**Created:** [October 30, 2023, 10:00am UTC](https://forum.duplicati.com/t/database-recreation-not-really-starting/16948 "2023-10-30T10:00:32Z")\
**Posts on this page:** 1\
**Showing post:** 26

<div class="post-metadata">

**Author:** ![ts678](https://forum.duplicati.com/letter_avatar_proxy/v4/letter/t/8491ac/32.png) [@ts678](https://forum.duplicati.com/u/ts678)\
**Post date:** [November 1, 2023, 2:20pm UTC](https://forum.duplicati.com/t/database-recreation-not-really-starting/16948/26 "2023-11-01T14:20:20Z")

</div>

Looks a lot like the other-topic situation where the [fileset referenced non-existent files](https://forum.duplicati.com/t/unexpected-difference-in-fileset-version-s/16895/7). Repeating here:

> `SELECT * FROM "FilesetEntry" LEFT JOIN "FixedFile" ON "FilesetEntry"."FileID" = "FixedFile"."ID" WHERE "FilesetEntry"."FilesetID" = 5 AND "FixedFile"."ID" IS NULL`

If using an original database, refer to `File` view instead of `FixedFile` table in the database bug report.

Result table has 65 rows, probably corresponding to 65 reduction of calculated files versus fileset’s list:

> [@titilesoleil](#):
>
> Unexpected difference in fileset version 8: 29.09.2023 13:00:00 (database id: 5), found 317826 entries, but expected 317891

is 65 short from the complex query that looks for data bits compared to the simple expected fileset list.  
Above query (if I’m doing this right) means that again some records of old files got removed somehow.

> [@gpatel-fr](#):
>
> Could you please run the following query

looks like it might be trying to look in the other direction (if fileset had extras). EXISTS is also suspect, although all this comment is tentative. Regardless the query did not return any rows when I had run it.

---

_[View the full topic](https://forum.duplicati.com/t/database-recreation-not-really-starting/16948)._