I very much appreciate the comments but to confirm, this definitely was
not a simultaneous user issue. There are just two of us, the lock
message is pretty clear and because of our schedules, there is also rare
overlap for when we might both even need to access the files.
That said, I still hope and presume it was somehow operator error in
some way though beyond the already discussed idea of accessing the same
data file repeatedly from very different versions, I cannot begin to
guess how it would even be possible to delete such a number of unrelated
transactions.
As for recovery, what I did was indeed go back just a few days,
basically a day before the data loss. The amount of work lost was
minimal, especially as I was able to export most of the transactions
that had been entered after the data loss and then import them into the
older file. Really, recovery and getting back to ground zero was not a
big deal.
Thanks!
===============================================
On 2/5/2023 3:33 PM, Phyllis Bruce wrote:
Has anyone suggested that you look back at older log files and recover from
one that is more complete? What's gone today may not have been gone last
month. Just saying....
On Sun, Feb 5, 2023 at 9:42 AM Michael or Penny Novack <
stepbystepf...@comcast.net> wrote:
On 2/5/2023 4:26 AM, David T. via gnucash-user wrote:
I'll briefly chime in here to suggest that network issues and potential
simultaneous access are more likely culprits for your data corruption and
loss.
I will second that. Gnucash does NOT support multiple simultaneous
users. It does support multiple sequential users but if used that way
the message "could not obtain lock" has to be treated very seriously. A
single user can override this and proceed anyway, but if there is ANY
chance a different user is accessing the data cannot do that.
For a program to support multiple simultaneous users it must be running
UNDER the control of a DBM (database manager) program. In which case the
simultaneous users might not even be using the same program to access
the database (as long as all such programs are running under the control
of the DBM). Back in my working days maintained apps running under DB2
(a DBM for mainframe SQL).
So in a case like this, multiple users and the data on a network drive,
that is overwhelmingly likely the problem. Unless you can definitely
rule out simultaneous access issues, look no farther. No point in trying
to analyze the details of what happened to the data because the
consequences of simultaneous access are unpredictable.
Michael D Novack
_______________________________________________
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-----
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.
_______________________________________________
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-----
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.
_______________________________________________
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-----
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.
