On 31 August 2017 at 22:58, John Ralls wrote:
>
>
> > On Aug 31, 2017, at 2:36 PM, Mike or Penny Novack <
> stepbystepf...@dialup4less.com> wrote:
> >
> > Are folks saying that sqlite3 does NOT come with a backup/restore
> utility? I would think that at least somewhat strange.
>
> Not a bit. I ju
> On Aug 31, 2017, at 2:36 PM, Mike or Penny Novack
> wrote:
>
>
> I'm accomplishing that part by writing the sqlite3 file to Dropbox, which
> etc. etc. (other discussion of backups)
>
>
> I have no familiarity with "small" version implementations of SQL << in my
> working days, it was
I do something similar, working between my office PC & my home PC but I
use SpiderOakONE to backup & synchronize the two PC's. However, my
GnuCash file is an SQLite database and I found that SOO did not play
well with the GnuCash file, since GnuCash writes each transaction, one
at a time to the
There may be other ways to backup the database, but there is a built-in
.dump command which will "dump" the entire contents data & schema into
an SQL formatted, text file. This file can then be read back by sqlite
to replicate the entire database.
Since an sqlite database is just a single file
On 08/31/2017 03:46 PM, Robert Heller wrote:
> I have a desktop Linux machine (CentOS 6, x86_64) and a laptop Linux machine
> (also 6, x86_64). Generally I run GnuCash (2.4.15-4.el6) on my desktop Linux
> machine. I do have a procedure (shell script) to rsync the GnuCash data &
> prefs onto my
Hi,
We use gnucash in two distinct computers running on windows. Both have the work
files are in complete sync, including a copy of the gnucash database files.
Since the computers function at different moments in time, never at the same
time, they both run gnucash all right. No issues.
For insta
I'm accomplishing that part by writing the sqlite3 file to Dropbox, which
etc. etc. (other discussion of backups)
I have no familiarity with "small" version implementations of SQL << in my working
days, it was mainframe SQL under the DB2 database manger >>
Are folks saying that sqlite3 doe
At Thu, 31 Aug 2017 14:29:10 -0400 james wrote:
>
> On 08/31/17 13:35, Matthew Pounsett wrote:
> > On 31 August 2017 at 13:33, Geert Janssens
> > wrote:
> >
> >>
> >> While these solutions will work most of the time they all have the same
> >> risk:
> >> if the snapshot is made while gnucash i
> On Aug 31, 2017, at 10:35 AM, Matthew Pounsett wrote:
>
>
>
> On 31 August 2017 at 13:33, Geert Janssens wrote:
>
> While these solutions will work most of the time they all have the same risk:
> if the snapshot is made while gnucash is updating the db, you end up with an
> inconsistent db
On 08/31/17 13:35, Matthew Pounsett wrote:
> On 31 August 2017 at 13:33, Geert Janssens
> wrote:
>
>>
>> While these solutions will work most of the time they all have the same
>> risk:
>> if the snapshot is made while gnucash is updating the db, you end up with
>> an
>> inconsistent db file. I d
On 31 August 2017 at 13:33, Geert Janssens
wrote:
>
> While these solutions will work most of the time they all have the same
> risk:
> if the snapshot is made while gnucash is updating the db, you end up with
> an
> inconsistent db file. I don't know how well sqlite3 handles this so the
> risk
>
On donderdag 31 augustus 2017 19:08:28 CEST Matthew Pounsett wrote:
> On 31 August 2017 at 12:27, John Ralls wrote:
> > It also doesn't make backups, so unless the user does there's no way to
> > roll back to an earlier state. Since all changes are immediately written
> > to
> > storage there's al
On 31 August 2017 at 12:27, John Ralls wrote:
>
>
> It also doesn't make backups, so unless the user does there's no way to
> roll back to an earlier state. Since all changes are immediately written to
> storage there's also no way to abandon a bunch of changes by quitting
> without saving.
>
> I
> On Aug 31, 2017, at 7:37 AM, james wrote:
>
> OK,
>
> So is using a database faster? Stable? Any advantages?
>
> Worth the effort to participate in testing and development?
The only current advantages to using the database backend are that it saves
changes immediately rather than every n m
OK,
So is using a database faster? Stable? Any advantages?
Worth the effort to participate in testing and development?
James
On 08/29/17 22:00, David T. wrote:
> The biggest problem with the database back end is users' misconception
> that its use implies database functionality. They think it
The biggest problem with the database back end is users' misconception that its
use implies database functionality. They think it will allow them to perform
database actions on the data set, as well as have multiple users
simultaneously. As you know, neither of these is true at this time.
Davi
On 29 August 2017 at 19:12, D wrote:
> ...
> The database back end is stable, and has been for a while now. There is
> nothing to prevent a user from making use of it, even for production.
OK, but note the OP is going to use 2.6.15, which was released in Dec
2016 I believe. I don't know whether t
On August 29, 2017, at 8:50 PM, Colin Law wrote:
>On 29 August 2017 at 16:36, james wrote:
>> Hello all,
>>
>> Background
>> So I've been running on gnucash 2.4.11 for some years.
>> it's been great, the only problems were my lack of
>> knowledge of finance. I want to migrate to version 2.6.15
On 29 August 2017 at 16:36, james wrote:
> Hello all,
>
> Background
> So I've been running on gnucash 2.4.11 for some years.
> it's been great, the only problems were my lack of
> knowledge of finance. I want to migrate to version 2.6.15
> (using gentoo linux).
>
>
> My only accounting problem is
Hello all,
Background
So I've been running on gnucash 2.4.11 for some years.
it's been great, the only problems were my lack of
knowledge of finance. I want to migrate to version 2.6.15
(using gentoo linux).
My only accounting problem is my depreciation does not match
what the accountant has bee
20 matches
Mail list logo
