Your code reports 3.6.23.1 with 4.60 b3. It's around 1yr old, is there a specific change in the meantime that you're interested in? To me, 1yr old is just like gold unless major bugfixes have come since. Otherwise, you're using much newer code that's far less tested.
If you check out that change history page I linked to, you'll see there's been some new commands added, new bug fixes and performance enhancements.
Of course, that's always the case. But unless there's a specific weakness in the existing version that the later one claims to fix, and you need that fix, it's better to stick with something you know is solid. In the world of code, brand-new is not something to yearn for. Let the team decide if the latest sqlite is worth the upgrade or not, you can trust them. I do, and I've yet to be disappointed.
Fix a potential database corruption bug that can occur if version 3.7.0 and version 3.6.23.1 alternately write to the same database file. Ticket [51ae9cad317a1]
This is 1 gotcha to worry about, if sharing SQLite DB's between PB static and external later versions.
The nice thing about standards is there are so many to choose from. ~ Andrew Tanenbaum
Fix a potential database corruption bug that can occur if version 3.7.0 and version 3.6.23.1 alternately write to the same database file. Ticket [51ae9cad317a1]
This is 1 gotcha to worry about, if sharing SQLite DB's between PB static and external later versions.
Can we please have an update on what the current plans for an SQLite update are?
Fred, I know you said that you have to modify some code to integrate with PB, so we understand that has to be done slow and careful.
But it would be nice if you could roadmap it for us, and if not let us know how long, but which version of PB (4.6x?, 4.7? 4.8??) an update will be planned for.
The whole idea of even a marginal risk of data corruption is unsettling. Especially if someone were to forget or have no idea it is an issue, and end up in a situation where they are doing R/W operations across different SQL versions.