[FIXED] BUG in database size « Writing Outliner Software Forum

Writing Outliner Software Forum » Writing Outliner Word Add-in » BETA Test Discussions

[FIXED] BUG in database size

(12 posts) (5 voices)

Started 1 year ago by IN4
Latest reply from IN4

Tags:

SQLite database

IN4
Member

1) I have database = 97 kb. I insert in document pictures (f.ex. picture.jpg = 47kB)
2) save project. Database = 290kb. (It is OK maybe)
3) I open project and delete picture. Size of database is not decrease !!! (database = 290 kb)

You use SQLite database. I decrease database size with 'sqlite3.exe ... vacuum' aplication. Database's size = 170 kB

ANY editing of project (f.ex. I delete 1 string or delete one char) enlarges size of database.

I think you must make 'optimize database' command. This is necessarily for SQLite database. I think It is very important

Best regards,
Igor.
P.S. Are you interested in russian and ukrainian translations?

Posted 1 year ago #
admin
Edwin Yip

Hi Igor,

Thanks, yes, thanks for the suggestion, an 'Optimize Database' command is needed.
Thank you very much for the offering of translating of Writing Outliner, I'm interested in it and I think it'd better to make translations after a few more version releases. Let's keep in tough, ok?

Posted 1 year ago #
IN4
Member

> it'd better to make translations after a few more version releases
OK. Give me to know when.

Posted 1 year ago #
Andrej
Member

Hi Edwin,
I think this is actually the problem of the file format (SQLite). I would repeat that I think it would be a much better idea to use a special, small file for metadata and keep the subdocuments as separate DOC files in the same folder.
For example, I am translating a book of 1800+ pages right now, and normally Word Outliner would be the best solution for handling so many chapters in the same place. But for safety reasons I actually prefer to use the clumsier version - use separate files for chapters and avoid the benefits I might have from WO, because I'm worried what might happen in the next 18 months (that's my my deadline) if the WOPRJ file keeps bloating and bloating (and the backup file grows to tens of gigabytes) until something gets corrupted. When writing a novel (around 300 pages, a few month's work), using the export option every so often seems safe enough, but - call me superstitious - I just don't trust the single WOPRJ file hundred of megabytes in size to keep such a huge project for a year an a half of everyday editing.
(I don't know much about the SQLite format itself, I'm just an average user - one of those your program is aimed at.)

Posted 1 year ago #
IN4
Member

> I think this is actually the problem of the file format (SQLite)
You are absolutely right. I know this problem very well.
Each program decides this problem in its way.
I think best way:
- make command 'optimize database' - WO exports all files on disk and imports all file into WOPRJ-database

Now WO unpacks all files in TEMP-folder for use. Maybe best way - to delete a string with old version of file and create new string in database with new version of file. I think now: WO rewrites a field in same string.

Maybe best way is don't use SQLite-database, and to use own file format.
f.ex. CHM-format are MHT-files + table of contents

>I actually prefer to use the clumsier version - use separate files for chapters
Maybe this possibility can be in options WO for users. But, as for me, This is wrong way, one database file is a future.

I use CyberArticle (best web clipping software). v.4.3xx had same file-format. I have no any problem. Now v.5.x use SQLite, MySQL, MS Access formats, as user wants. Cyberarticle had problem with SQLite-database in early versions. There are not any problem now.

Best regards
Igor

Posted 1 year ago #
admin
Edwin Yip

Actually, sqlite is widely used by many many well-known software such as Adobe, Google,Apple, and so on, so it's quite stable.

@ Andrej, in your case do you think that will make you more confident if Writing Outliner stores each individual file in a specific folder in your hard disk, instead of storing them in a database file?

Posted 1 year ago #
Andrej
Member

Yes, Edwin.

I understand there are different opinions on whether one database file or a directory of files is the future, but I'd be very happy to at least have this as an option.

In this particular project I'll have about 15 quite large docs and it would be convenient if I had them all at my fingertips within the Outliner at all times, but everything will be huge and will involve a LOT of editing for a very long time. I would just feel safer.

Posted 1 year ago #
dparish1952
Member

Edwin,

I also prefer Andrej's suggested architecture. I am a technical writer, and I need to repeat information within and among projects. As far as I have seen, the SQL restricts what I can do with content controls, legacy fields, and other Word/VBA tools.

Posted 1 year ago #
MarsKy
Member

"@ Andrej, in your case do you think that will make you more confident if Writing Outliner stores each individual file in a specific folder in your hard disk, instead of storing them in a database file?"

When I tried Writing Outliner, I thought that it was a "front-end" to docs existing on the hard drive (which is why at first I couldn't find the docs I had created within Outliner on my PC!)
For me, this would be a better method, as there would be no doubts on the integrity of the docs being maintained. In fact, I now tend to save the Outliner produced docs to the hard drive, just in case. No doubt sqlite is robust, but it adds a layer which, as can be seen from the other posts, questions the confidence in the product.

Posted 1 year ago #
admin
Edwin Yip

Thanks for the comments guys, I fully understand your concerns and this will have a high priority in my dev. plan!

Posted 1 year ago #
admin
Edwin Yip

Hi Guys, just to let you know that in upcoming new version of Writing Outliner Word addin will include a 'Compress Project File' menu command, and you'll see the percentage of the compression rate after the compression.

Posted 1 year ago #
IN4
Member

Thanks Edwin.
I.

Posted 1 year ago #

RSS feed for this topic

Reply

You must log in to post.