Hi,
so what do you mean with why do you open the database again? Maybe there
is a misunderstanding: I found no way to avoid the lock pop-up message;
I just launch gnucash and the pop-up window telling me about the locked
database comes immediately; at this point I have only three options:
open, though (which leads to connect to the database last used) / create
a new file / end program.
regards,
Johann
Am 2010-11-26 15:54, schrieb John Ralls:
On Nov 26, 2010, at 6:23 AM, Johann Wöckinger wrote:
Hi,
here are the answers:
I connect to a local postgres-database and I use linux (debian squeeze). I use the
hostname in the connectstring (not "localhost").
Here are the process id observations:
after start of gnucash until pop-up with lock-message appears:
30525 ? SLl 0:04 gnucash
30540 ? Ss 0:00 postgres: hans gnucash 192.168.129.8(36175) idle
after selecting open though and gnucash up and running with active database
connection:
30525 ? SLl 0:06 gnucash
30540 ? Ss 0:00 postgres: hans gnucash 192.168.129.8(36175) idle
31429 ? Ss 0:00 postgres: hans gnucash 192.168.129.8(47428) idle
in gnclock, the pid-entry is pid 30525
entry in gnclock not deleted on closing gnucash (checked by inspecting the
database-entry)
So, gnucash makes two connections, and the lock-message is generated on trying
to make the 2nd one.
regards,
J. Woeckinger
Am 2010-11-26 02:31, schrieb John Ralls:
On Nov 25, 2010, at 1:44 PM, Johann Wöckinger wrote:
Yes, it's also in 2.3.17.
Am 2010-11-25 21:28, schrieb John Ralls:
On Nov 24, 2010, at 11:21 AM, Johann Wöckinger wrote:
Hello,
since Version 2.3.16RC1, I notice the following message popup on starting
gnucash:
GnuCash could not get exclusive write permission to postgres://.........
with some explaination for reasons for that.
It seems, that gnucash does not delete the lock entry in the database (table: gnclock)
when closing the application (I found the lock entry still in the database table after
closing gnucash), so it comes up with this warning on startup, which can be overridden on
selecting "open" - but its somewhat annoying.
This behaviour was not observed in former releases of the 2.3.x series.
Would be nice to have the former behavior.
Have you seen this with 2.3.17? It sounds like a duplicate of
https://bugzilla.gnome.org/show_bug.cgi?id=634392, which was fixed for 2.3.17.
Well, that's annoying, because I don't see the problem on my development system.
Are you connecting to a local (on the same machine) or network psql server?
On what OS are you running Gnucash? If you're connecting to psql on a different
machine, what OS is it running? What version of psql?
Please start gnucash and find its PID and the hostname of the machine running Gnucash.
Then quit Gnucash and, from psql, do "select * from gnclock". Are the hostnames
and PIDs the same?
At the end of gnucash.trace is there a warning about not finding the lock?
Well, that's a use-case I hadn't considered. Why do you open the database again
after Gnucash has already opened it for you?
To change the behavior, Gnucash would have to close and unlock the old
connection before opening the new one. If the open failed, it would have
nothing open and would present a blank window, where now if the open fails it
keeps the old connection (which for most users will be a different database).
Please, let's keep this on the list. Use "reply all" (or "reply list" if your
mail client can do that).
Regards,
John Ralls
_______________________________________________
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
