×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
What we do is have 2 versions of the display file, with one of them being the prior version
When the display file needs to be changed, we get the prior version, copy the latest version into the prior version and change THAT version
We obviously need to change the program to look at this latest version
Hope that makes some sense
Alan Shore
E-mail : ASHORE@xxxxxxxx
Phone [O] : (631) 200-5019
Phone [C] : (631) 880-8640
‘If you're going through hell, keep going.’
Winston Churchill
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Joe Pluta
Sent: Monday, April 02, 2018 12:19 PM
To: midrange-l@xxxxxxxxxxxx
Subject: Re: Allocating a display file
On 4/2/2018 11:02 AM, David Gibbs wrote:
On 4/2/2018 10:53 AM, Joe Pluta wrote:
I'm just wondering if anybody else has ever felt a need to
exclusively lock a display file and if so, how they got around this
particular error.
This is something that most change control products have to deal with.
The best that can be done is ensure that the display file isn't in use
before trying to operate on it.
david
That's the conclusion I'm coming to, with all the normal issues of "well, it wasn't in use when I started the compile". And clearly there is SOME sort of locking going on since you can't delete the object while it's in use. I was just hoping I had perhaps overlooked some way to materialize that lock at the API level.
And if you haven't done it, David, then I'm reasonably certain there's nothing to be done about it. :)
midrange.com
