<div dir="ltr"><div dir="ltr"><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div><br></div></div></div></div></div></div></div></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Mar 20, 2019 at 5:39 PM Remco Viëtor <<a href="mailto:remco.vietor@wanadoo.fr">remco.vietor@wanadoo.fr</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
Agreed that getting the multi-system issues sorted properly would be a good <br>
step. <br>
<br>
But when you have a remote (networked) collection, there's a very good chance <br>
that it will be accessed from different terminals (and not just through <br>
different OSes). And *that* means you'll get concurrent access sooner or <br>
later.<br>
<br>
>From what I gathered here, concurrent access to the database is *not* <br>
supported yet. Result: sooner or later you will get database corruption. With <br>
all the headaches that causes.<br>
<br>
So, until that kind of issues are dealt with, it might not be the best of <br>
ideas to make multi-system access too easy (and noting the caveats in the <br>
configuration dialog isn't enough, in practice).<br></blockquote><div><br></div><div>Couldn't, in a first phase, the first instance of DK that accesses the DB just lock the DB. Other instances would then emit a message "waiting for other instances to release the DB" until the first user closes his DK instance. That would be a quick fix to your issue and at least allow the same user to access the DB across different OSes.</div><div><br></div><div>Phase 2, only set the lock when an actual DB access occurs. Then you're getting very close to concurrent access without corruption.</div><div><br></div><div>Hajo</div></div></div>