On 2015-09-28 11:30 AM, Aaron Digulla wrote: > > Am Freitag, 25. September 2015 20:46 CEST, Warren Young <wyml at etr-usa.com> > schrieb: > >> >> That suggests a good test for Aaron, then: >> >> sqlite3 my.db .dump > dump.sql >> sqlite3 a.db < dump.sql >> sqlite3 b.db < dump.sql > Thank you very much. This set of commands has allowed me to narrow down the > root cause to the Java JDBC driver by xerial > (https://github.com/xerial/sqlite-jdbc): > > When I dump the database and recreate it two times with the command line > sqlite3 tool, I get the exact same files. Looking at the source code of the > JDBC driver, I can't see anything obviously wrong, either. There is one > malloc() where it doesn't clear the memory but > I'm not creating functions, so the code is never used. > > The other malloc() when I read metadata from the database. > > That leaves me with a bug in my code or some really odd behavior because of > the Java VM.
Also note that if the Java VM builds the DB in any way other than a straight dump-the-sql-to-SQLite-Execute method, it might for instance add comments to the Table definitions, often if this is done a date / time is included, which by itself will cause different byte images for the DB file.
