Perhaps we should document that database upgrade for SQLite is not supported. Instead, proxy's database file should simply be removed. When started, proxy will recreate it automatically.
Interesting, could proxy do that (delete the file) itself ?
[1]
Currently noted that automatic DB upgrade not supported for SQLite:
- https://www.zabbix.com/documentation/2.2/manual/introduction/whatsnew220#automatic_database_upgrade
- https://www.zabbix.com/documentation/2.2/manual/installation/upgrade_notes_220#new_upgrade_procedure
zalex_ua for now it's ok.
But most of us agree that something should be changed on proxy code with sqlite support.
After that these notes probably should be changed.
sasha added the message "Zabbix does not support SQLite3 database upgrade." on proxy an server sides.
CLOSED
Yeah, please document that. I run into the same issue a couple of month ago too and it took me some time to solve. Beside documenting it I'd appreciate a dedicated log messages that informs about this limitation.
As for deletion I'd prefer the process would not do it automatically. The process can't reliably know whether the data might still be of any interest to the user or not.
But an additional option to allow that, which of course by default is disabled, might be a compromise.
Good idea, okkuv9xh, to have proxy configuration parameter allowing that.
There were discussion with devs about the idea to automatically remove db file with smart logic.
We finished that idea looks good and would worth to develop it.
Considering possibly existing historical data - there no way to do something with it.
For example if server already upgraded and running - proxy should not be pointed to the server. There no way than delete db file and let proxy recreate it.
It should be only in case of major upgrade. Not sure what to do with optional patches.
As for configuration option which is disabled by default - I don't agree.
Do we have any similar configuration thing for server upgrade? No! Why then we need it for proxy?
It should be upgraded automatically! (IMO)
I see your point zalex_ua. Just speaking for myself and for my current setup I could live with that.
Nevertheless, deleting is generally an irreversible action. Users may have done some custom stuff like adding indirect connected data that might be joined with zabbix data in queries.
Sure one can argue that this is not supported by upstream. Anyway the possibility for doing so, is an elementary option in the realm of FOSS.
The implementation of a clever algorithm, that might take care of any possible variable that might theoretically exist, sounds to me a lot more effort - when even successfully doable at all.
As for referring to the way things are already done, I'd say: Let's do it the right way and make sqlite databases upgradeable in the same way it is already done for other database backends.
Addendum:
As for server upgrade, it made my live a lot easier, since i had over 30 proxies that had to be updated separately. Beside the fact that I don't want to rollback 30 proxies when it turns out that there are unexpected serious issues with the new release.
I know that's not supported as well. but in cases where it still works it's a blessing.
But that has actually nothing to do with how to take care about the proxy database 
sasha in that discussion said:
it is fairly hard to do database upgrade in SQLite.
For instance, in order to change a field's type or rename it, one has to recreate a table.
We should write absolutely different code to upgrade SQLite3. For a proxy it isn't so important. It is simpler to delete and create the new database.
Never said that sqlite upgrade would be an easy(er) way 
In case the aim is use "[...] similar configuration thing for server upgrade", then I'd suggest to implement sqlite upgrade but not to implement something new that is not done somewhere else as well.
In doubt, I believe it's by far better just to print/log a clear information about the current limitation.
Addendum:
Or to make the automatic deletion optional, of course. At least to allow opt-out.
auto-deleting would be bad, as noted that's irreversible.
i'd vote for nice message in the logfile.
For the time being, we are not going to implement a ``smart'' mechanism for upgrading SQLite databases. A log message has been added to note that SQLite DBs are not supported.
Change implemented at svn://svn.zabbix.com/branches/dev/ZBX-8307
Fix merged in 2.3.3 (trunk) r47286
FYI - svn r47286 log message uses wrong issue number "ZBX-8037"
sasha Thanks! FIXED