Hi all,
What are the pros and cons of the various storage formats? Is one
preferred over the others?
Also, if in the future I should decide to switch to a different format,
is it a fairly straightforward process to convert?
--keith
--
kkel...@wombat.san-francisco.ca.us
__
Keith Keller wrote
> Also, if in the future I should decide to switch to a different format,
> is it a fairly straightforward process to convert?
It seems fairly straightforward to me - Save As will save the current book
in the newly selected format. Hence you can try them out and see if they fit
On Tue, May 15, 2018 at 07:48:52AM -0700, cicko wrote:
>
> Listing all the pros and cons is difficult simply because whether something
> is a pro or a con depends on your situation.
Sure. But I was hoping some sort of general guidelines might exist.
> Some more info can be found on the wiki:
>
Keith,
I'm not sure how you looked, but this topic had been discussed for many years
on the list. A recent one was
https://lists.gnucash.org/pipermail/gnucash-user/2018-January/074315.html.
Another was
https://lists.gnucash.org/pipermail/gnucash-user/2013-September/050410.html.
David
O
On Thu, May 17, 2018 at 03:21:13AM +, David T. wrote:
> I'm not sure how you looked, but this topic had been discussed for many
> years on the list. A recent one was
> https://lists.gnucash.org/pipermail/gnucash-user/2018-January/074315.html.
> Another was
> https://lists.gnucash.org/piper
Keith,
The SQL backends are having a few issues at the moment. It would be a good idea
to search the list here and also to look over the bug reports on Bugzilla.
I originally used MySQL when I was running an Ubuntu box as my daily machine,
but changed to XML when I moved to MacOS, and then swit
And, as I noted in January, the sql format does not get compressed, so the
files are much larger.
On Thu, May 17, 2018 at 10:37, Adrien
Monteleone wrote: Keith,
The SQL backends are having a few issues at the moment. It would be a good idea
to search the list here and also to look ove
Is the SQLite storage format immune to the issue regarding "very long time
to save the XML format" some users are experiencing?
On Thu, May 17, 2018, 10:46 David T. via gnucash-user <
gnucash-user@gnucash.org> wrote:
> And, as I noted in January, the sql format does not get compressed, so the
> f
Should be since the SQL (including SQLite3) backend saves each change
immediately so there is no bulk saving. The initial “save as” operation might
be, but that’s a one-time hit.
Regards,
John Ralls
> On May 17, 2018, at 6:35 AM, Sébastien de Menten wrote:
>
> Is the SQLite storage format im
Thanks to everyone for the helpful thread! This definitely helps answer
my questions about storage format.
On Thu, May 17, 2018 at 12:36:03AM -0500, Adrien Monteleone wrote:
> If all you want is the ability to run outside queries for custom reporting or
> data integration, then sqlite3 is probab
When playing with it I noticed zero performance hit on High Sierra. But I also
have no performance lag with XML. Mileage may vary.
Regards,
Adrien
> On May 17, 2018, at 9:07 AM, John Ralls wrote:
>
> Should be since the SQL (including SQLite3) backend saves each change
> immediately so there
I have used xml, postgresql, and sqlite (which must default to sqlite3
on Ubuntu) with gnucash. sqlite3, as mentioned already, is a good
compromise between a database backend and simplicity of set up.
PostgreSQL is, probably, technically the best of the database backend
options for being robust, a
MySQL and postgre are the only formats that can be password protected. I
have been using MySQL for many years. It takes more disc space, but it's
more secure, backups are small, and is an excellent backed for reporting.
On Thu, May 17, 2018, 3:58 PM GWB wrote:
> I have used xml, postgresql, and
13 matches
Mail list logo