Property-heavy (almost all 1382a properties) db is blank on new PC

[Herkules97]

So I finally got a new computer running and as I am making everything 1386a so I don't have some 1382a, some 1383a and some 1386a scattered..I come to one of my property-heavy databases.
These databases contain almost all properties and their sole purpose is to store the root folders.
I haven't tested others, like the 1383a ones as I make new dbs run the latest EBV.
But each one has unique data, each one contains one drive letter and number combination.
#1 can have an R: and #2 can have an R: but they are different devices. I can't mix them as I can't index multiple same-named root folders.
At least I don't know how.

So testing a 1383a version is pointless because they don't have the same data. If this db doesn't work, the data is inaccessible as it exists nowhere else.
I have the dbs, but even with -read-only there is nothing.
Debug -> Stats works and all it says is "Last rebuild reason: Unable to open database file."
Are there properties exclusive to the system you are currently on that prevents it from running?

Non-heavy dbs that are also folder monitors have so far worked fine.
I will also look into the 4 dbs that had an empty stat page on my old computer and update that thread..I have been busy doing migration stuff for maybe 2 weeks.

[therube]

I am making everything 1386a

Current is 1387a.

The rest, I'm not really following. More explanation, examples might help?

[Herkules97]

I am making everything 1386a

Current is 1387a.

The rest, I'm not really following. More explanation, examples might help?

I am still making them 1386a so they all fit into the same folder.

I am not sure what you mean by examples, I don't know how to explain it further?
I have databases that have all properties indexed.
I moved to a new computer, new Windows install and all-new hardware except peripherals and the old Windows storage device because I am copying from it.
I copy the databases from it and I have 11 of them that are indexing the root folders and then one sub-folder for each of those devices.
So R:\ and R:\R10 for example.
This is so I have every property that can be indexed from that top structure like volume label and every single other property.
Those databases worked fine on that old Windows. Now they do not load and it's like I am starting a new database.
Statistics page says db could not be loaded.
I am mostly repeating what I already said because I don't know what you are seeking.

Or I should say the one I tried doesn't. But since they all contain unique data that I don't index anywhere else, losing one means losing the properties indexed on that db. So even if all other 10 works, I obviously want to still find out if the 1 that I tried so far can be fixed somehow.

[therube]

the data is inaccessible as it exists nowhere else

You'd better have multiple backups on various devices / locations of the .db's.

their sole purpose is to store the root folders

What do you mean by that, "root folders"?

#1 can have an R: and #2 can have an R:

So are these removable drives?
(You can assign set drive letters to removable devices, & depending, they may remain [essentially] static.)

I can't index multiple same-named root folders

So you're dealing with Folder Indexes & not NTFS (volume) indexes?

Unable to open database file

How are you going about opening the .db?

I am still making them 1386a so they all fit into the same folder.

What do you mean by, "fit into the same folder"?


I copy a .db that has the Length Property indexed.
I copy that .db onto a different computer, open that .db in its' own Instance with -read-only -no-auto-include.
And with that the .db is read & I can see the Length properties (along with all other expected data).

So why is similar not working on your end?

[void]

Are there properties exclusive to the system you are currently on that prevents it from running?

Everything 1.5.0.1384a removed the Volume Label property.
A database rebuild will be required if you were indexing this property in a previous version.
Sorry for the inconvenience.

The "Index Volume Label" property was renamed to Volume Label.

[Herkules97]

the data is inaccessible as it exists nowhere else

You'd better have multiple backups on various devices / locations of the .db's.

their sole purpose is to store the root folders

What do you mean by that, "root folders"?

#1 can have an R: and #2 can have an R:

So are these removable drives?
(You can assign set drive letters to removable devices, & depending, they may remain [essentially] static.)

I can't index multiple same-named root folders

So you're dealing with Folder Indexes & not NTFS (volume) indexes?

Unable to open database file

How are you going about opening the .db?

I am still making them 1386a so they all fit into the same folder.

What do you mean by, "fit into the same folder"?


I copy a .db that has the Length Property indexed.
I copy that .db onto a different computer, open that .db in its' own Instance with -read-only -no-auto-include.
And with that the .db is read & I can see the Length properties (along with all other expected data).

So why is similar not working on your end?

I can't be arsed to format this like usual, so I will answer them down here instead.
I don't know why you misinterpret what I say as if I don't have backups. The db is not loading, it's not that I don't have the dbs. I have the db, hence why I can launch it and it errors.

Root folders i A:\, C:\ and such. Root..

If by removeable you mean external, not exclusively. They are by drive letter. I can have 2 R:\ drives, but they are different drives. Windows system.
You know how you can have one SSD that is C: and is your OS device..But then that breaks and now you need a new SSD..That will still be C:\, but it isn't the same SSD.

I am noticing a pattern that I am constantly being misunderstood and I don't know what I am doing wrong. Anyway ignore the "can't index multiple" line, I just want to get a reply out there to explain the main focus so I am not reading what I wrote. It took some time because I was swapping PC, then the new Windows install broke 2 days in and I waited 12 days to restart to confirm it.

I open the db just like any, only this hasn't opened at all and instead just re-scans whatever is set in the settings. I will point out I still haven't tried other same-purpose dbs. But everything I have tried so far works. I make a shortcut, put instance in with the same name as files have.
That includes folder-only ones, NTFS-only ones and FAT-only ones.
Only the one I've tried that does not work is the one that indexes everything.

Also another one that isn't relevant, it's just like this:"C:\C9\Portables\EBV\EverythingVoidtools v1.5.0.1386a x64"
Like "C:\C9\Portables\EBV\EverythingVoidtools v1.5.0.1386a x64\Drive letter+number #2"
The shortcut: "C:\C9\Portables\EBV\EverythingVoidtools v1.5.0.1386a x64\Drive letter+number #2\EverythingVoidtools v1.5.0.1386a x64 - Drive letter+number #2.lnk"
It can't have anything to do with it failing, this is how I've done it since I started using instances.
As only these dbs have all properties indexed, the main suspect is how many properties it had and nothing to do with shortcuts or file paths.

To answer the last one from you..Yes..That is also what I do. I guess I didn't mention that the database that doesn't work has all properties but isn't exclusively the only I have.
I already have a bunch of databases that work fine, but they are meant to be used.
These drive letter ones aren't meant to be used, one-offs scanning one drive letter per database instance.
If I have R:\, I scan that in with all properties into drive letter 1 db.
If I have a different R:\ device, I scan that with drive letter 2 db and so on.

To answer Void, I didn't update. I used read-only, but that doesn't matter because the db itself isn't being read.

HOWEVER, I will note that just like I said above..That system install was broken.
I installed AMD drivers and couldn't shift+ctrl+c as in copy path and maybe other things broke. Restarted on the 19th and found out more shit broke.
This has not changed it, using the read-only shortcut it still says could not open database.

Here is line and db name
"C:\C9\Portables\EBV\EverythingVoidtools v1.5.0.1386a x64\Drive letter+number #2\Everything64.exe" -instance "Drive letter+number #2 1.5.0.1386a" -read-only
"Everything-Drive letter+number #2 1.5.0.1386a.db"
Here is the entire stat page in a lazy format:
Database
Location: C:\C9\Portables\EBV\EverythingVoidtools v1.5.0.1386a x64\Drive letter+number #2\Everything-Drive letter+number #2 1.5.0.1386a.db
Indexed file properties: Name, Path
Indexed folder properties: Name, Path
Fast sorts: Name, Path,
Folder count: 0
File count: 0
Total item count: 0
FAT index count: 0
NTFS index count: 0
ReFS index count: 0
Network drive index count: 0
Folder index count: 0
File list index count: 0
Network index count: 0
Total index count: 0
Folder data size: 0 bytes
File data size: 0 bytes
Total data size: 0 bytes
Folder index size: 0 bytes
File index size: 0 bytes
Total index size: 0 bytes
Total size: 0 bytes
Folders created: 0
Folders modified: 0
Folders deleted: 0
Folders moved: 0
Files created: 0
Files modified: 0
Files deleted: 0
Files moved: 0

Journal
Enabled: Yes
ID:
Size: 0 bytes
Max size: 3 072 000 000 bytes
First item ID:
Next item ID: 1
Item count: 0

Build
Count: 0
Total duration:
Minimum duration:
Maximum duration:
Average duration:
Last duration:
Last build date:
Last rebuild reason: Unable to open database file.

Update
Count: 0
Total duration:
Minimum duration:
Maximum duration:
Average duration:
Last duration:
Last update date:

Load
Count: 0
Total duration:
Minimum duration:
Maximum duration:
Average duration:
Last duration:
Last load date:

Save
Count: 0
Total duration:
Minimum duration:
Maximum duration:
Average duration:
Last duration:
Last save date:
Next scheduled save date: 2024-12-24 04:00:00:000
Total bytes written: 0

Query
Count: 1
Total duration: 00:00
Minimum duration: 0,000038 seconds
Maximum duration: 0,000038 seconds
Average duration: 0,000038 seconds
Last duration: 0,000038 seconds
Last query date: 2024-12-23 21:54:57:724
Total result count: 0
Maximum result count: 0
Average result count: 0
Last result count: 0

Sort
Count: 1
Total duration: 00:00
Minimum duration: 0,000015 seconds
Maximum duration: 0,000015 seconds
Average duration: 0,000015 seconds
Last duration: 0,000015 seconds
Last sort date: 2024-12-23 21:54:57:724

[Herkules97]

Here is line and db name
"C:\C9\Portables\EBV\EverythingVoidtools v1.5.0.1386a x64\Drive letter+number #2\Everything64.exe" -instance "Drive letter+number #2 1.5.0.1386a" -read-only
"Everything-Drive letter+number #2 1.5.0.1386a.db"
Here is the entire stat page in a lazy format:

I am aware the writing of the reply is messed up grammatically and whatever, I guess I autopiloted writing some of it..
Anyway I just wanted to note that this does point to 1386a..But as I've already written I used the original 1382a one too.
I have both available..I have launched both with read-only both when I wrote the post and also just now.