On Tue, Mar 12, 2019 at 11:47 AM Hick Gunter <[email protected]> wrote:
> Without gaining SQLite shell access to the actual file (e.g. copy from > flash to PC/Linux/whatever) or some other possibility to run integrity > checks, this is going to be hard. > I do have this - the firmware is able to upload a copy of the raw database (at least, I believe it is untouched), and I have been able to run SQLite tools against it on Windows. This is how I know the state of the doubtful entries - the "normal" data access mechanisms used by the device and its management software (MODBUS requests to a defined register map) don't show the "bad" entries at all. > > With an embedded device, not upgrading SQLite is probably due to not > wanting to increase image size. Newer releases have more features and may > require defining more OMIT macros for the custom build to remain small. If > SQLite still accepts the database after a hard powerfail, then the custom > vfs layer seems to be working well enough. > It is likely a combination of desire not to increase the ROM footprint and a lack of time to deal with it (I'm sure this was one of half a dozen devices the engineer was supporting along with new development. In that case, you generally don't give yourself additional work if there is no demonstrated need to.) > > I suspect the application may be creating a set of "empty" records (to > make sure there is enough space in the file/flash memory) in an "initial" > transaction and performing some kind of batch update to write the data when > "enough" has been collected. Or possibly logging to temp tables (in memory) > for speed and batch copying to persistent tables periodically. The TEMP > database is automatically deleted when the connection is closed. > This is possible (and I will look for that), but I haven't seen such yet. Unfortunately, the code is a pile of C++ abstractions that make it harder for me to follow than I'd like. > > Having upgraded from 3.5.9 -> 3.7.4 -> 3.7.14.1 and recently 3.24 with > only minor problems related te extensive use of virtual tables, I think > "don't need to" was the main reason for staying on an old version. > > Given your lack of issues doing the upgrade, I will look into possibly doing it to just be more current even if there is no expectation it will help with this specific issue. Ted _______________________________________________ sqlite-users mailing list [email protected] http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
