Where does Gnucash save it backup files when using mysql data source

[L. D. James]

On 07/05/2015 04:20 PM, AC wrote:
> On 2015-07-05 12:34, David G Hamblen wrote:
>>
>> On 07/05/2015 10:21 AM, Colin Law wrote:
>>> On 5 July 2015 at 10:47, L. D. James <ljames at apollo3.com> wrote:
>>>> When I first started using Peachtree, as far as I know, it was a
>>>> bunch of
>>>> local files very similar to the way Gnucash started out. Eventually they
>>>> incorporated a database engine.  It's a very powerful engine.  I can
>>>> research and give you the name of it.  The Linux version of the
>>>> engine is
>>>> extremely expensive.
>>> If that comment is in answer to my request for examples of
>>> applications that use mySQL and do database backups within the apps, I
>>> am not particularly familiar with Peachtree but I don't think it uses
>>> mySQL.  I think it uses the Pervasive database which is a very
>>> different beast to mySQL.  A big difference I think is that Pervasive
>>> is intended to be embedded within an app, whereas mySQL uses an
>>> external server over which gnucash has little control.
>> I use Peachtree extensively at work (GC at home) and yes, Peachtree uses
>> Pervasive, but their backups are simply a zip file of the entire data
>> directory.  They've got a Windows script which sets up the equivalent of
>> a cron job to do the zip backup to anywhere (I automatically backup to
>> an off-site server every two days).  So doing a compressed xml export as
>> previous posters have suggested would be good.  (I do that manually
>> about once a month at home - SaveAs, followed by reopening the mysql db.)
>> ...
>> (snip)
>> ...
> The Pervasive engine uses a file storage mechanism similar to flat file
> databases like sqllite.  That's why the backup process can be a simple
> zip archive.  This is by design since the Pervasive engine is intended
> to be embedded in software without necessarily requiring a separate
> application/server installation like would be required with MySQL,
> Postgres or other engines (except sqlllite which is also an embedded
> type of database).  This method of backup doesn't work with other
> database engines because they use files on disk as a type of virtual
> disk drive, writing data in various places within the file as the engine
> needs.  The file is never in a consistent state unless the database has
> been closed and flushed because of the random access nature of the files
> (no declared internal structure in the file like flat file databases).
>
> The argument about performing a "Save As" on a Gnucash database hosted
> on a database engine instead of the XML storage is just the data
> integrity.  Gnucash must be able to signal other clients that they must
> complete all transactions and close out their connections prior to the
> export otherwise there is no way to guarantee a write doesn't occur
> during the export (this would be a full database lock but it's
> inefficient and time consuming especially as the number of records
> grows).  There are better ways of doing this but they would have to
> happen outside of the Gnucash client.
When I was using Peachtree/Pervasive, the option was given to install on 
a server or client.  I chose the server option.  Then I used clients to 
login to and use the data on the server.  I stopped using Peachtree 
because I didn't want to retain the Windows server as a main part of my 
network.  If I could have easily afforded the $1500.00 to install it on 
my Linux server, I would have.  I couldn't justify the expense.  So I 
ran Windows on a virtual machine for Peachtree (for sever years) and in 
the recent months stop using it altogether and have switched to Gnucash.

I'm saying that to say, I was running it on a Windows server.  That was 
one of the install options that I chose.

I believe Peachtree is a very great and powerful accounting software.  I 
will miss it.  But I'll get used to Gnucash.  So far I like the support 
and see that it's growing.  I hope to participate and contribute in it's 
growth, if allowed.

The backup feature already exist with the Mysql the way it is.  I use it 
all the time with Gnucash, at this time.  It works flawlessly.  It takes 
a fraction of a second to backup the software.  I have the option of 
backing it up to XML or Sqlite.  In my environment the I can't back it 
up (save as) to Mysql because I have chosen not to give the userID that 
access.

Again, the data is stored on a server, on a different machine.  Any of 
the machines in my shop, as well as any of the offsite locations can 
access the accounting system and manually click "Save as" and have the 
complete data on their  local machine.

I don't understand why you're so animate on stopping the "save as" just 
because the data might grow large.  I can't imagine it growing so large 
that it would ever take more than a few seconds to "save as" two years 
of accounting data.  You can save a couple of thousand pages of 
Microsoft pages in a couple of seconds.

So again, it's working now.  What I have asked for is already 
implemented.  It is just lacking a feature to specify the directory and 
now and actually add numbers for incrementing to the user configured 
filename.

At present there multiuser feature isn't available in the mysql. But 
again, the saving (backing up) of the actual data is there and works 
flawlessly.

You're saying it won't work when multiuser is implemented because the 
data might change.  However, there are api's for SQL to lock the files 
so that the data doesn't change.  This is done all the time with file 
locking when working with any files.  I can't see why it would be so 
complicated for the database to be unavailable for two seconds while the 
"save as" functionality that already works, is happening.

-- L. James

-- 
L. D. James
ljames at apollo3.com
www.apollo3.com/~ljames