gnucash-user Digest, Vol 129, Issue 3
John Donnee
jdonnee at ec.rr.com
Tue Dec 3 12:49:28 EST 2013
Hi Colin, thanks for the answer. I do have another easy question.
1. Is there a “Backup” command? I could not find one except in the manual it says that GNUCash makes a backup when any transactions have been entered.
So if I am not going to post any transactions but want to make a backup, do I use “Save As” since I do not see any “Backup” command?
Thanks
John Donnee
910.622.8111
8422 Emerald Dunes Rd.
Wilmington, NC 28411
On Dec 3, 2013, at 12:00 PM, gnucash-user-request at gnucash.org wrote:
> Send gnucash-user mailing list submissions to
> gnucash-user at gnucash.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.gnucash.org/mailman/listinfo/gnucash-user
> or, via email, send a message with subject or body 'help' to
> gnucash-user-request at gnucash.org
>
> You can reach the person managing the list at
> gnucash-user-owner at gnucash.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of gnucash-user digest..."
>
>
> Today's Topics:
>
> 1. Re: Automatic Reconcilliation using MT940 or OFX (David Carlson)
> 2. Re: SQL BackEnd Clarification (John Ralls)
> 3. Re: Missing Invoice (John Ralls)
> 4. Re: Missing Invoice (Roman)
> 5. Re: Missing Invoice (John Ralls)
> 6. Backing Up File (John Donnee)
> 7. Re: Backing Up File (Colin Law)
> 8. Re: SQL BackEnd Clarification (Derek Atkins)
> 9. Re: SQL BackEnd Clarification (Russell Mercer)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 02 Dec 2013 11:02:47 -0600
> From: David Carlson <david.carlson.417 at gmail.com>
> To: gnucash-user at gnucash.org
> Subject: Re: Automatic Reconcilliation using MT940 or OFX
> Message-ID: <529CBD37.2090206 at gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On 12/2/2013 9:27 AM, Derek Atkins wrote:
>> Hi,
>>
>> Egbert van der Wal <ewal at pointpro.nl> writes:
>>
>>> So I still have to do the manual reconcilliation even if there is a
>>> complete match with the imported OFX file?
>> Yes, because reconciliation is about making sure that your accounts
>> match the bank accounts at well defined boundaries. This is done by
>> going through your bank statement and "reconciling" your accounts to the
>> bank's view of your accounts. All that an import proves is that your
>> transaction has cleared the bank, which is why it gets marked as C.
>>
>> This is by all design.
>>
>>> And then still the issue remains that only half of the items are
>>> actually cleared, even though all of them have been matched (and are
>>> green) in the import matcher. The rest remain marked as 'N' even
>>> though I did select 'R' in the import matcher. Am I running into a bug
>>> here?
>> Sorry, I don't have an answer for this. It may be a bug or it may be
>> user input error. Sorry I cannot you with help that.
>>
>>> Thanks for your reply,
>>>
>>> Egbert van der Wal
>> -derek
>>
>>> On 02/12/13 16:17, Derek Atkins wrote:
>>>> Hi,
>>>>
>>>> Egbert van der Wal <ewal at pointpro.nl> writes:
>>>>
>>>> [snip]
>>>>> Then, additionally, when I select 'R' (or 'U + R', doesn't make a
>>>>> difference) and click 'Ok', it doesn't really work. About half of the
>>>>> transactions are marked as 'C' in the 'R' column in the register. The
>>>>> rest is marked 'N', and thus, nothing is marked 'Y'. This means that I
>>>>> can use this function to import the transactions, but not to reconcile
>>>>> them (even though the reconcilliation matcher suggests that it will do
>>>>> this). I'm also puzzled as to why only half of the transactions are
>>>>> actually marked 'C' and the rest 'N'. The console or GnuCash doesn't
>>>>> report any errors whatsoever.
>>>>>
>>>>> I'm using GnuCash 2.4.13, by the way.
>>>>>
>>>>> Any ideas on these issues?
>>>> This is how it is supposed to work. The only way to mark items "y" it
>>>> to go through the Reconcile process. The importer will only clear your
>>>> items.
>>>>
>>>>> Regards,
>>>>>
>>>>> Egbert
>>>>> Please remember to CC this list on all your replies.
>>>>> You can do this by using Reply-To-List or Reply-All.
>>>> -derek
>>>>
>>>
>>>
>
> Are you sure that the transaction import assistant actually matched
> every incoming transaction correctly to it's respective existing
> transaction when there was one? I have found that when there are
> somewhat similar looking transactions (the amounts may even differ by a
> small amount) the import assistant mistakenly matches to the wrong one.
> I double click every incoming transaction to check which existing one is
> matched, and too often I need to change the choice that the import
> assistant made. For the transaction mix that I typically see, it errs
> this way about 3 to 5 % of the time. I can imagine that in some cases
> the error rate would be much higher.
> Then, once a match error is made, the incoming transaction will not
> appear in a subsequent import because it was already matched to
> something. The easiest work-around is to click the 'R' box to change
> the status to 'c' instead of 'n'.
>
> The other result of a mismatch is that some transaction does not get
> imported. This is harder to fix. There are two ways to do it, but
> neither of them is user friendly.
> One way that I have been told works (but I have not tried it) is to
> deliberately import into a different account then manually correct the
> account after that import. The other is to edit the OFX file to change
> the transaction number of the missing transaction(s). To do that you
> must figure out the numbering scheme that the financial institution uses
> so that you can generate a number that was not used before and will not
> be used in the future. Not worth the trouble unless you really want to
> get the actual text from the import file.
>
> The bottom line in my opinion is to follow up with a real manual
> reconciliation when the statement arrives to catch errors from this
> process as well as errors from any other source.
>
> David C
>
>
> ------------------------------
>
> Message: 2
> Date: Mon, 2 Dec 2013 09:12:48 -0800
> From: John Ralls <jralls at ceridwen.us>
> To: Russell Mercer <rmercer206 at gmail.com>
> Cc: Derek Atkins <warlord at mit.edu>, "gnucash-user at gnucash.org"
> <gnucash-user at gnucash.org>
> Subject: Re: SQL BackEnd Clarification
> Message-ID: <CFA7A4DD-F825-4D77-B852-68F1A49888D7 at ceridwen.us>
> Content-Type: text/plain; charset=us-ascii
>
>
> On Dec 2, 2013, at 8:14 AM, Russell Mercer <rmercer206 at gmail.com> wrote:
>
>> Derek,
>>
>> To be clear then, what you are saying is that even though the SQL backends
>> like SQLite, MySQL or PostgreSQL have been offered as equal storage options
>> to the basic .xml file, the reality is that a potential for data loss
>> exists for them that does not exist for the .xml storage?
>>
>> It seems to me that if the potential for data loss exists by using the
>> alternate storage formats, this should be clearly noted in the
>> documentation. I would hate to be the new user that starts with the
>> software, enters a large amount of data into an sqlite format, for example,
>> and then loses data, as you say, because they happen to hit one of the
>> bugs.
>>
>> I completely understand that this is an all volunteer operation and that
>> the ability to address bugs is limited by the time that you and the other
>> programmers have to devote to the product. Don't mistake this for not
>> being appreciative of that, because the work you have done is tremendous
>> and the product is fantastic. At its most basic, it would seem that being
>> able to enter data and have it be saved in a regular manner is of extremely
>> high importance, to the extent of being expected functionality. If using
>> an SQL backend means that there are cases where saving does not always
>> occur and data loss could happen, that should be clearly noted that these
>> are not stable formats and the only recommended storage file type for
>> consistent saves is .xml.
>>
>> I hope I'm not taking this out of context and blowing it up into more than
>> it is. What may seem like something small to you from a developer
>> standpoint looms large to me when I hear that my data may not all be saved
>> in an SQL backend, when I think it is being saved.
>
> We've been pretty clear throughout the 2.4 life cycle that the SQL backend has issues and should only be used with great care and vigilance. Several bugs have been reported over the two years since 2.4's initial release regarding incorrect storage in some corner of Gnucash, and I fixed the last one of them last week.
>
> OTOH, I've also been using the SQL backend for my personal accounts since 2.4 released and I haven't had any problems, but that's because I don't use any of the features that had problems. After all, I'd fixed all of the features I use during the 2.3 cycle. ;-). But I don't use the business features, the mortgage calculator, or budgets. There are probably other features that I don't even know about and haven't tested. Other people do, and in some cases have submitted bugs. As I said, I've fixed all of them for 2.5.x, so I can confidently say that 2.6 will be a lot safer to use with the SQL backend than 2.4 is. That said, there still isn't comprehensive test coverage and GnuCash's code base is quite complex so that it's impossible to be sure that all execution paths call the write code upon which the SQL backend depends. Until we have that test coverage or have properly enforced the privacy of persistent objects (or better yet, both) we can't be absolutely certain that all u!
> ses of the SQL backend are as safe as the XML backend.
>
> Regards,
> John Ralls
>
>
>
>
>
>
> ------------------------------
>
> Message: 3
> Date: Mon, 2 Dec 2013 10:05:08 -0800
> From: John Ralls <jralls at ceridwen.us>
> To: Derek Atkins <warlord at MIT.EDU>
> Cc: "gnucash-user at lists.gnucash.org List"
> <gnucash-user at lists.gnucash.org>, Roman <romankal at verizon.net>
> Subject: Re: Missing Invoice
> Message-ID: <E224CBDC-161D-4DBF-BA23-8CC9597D854A at ceridwen.us>
> Content-Type: text/plain; charset=us-ascii
>
>
> On Dec 2, 2013, at 7:19 AM, Derek Atkins <warlord at MIT.EDU> wrote:
>
>> Hi,
>>
>> Roman <romankal at verizon.net> writes:
>>
>>> I run GnuCash 2.4.13 under Windows 7-x64 using MySQL as the database
>>> backend. I created an Invoice having an Invoice ID 'ID01', and posted it
>>> into an account (receivable). I now want to remove that posted entry and
>>> replace it with a different modified Invoice. In order to do so I must
>>> unpost the Invoice which will remove the entry.
>>>
>>> However, on running the 'Find Invoice' script, I get a list of ALL my known
>>> invoices except 'ID01'. And on checking the MySQL database 'invoices' table
>>> I see that this invoice is not present! Thus, I cannot remove that entry.
>>> But the entry for this transaction (posting the invoice) can be found in the
>>> 'transactions' table. (By the way, that invoice did exist until recently.)
>>>
>>> How should I proceed? Based on developer recommendations, I have made no
>>> modifications or deletions directly via MySQL. Furthermore, there apparently
>>> is no intent to provide Invoice removal options. Is it safe to remove the
>>> record in table 'transactions' referencing Invoice 'ID01'? Or can I add a
>>> record to the 'invoices' table with the proper guid? Where would I find that
>>> guid?
>>>
>>> Is there a set of actions that I can perform on the MySQL backend to remove
>>> this unwanted invoice transaction for a missing invoice?
>>
>> First, why are you using MySQL? Most likely you hit a data loss bug
>> somewhere and you've now run into a bigger issue where you have
>> inconsistent data. Alas, I don't know a good way to correct that.
>> GnuCash (rightfully!) stops you from deleting an Invoice Transaction,
>> but if you have no Invoice to unpost then the transaction is stuck.
>>
>> Considering there is no way to delete an invoice, I'm curious how you
>> got into this state in the first place. Like I said, most likely a data
>> corruption bug in the SQL backend -- which is why for YEARS we have been
>> telling people not to use SQL for real data. Now you know why.
>>
>
> If there's no way to delete an invoice, then the SQL backend can't delete it either: The only way to make a SQL DELETE statement is to free an instance and mark it dirty inside of a BeginEdit/CommitEdit block for that instance, which would also result in its being deleted from the XML backend.
>
> So far, though, we don't know that the invoice *was* deleted; it's possible that it just had its name changed.
>
> To find the guid of the invoice, run
> select * from slots where obj_guid is "<transaction guid>" and name like "gncInvoice%";
>
> The resulting row's name will be either gncInvoice or gncInvoice/invoice-guid. In the latter case the second guid in the row is the invoice; in the former case you need to run
> select * from slots where obj_guid is "<result second guid>" and name like "%invoice-guid";
> and that row's second guid will be the invoice. Run
> select * from invoices where guid is "<invoice guid>";
> select * from entries where invoice is "<invoice guid>";
> to make absolutely sure that it's been deleted.
>
> If it really has been deleted your best bet is to copy another invoice, changing only the guid to match the missing one and the name so you can find it easily. You need rows in both the invoices and entries tables. I suggest that you first "save as" your database to SQLite3 and test on that so that you don't risk any more damage to your MySQL database.
>
> Regards,
> John Ralls
>
>
>
>
>
>
>
>
>
> ------------------------------
>
> Message: 4
> Date: Mon, 2 Dec 2013 19:17:03 +0000 (UTC)
> From: Roman <romankal at verizon.net>
> To: gnucash-user at lists.gnucash.org
> Subject: Re: Missing Invoice
> Message-ID: <loom.20131202T200248-974 at post.gmane.org>
> Content-Type: text/plain; charset=us-ascii
>
> Hi Derek,
>
> Derek Atkins <warlord <at> MIT.EDU> writes:
>
>>
>> Hi,
>>
>> Roman <romankal <at> verizon.net> writes:
>>
>>> I run GnuCash 2.4.13 under Windows 7-x64 using MySQL as the database
>>> backend. I created an Invoice having an Invoice ID 'ID01', and posted it
>>> into an account (receivable). I now want to remove that posted entry and
>>> replace it with a different modified Invoice. In order to do so I must
>>> unpost the Invoice which will remove the entry.
>>>
>>> However, on running the 'Find Invoice' script, I get a list of ALL my known
>>> invoices except 'ID01'. And on checking the MySQL database 'invoices' table
>>> I see that this invoice is not present! Thus, I cannot remove that entry.
>>> But the entry for this transaction (posting the invoice) can be found in the
>>> 'transactions' table. (By the way, that invoice did exist until recently.)
>>>
>>> How should I proceed? Based on developer recommendations, I have made no
>>> modifications or deletions directly via MySQL. Furthermore, there apparently
>>> is no intent to provide Invoice removal options. Is it safe to remove the
>>> record in table 'transactions' referencing Invoice 'ID01'? Or can I add a
>>> record to the 'invoices' table with the proper guid? Where would I find that
>>> guid?
>>>
>>> Is there a set of actions that I can perform on the MySQL backend to remove
>>> this unwanted invoice transaction for a missing invoice?
>>
>> First, why are you using MySQL? Most likely you hit a data loss bug
>> somewhere and you've now run into a bigger issue where you have
>> inconsistent data. Alas, I don't know a good way to correct that.
>> GnuCash (rightfully!) stops you from deleting an Invoice Transaction,
>> but if you have no Invoice to unpost then the transaction is stuck.
>>
>
> I am using MySQL because I have the server running on my computer and
> because GnuCash has offered it as a back-end. Furthermore, I am more
> familiar with it than with XML. And I am more comfortable with Perl scripts
> that can generate reports from MySQL data than with Scheme programming or
> Lisp. (However I can somewhat understand your view since Scheme was
> developed at MIT.)
>
>> Considering there is no way to delete an invoice, I'm curious how you
>> got into this state in the first place. Like I said, most likely a data
>> corruption bug in the SQL backend -- which is why for YEARS we have been
>> telling people not to use SQL for real data. Now you know why.
>>
>
> Thanks for the comments - however, I was hoping for a better response.
> Actually one can delete an Invoice if one is willing to work directly with
> the MySQL database. But great care must be taken in doing so. With this in
> mind, can you tell me whether ALL user data is stored in MySQL or whether
> there is another, perhaps hidden, resource. In other words, are the XML file
> and MySQL equivalent data bases?
>
>> Sorry,
>>
>>> Thanks for any help here.
>>>
>>> Roman
>>
>>> Please remember to CC this list on all your replies.
>>> You can do this by using Reply-To-List or Reply-All.
>>
>> -derek
>>
>
>
>
>
>
>
> ------------------------------
>
> Message: 5
> Date: Mon, 2 Dec 2013 13:16:02 -0800
> From: John Ralls <jralls at ceridwen.us>
> To: Roman <romankal at verizon.net>
> Cc: "gnucash-user at lists.gnucash.org List"
> <gnucash-user at lists.gnucash.org>
> Subject: Re: Missing Invoice
> Message-ID: <6B7502AC-C1B0-4DF8-9282-9861F8D47FFD at ceridwen.us>
> Content-Type: text/plain; charset=windows-1252
>
>
> On Dec 2, 2013, at 11:17 AM, Roman <romankal at verizon.net> wrote:
>
>> Hi Derek,
>>
>> Derek Atkins <warlord <at> MIT.EDU> writes:
>>
>>>
>>> Hi,
>>>
>>> Roman <romankal <at> verizon.net> writes:
>>>
>>>> I run GnuCash 2.4.13 under Windows 7-x64 using MySQL as the database
>>>> backend. I created an Invoice having an Invoice ID 'ID01', and posted it
>>>> into an account (receivable). I now want to remove that posted entry and
>>>> replace it with a different modified Invoice. In order to do so I must
>>>> unpost the Invoice which will remove the entry.
>>>>
>>>> However, on running the 'Find Invoice' script, I get a list of ALL my known
>>>> invoices except 'ID01'. And on checking the MySQL database 'invoices' table
>>>> I see that this invoice is not present! Thus, I cannot remove that entry.
>>>> But the entry for this transaction (posting the invoice) can be found in the
>>>> 'transactions' table. (By the way, that invoice did exist until recently.)
>>>>
>>>> How should I proceed? Based on developer recommendations, I have made no
>>>> modifications or deletions directly via MySQL. Furthermore, there apparently
>>>> is no intent to provide Invoice removal options. Is it safe to remove the
>>>> record in table 'transactions' referencing Invoice 'ID01'? Or can I add a
>>>> record to the 'invoices' table with the proper guid? Where would I find that
>>>> guid?
>>>>
>>>> Is there a set of actions that I can perform on the MySQL backend to remove
>>>> this unwanted invoice transaction for a missing invoice?
>>>
>>> First, why are you using MySQL? Most likely you hit a data loss bug
>>> somewhere and you've now run into a bigger issue where you have
>>> inconsistent data. Alas, I don't know a good way to correct that.
>>> GnuCash (rightfully!) stops you from deleting an Invoice Transaction,
>>> but if you have no Invoice to unpost then the transaction is stuck.
>>>
>>
>> I am using MySQL because I have the server running on my computer and
>> because GnuCash has offered it as a back-end. Furthermore, I am more
>> familiar with it than with XML. And I am more comfortable with Perl scripts
>> that can generate reports from MySQL data than with Scheme programming or
>> Lisp. (However I can somewhat understand your view since Scheme was
>> developed at MIT.)
>>
>>> Considering there is no way to delete an invoice, I'm curious how you
>>> got into this state in the first place. Like I said, most likely a data
>>> corruption bug in the SQL backend -- which is why for YEARS we have been
>>> telling people not to use SQL for real data. Now you know why.
>>>
>>
>> Thanks for the comments - however, I was hoping for a better response.
>> Actually one can delete an Invoice if one is willing to work directly with
>> the MySQL database. But great care must be taken in doing so. With this in
>> mind, can you tell me whether ALL user data is stored in MySQL or whether
>> there is another, perhaps hidden, resource. In other words, are the XML file
>> and MySQL equivalent data bases?
>
>
> There are stores of UI state, preferences, and some other general settings in ~/.gnucash and ~/.gconf. That has no data relevant to your invoice problem; everything that is stored is stored in the selected backend, the MySQL database in your case. When you run ?file save as?, everything does get stored, even to a SQL backend. The problem is that in normal operation, the SQL backend stores every time ?commit edit? is called, and it stores only the object on which commit edit is called and only the parts that are marked as having been changed (?dirty?), where the XML backend just uses the ?dirty? flag to indicate that *something* needs saving, and saves everything in memory. For many years developers relied on that and were careless about marking things dirty or wrapping state changes in BeginEdit/CommitEdit. We?re still trying to track down all of those skipped spots.
>
> That?s unlikely to explain how your invoice got deleted, if it did. I proposed some queries in my previous reply and I?m looking forward to hearing what you find out.
>
> Regards,
> John Ralls
>
>
>
>
> ------------------------------
>
> Message: 6
> Date: Mon, 2 Dec 2013 16:37:09 -0500
> From: John Donnee <jdonnee at ec.rr.com>
> To: GnuCash Users List <gnucash-user at gnucash.org>
> Cc: John Donnee <jdonnee at ec.rr.com>
> Subject: Backing Up File
> Message-ID: <D4EA4418-6618-40C0-A089-45CE60E97328 at ec.rr.com>
> Content-Type: text/plain; charset=us-ascii
>
> I read the sections on Backup and Recovery and I have a question. I had my data file get corrupt today so I used the latest backup file with the long number to make my entries.
>
> Question:
>
> 1. Do I now do a Save As and give it a new file name that is shorter than the one with the long number string?
> 2. The next time, the new file will open.
>
> Is this the correct way to recover from a bad file??
>
> Thanks
> John Donnee
>
> 910.622.8111
> 8422 Emerald Dunes Rd.
> Wilmington, NC 28411
>
>
>
>
> ------------------------------
>
> Message: 7
> Date: Mon, 2 Dec 2013 21:56:26 +0000
> From: Colin Law <clanlaw at gmail.com>
> To: John Donnee <jdonnee at ec.rr.com>
> Cc: GnuCash Users List <gnucash-user at gnucash.org>
> Subject: Re: Backing Up File
> Message-ID:
> <CAL=0gLsEscndyOo5LJGn6YdRv97X8kt2fMuA23H2d7hCo+eBZw at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> On 2 December 2013 21:37, John Donnee <jdonnee at ec.rr.com> wrote:
>> I read the sections on Backup and Recovery and I have a question. I had my data file get corrupt today so I used the latest backup file with the long number to make my entries.
>>
>> Question:
>>
>> 1. Do I now do a Save As and give it a new file name that is shorter than the one with the long number string?
>> 2. The next time, the new file will open.
>>
>> Is this the correct way to recover from a bad file??
>
> Yes, you can use the same name as the original file if you want. Also
> it is a good idea to take additional backups to CD or another computer
> occasionally in case the machine goes up in smoke. If the data are
> really important then keep an offsite copy in case the building goes
> up in smoke.
>
> Colin
>
>
> ------------------------------
>
> Message: 8
> Date: Tue, 03 Dec 2013 10:37:22 -0500
> From: Derek Atkins <warlord at MIT.EDU>
> To: Russell Mercer <rmercer206 at gmail.com>
> Cc: "gnucash-user at gnucash.org" <gnucash-user at gnucash.org>
> Subject: Re: SQL BackEnd Clarification
> Message-ID: <sjmk3fm54jx.fsf at mocana.ihtfp.org>
> Content-Type: text/plain
>
> Russell Mercer <rmercer206 at gmail.com> writes:
>
>> Derek,
>>
>> To be clear then, what you are saying is that even though the SQL backends
>> like SQLite, MySQL or PostgreSQL have been offered as equal storage options to
>> the basic .xml file, the reality is that a potential for data loss exists for
>> them that does not exist for the .xml storage?
>
> They have never been offered as "equal storage options". They are just
> "storage options", but XML is still the default for a very good reason.
> But yes, the reality is that a potential for data loss exists for them
> that does not exist for the xml storage.
>
>> Please remember to CC this list on all your replies.
>> You can do this by using Reply-To-List or Reply-All.
>
> -derek
>
> --
> Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
> Member, MIT Student Information Processing Board (SIPB)
> URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH
> warlord at MIT.EDU PGP key available
>
>
> ------------------------------
>
> Message: 9
> Date: Tue, 3 Dec 2013 08:00:56 -0800
> From: Russell Mercer <rmercer206 at gmail.com>
> To: Derek Atkins <warlord at mit.edu>
> Cc: "gnucash-user at gnucash.org" <gnucash-user at gnucash.org>
> Subject: Re: SQL BackEnd Clarification
> Message-ID:
> <CAB5KxtW1MKYLTL_CMHT1JDO6HNs7_6QpGJAhji5RcjXNWOLCeQ at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> I think it is rather important that this fact be noted prominently as a
> warning on the website. I am sure, as John said, that there has been
> discussion through the development process of the various bugs related to
> the SQL backend. If you come to www.gnucash.org for the first time, find
> the download, then look at the basic documentation, there is nothing
> warning you that these other "storage options" contain potential for data
> loss that is not there with the .xml version. While it may not have been
> hidden, I think it could be made more explicit.
>
> That is my 2 cents. Aside from this, please know the work you are doing is
> very much appreciated.
>
> Thanks,
> Russell
>
>
> On Tue, Dec 3, 2013 at 7:37 AM, Derek Atkins <warlord at mit.edu> wrote:
>
>> Russell Mercer <rmercer206 at gmail.com> writes:
>>
>>> Derek,
>>>
>>> To be clear then, what you are saying is that even though the SQL
>> backends
>>> like SQLite, MySQL or PostgreSQL have been offered as equal storage
>> options to
>>> the basic .xml file, the reality is that a potential for data loss
>> exists for
>>> them that does not exist for the .xml storage?
>>
>> They have never been offered as "equal storage options". They are just
>> "storage options", but XML is still the default for a very good reason.
>> But yes, the reality is that a potential for data loss exists for them
>> that does not exist for the xml storage.
>>
>>> Please remember to CC this list on all your replies.
>>> You can do this by using Reply-To-List or Reply-All.
>>
>> -derek
>>
>> --
>> Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
>> Member, MIT Student Information Processing Board (SIPB)
>> URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH
>> warlord at MIT.EDU PGP key available
>>
>
>
> ------------------------------
>
> _______________________________________________
> gnucash-user mailing list
> gnucash-user at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-user
>
>
> End of gnucash-user Digest, Vol 129, Issue 3
> ********************************************
More information about the gnucash-user
mailing list