Hello identity
yes, the image table is still in the sqlite.db file. Unless you manually, and by script, attach a second database to your project, everything goes into the sqlite.db file.
My making a seperate table for images i mean something like for example :
- a car table with ID,BRAND,COLOR and so on
- a image table with ID,CAR_ID,IMAGE
That way, you can have as many images as you want per CAR, and all the images are stored in on separate table, not mixed with text and integers.
To make sqlite.db smaller, you can not do much :
- limit the number of picture per CAR (in my example)
- limit the size of the images you save
You can VACUUM a whole database or only a specific table.
Command is (with the example of a table called car_images :
SQLExecute('VACUUM car_images');
THIS IS USEFULL ONLY IF YOU PERFORM A LOT OF DELETE ON THE TABLE, otherwise, I recommend you don't use it.
In my project, there is a counter in database that is incremented by every delete operation, and when it reaches 30, the script is triggered.
Each time you vacuum, there is no changes made to your row id on the table (the ID of your records), so your data won't get messed-up.
Only if you reach the maximum number of row id for a table (which is 18446744073709551616) then the system will start to reuse old row id left empty by the delete operation. It is very much unlikely to happen during the life cycle of your application
Mathias
I'm a very good housekeeper !
Each time I get a divorce, I keep the house
Zaza Gabor