What I am understood from the answer is explicit code must be used during creating db, for example, auto_vacuum=FULL. If no, the file size will not reduce even deleting a number of records and this is normal.
On Sat, Sep 2, 2017 at 12:47 AM, Stephen Chrzanowski <pontia...@gmail.com> wrote: > You'll want to vacuum the database. > > https://sqlite.org/lang_vacuum.html > > Deleting records from a SQLite database only changes the pages that already > exist within the file. It doesn't prune anything automatically. It can do > so, though, if you set the appropriate pragma. > > On Fri, Sep 1, 2017 at 12:41 PM, Jacky Lam <jacky...@gmail.com> wrote: > > > Hi All, > > While using my own implemented file system, the db file size will only > > expand and not prune even remove record from the db. > > Could anyone advise me that what I am missing in order to pruning the db > > size when removing a number of records? > > Jacky > > > > On Wed, Aug 9, 2017 at 11:02 AM, Simon Slavin <slav...@bigfraud.org> > > wrote: > > > > > > > > > > > On 9 Aug 2017, at 3:31am, Jacky Lam <jacky...@gmail.com> wrote: > > > > > > > 1. Can I call sqlite3_open more than one times before calling > > > sqlite3_close > > > > and sqlite3_free? > > > > > > Call sqlite3_open() for each database you want to open. You can have > any > > > number of databases open at the same time. Call sqlite3_close() for > each > > > database you have open when you no longer need it. After closing the > > last > > > connection call sqlite3_shutdown() as described in > > > > > > <https://sqlite.org/c3ref/initialize.html> > > > > > > (The above ignores use of SQL's ATTACH command.) > > > > > > You are not expected to ever call sqlite3_free() unless you are using > > > SQLite to do other memory-handing tasks for you. Most people who use > > > SQLite never call sqlite3_free(). > > > > > > > 2. If the above mentioned devices change to mutli-thread setting but > no > > > > thread safe functions such as mutex, is this setting still fine? > > > > > > You have explicitly declared SQLITE_THREADSAFE=0 . That means you will > > > arrange that only one thread will be doing SQLite calls at once. As > long > > > as you can ensure this, SQLite will function correctly. > > > > > > > If not, how can I make it thread safe with lack of mutex support > in > > > > the system? > > > > > > Do any of the following: > > > > > > A) Implement your own mutex system. > > > > > > B) Use SQLite’s mutex system ( <https://sqlite.org/c3ref/ > > mutex_alloc.html> > > > ) > > > > > > C) Supply the value SQLITE_OPEN_FULLMUTEX when you open connections > using > > > sqlite3_open_v2(), as described in <https://sqlite.org/c3ref/open.html > > > > . > > > > > > Please note that the above is a top-of-the-head answer and I have not > > > personally tries each of the options to make sure it works. > > > > > > Simon. > > > _______________________________________________ > > > sqlite-users mailing list > > > sqlite-users@mailinglists.sqlite.org > > > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > > > > > _______________________________________________ > > sqlite-users mailing list > > sqlite-users@mailinglists.sqlite.org > > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > > > _______________________________________________ > sqlite-users mailing list > sqlite-users@mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
