1251a breaks -instance ?

[therube]

1251
vs
1250

i /think/ it was 1250 that i started with
i /think/ it was :: 1250: command line that worked (now, not so sure? though at the time, it seemed to work)

1251 breaks 1250: command line
& i think 1251 breaks command line too ?
i.e., the .db, Everything-MUSIC.db, is not being read?

what i wanted, was:
Everything-MUSIC.ini
Everything-MUSIC.db ...

:: 1251: cmd /c start .\everything.exe -instance MUSIC -read-only

:: 1250: cmd /c start .\everything.exe -instance MUSIC -read-only -config MUSIC

:: .\everything.exe -instance 15 -install-service


-


something like:
cmd /c start .\everything1251.exe -instance MUSIC -read-only -config MUSIC
creates an .ini file name, "MUSIC" - no extension at all
(& also creates a file named, "Plugins-MUSIC.ini)

(didn't look to see what the ".db"... might be, or do, or not ?)


(& all because of tindersticks )

[therube]

A bit more explanation, I guess...

Copy existing .db & .ini (& 1251.exe) into new directory
Rename .db .ini to Everything-MUSIC.ini (.db)

everything -install-service -instance MUSIC

everything -instance MUSIC -config MUSIC -read-only

That creates "MUSIC" (no extension, which is the .ini).
That does not read (pre)existing EVERYTHING-MUSIC.db

(gotta go...)

[void]

Thank you for the feedback therube,

Everything 1251 will force a rebuild.

Databases made with earlier versions of Everything are not compatible with Everything 1251.

I will try to avoid forcing a rebuild like this. (re-indexing properties is a pain)
However, there will be a few cases during development where Everything will require a rebuild.

For example, the (soon to be released) 1252 update will also require a rebuild as it fixes a major sorting issue with paths.
If I don't force a rebuild, you are likely to see the Corrupt database dialog.

I will make a note in the change log if the database will be rebuilt.

Also check your Tools -> Debug -> Statistics as it will usually show the reason for the rebuild. In this case it should show "Unsupported database version".

[NotNull]

Is it useful to add the database version to the Statistics?

[void]

I did try that recently. It was removed as its adds to much confusion between the database version (currently 1.7.25) and the Everything version 1.5.0.1252a. I keep track of which Everything version has what database version so it not really useful information for the end user? .. I might be wrong though..

It would be useful information if Everything supported multiple database versions. However, that is unlikely to happen..

[NotNull]

The idea came from opening older databases (everything.exe -db backup.db -readonly) where you might want to know what version was used at that time.

But you are right: not really useful information for the end user. I doubt if I was ever going to need this.

[void]

everything.exe -db backup.db -readonly

Unfortunately, if the version changes, this would fail with unsupported DB version.
With -readonly, Everything would not load or create a database at all. (empty database) Tools -> Debug -> Stats would report an empty database with the new version (not the version from the file specified with -db)

Forcing a rebuild with new database versions will be reduced as the stability for Everything 1.5a improves.

A little bit of history here:
Everything 1.3 development went from db version 1.6.7 to 1.7.8
Everything 1.4 development went from db version 1.7.8 to 1.7.20

db2efu reports the Everything database version.

[NotNull]

OK, I see (adn even tried it). In that case there is no use adding the database version.
(and in the process I learned how to get the database version out of a everything.db, so I'm good )