<div dir="auto">Just to weigh in on the technical side as someone who has both programmed software that does this and also someone on the help desk that dealt with other software.<div dir="auto"><br></div><div dir="auto">Nothing is perfect.</div><div dir="auto"><br></div><div dir="auto">Things that can break a software lock:</div><div dir="auto"><br></div><div dir="auto">* Computer crash or shutdown as already noted.</div><div dir="auto">* User starts working and goes to lunch/a meeting/whatever</div><div dir="auto">* Database server restarted/crashed (most clients can end up in a weird state at this point).</div><div dir="auto"><br></div><div dir="auto">Things that seem like a good idea:</div><div dir="auto"><br></div><div dir="auto">* Implement a 30minute time out.</div><div dir="auto">* Allow IT to override the lock outs.</div><div dir="auto">* Allow &quot;more important&quot; staff to override the locks.</div><div dir="auto"><br></div><div dir="auto">Why they&#39;re not:</div><div dir="auto">* User goes to lunch etc and lock times out/overridden and then all their work is lost.  Bonus points if the work lost was by some of the more awkward/higher ranking staff members.</div><div dir="auto">* You get to watch the arguments for the third one which can be amusing.</div><div dir="auto"><br></div><div dir="auto">Having said all of this, having a lock option of any sort and understanding the problems it may cause is probably a good choice to have for some sites.</div><div dir="auto"><br></div><div dir="auto">Regards,</div><div dir="auto"><br></div><div dir="auto">Wayne</div></div><div class="gmail_extra"><br><div class="gmail_quote">On 26 Jun 2017 12:31, &quot;Rob Landry&quot; &lt;<a href="mailto:41001140@interpring.com">41001140@interpring.com</a>&gt; wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
I went through similar issues with my music scheduling programs. In the end, it turned out to be easier for the users to solve this problem by communicating among themselves than to craft a technical solution. Technical solutions to this sort of problem tend to be messy (e.g. user shuts down computer without properly logging out, so log stays locked forever).<br>
<br>
<br>
Rob<br>
<br>
On Thu, 22 Jun 2017, Patrick wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Today someone was voice tracking and another person went into the log editor accessing the same<br>
log. I believe the way the log editor works is the entire log is loaded in and then written back when<br>
done, causing any voice tracks recorded during that time to be overwritten.<br>
<br>
If this is true, would it be a good idea to place some kind of lock on the database when someone<br>
is voice tracking that prevents the log editor from opening the same log, at least without some kind<br>
of warning message?<br>
<br>
Patrick<br>
<br>
<br>
</blockquote>
______________________________<wbr>_________________<br>
Rivendell-dev mailing list<br>
<a href="mailto:Rivendell-dev@lists.rivendellaudio.org" target="_blank">Rivendell-dev@lists.rivendella<wbr>udio.org</a><br>
<a href="http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev" rel="noreferrer" target="_blank">http://caspian.paravelsystems.<wbr>com/mailman/listinfo/rivendell<wbr>-dev</a><br>
</blockquote></div></div>