Re: File open


Steven Blank
 

Dean,

I first implemented functionality in an application to limit each user to a single login by locking their username with Lock(User(0)) in a late service pack of v9.4, but it didn't really come into its current, fully polished state until v10.1. This same application is currently operating in uniPaaS v1.9o and has been tested and is ready to go in v2.5, when (if) they ever get a round tuit.

The thing is, the users of this system were and remain some of the least patient users I've ever encountered. They'd as soon three-finger an application as take a second breath; it's their go-to solution for anything. Really.

This has never been more of a problem than during their early wireless days. For more than a year, they struggled with a half-assed, DIY wireless network in their main warehouse, before they were finally convinced to cough up several grand and get the job done right. In the meanwhile, however, one needed only to sneeze to lose one's network connection, lock-up one's computer, and, as a result, often leave data in an inconsistent state. So I expended a great deal of time and effort fixing data anomalies and otherwise making the software as fault-tolerant as possible.

Moreover, I seem to recall hearing of at least one other house (FactoryMaster? AOD?) having problems as you describe, but, try as I might (and I have indeed tried) to produce such artifacts, I cannot. I even tried again just now, albeit for only a couple of minutes, but am still unable to cause the internal locking system to hiccup. I might be inclined to think that I'd done something extraordinary, but it's really not in the least exotic: I attempt to Lock the resource in the Main Program's Task Prefix, proceeding only if successful, and subsequently UnLock the same resource in the Main Program's Task Suffix.

It works for me; of course, YMMV.

Steve Blank



At 05:59 AM 1/5/2017, you wrote:

Hello Steve,

Yes, I'm aware of that function - it came out many years ago and I recall thinking 'wow' about it at the time and telling any of my colleagues that would listen, ‘hey, have you checked out the new cool Locking function blah blah or suchlike... Indeed, I put it to work right away only to be sorely disappointed to discover it simply didn't work properly (or at least not quite as I expected/needed it to). My anticipatory bubble was quickly burst.

It’s so long ago, I can’t quite recall what the issue was. I remember thinking that MSE had given us an ‘in’ to their own tried and tested locking mechanism, which is fundamentally similar to mine in that it is predicated on the use of a physical file on disk as a locking file and relies on letting the OS take care of preventing deletion when in genuine use etc.

Since then, either the boys & girls at MSE have fixed their function (perhaps on the quiet in a sub release following its first appearance) - or maybe it always worked and my use of it was flawed in some way. Clearly it must be working properly now, otherwise you presumably wouldn’t be using it – although, dare I say – are you really sure it works? Have you checked that a resourrce lock is released after the program that invoked it is given the ‘3 fingered salute’. In my case, I tried it, discovered it simply didn't do what I expected of it and so once bitten, forever shy. Perhaps this is unfair of me, but as is so often the case, once a robust solution to a given problem has been designed, it’s very easy to take that same code structure and bolt it into wherever it’s needed, sure in the knowledge that it just works.

Regards,Dean,

Regards,

Dean.

Join main@magicu-l.groups.io to automatically receive all group messages.