Barry Stuart’s Advice
Bob, et all updaters.
This is a very complex issue to answer quickly and easily. In its basic form as you outline below, “Yes”, you are correct in your answer, you cant set a flag for updating (U) if the record flag is already set to new record (N)!
Reading all of the thread on this mail it becomes obvious that, because of the way the Db is structured, the problem is more complex to understand, and, thus work-around! When I first explained years ago about how the updating process worked it seemed pretty logical to understand, given that the structure was being upgraded and explained to the group as these changes took place. Now I am outside looking in at the updating process and I have to say it looks a bit confusing to try and offer a quick “rules to observe” at the present stage of the Db structure!
There are a few things I would suggest need change to try and add some extra protection to an updaters input, mostly around NEW records, because this is without doubt the problem area.
I am away chasing railways again next week around Europe, but, as the nights will be longer I will take a pen and paper and try to cobble together a potential solution to the problem.
First thought is to make a new record NON-UPDATABLE by the updater who added it till such times as the record has been produced through the master Db and thus out to the group. Initial thought, not easy to initiate a logical (Db wise) argument.
One option, but avoiding the Db argument path. When an updater holds NEW records he is forced to produce these in an update out to the master Db before he can close the Db session he added them in. Argument for this method would be to protect new records in case the PC went down before update was produced (reasonably easy to do by setting N flag to M? flag only after update is ready for sending to master) and then is held at (say) M? on the updaters Db till the update from the master to the group is run back in to the updaters Db, at which point M becomes the default archive flag of A!
If this option is followed through then you will only add one new letter to the updating production scripts (M in this instance) and you would only be dealing with a minimum amount of recode work. Note, it will be minimal, but it WONT be a walk in the park job, it will need thinking through and it will need testing out at each stage!
To pre-empt the question “Why” can this problem happen?
The Db was, years ago, built as a flat field structure, as a lot of Db’s still are! It has evolved over the years into a fully relational system and this opens up potential problem areas when a Db is being used in a non closed environment (updated by many users who are not all working on a single Db (master copy) outside a network)
In a nutshell. When a new record is entered there is initially only 1 record table, the core data. If a previous reg is added at the same time it then adds a new record to the history table, an airfield, new record to the fields table, and so on and so forth. But it ONLY adds these new records to tables if you add all this data at the same time. Move to another record and your new record is available to you, the creator of that record, till such times as its been through the system!
Barry
…………………………
From: Bob Clarke [mailto:bcwithe@ntlworld.com]
Sent: 15-10-2011 19:53
To: ‘paceditors@googlegroups.com’
Subject: RE: [paceditors] Attn Bob re AB47 Doug, et All.
This issue was discussed on the group quite some time ago. Stu Telford raised the initial concern following instances of updates not being reflected in the database even though Stu had put the updates in.
My understanding, and I do not mind being corrected, is that once you have updated a record, a flag is set to denote a change has been made. Subsequent changes will not influence this flag until it has been run through in an update.
Now the problem, you enter a new frame into your copy of the Db, this will flag the frame as (N)ew and will find its way into the database once run through the master. At the point you entered this change, the database routine did a sweep of what had been added and identified these records for the update. This implies that once the update check routine has run, it does not re-run following additional material/information being added.
This has been checked and verified with Stu. Now, if this is not the case, then why have we so much concern about missing “bits” that are known to have been added but are not evident through the master database.
I have copied Barry on the email to see if he is able to confirm or refute observations.
For the future, I would recommend that once you have added or amended a record and saved it to an update, leave it alone until it comes through the master.
If I get any more info on this I will post it to the group. Bob
From: paceditors@googlegroups.com [mailto:paceditors@googlegroups.com] On Behalf Of Douglas Tillie
Sent: 15-10-2011 19:03
To: paceditors@googlegroups.com
Subject: Re: [paceditors] Attn Bob re AB47
That might be our best bet, Al……..maybe Bob will be able to shed more light on this for us. Doug.
—– Original Message —–
From: Al Henderson
To: paceditors@googlegroups.com
Sent: Saturday, October 15, 2011 2:24 PM
Subject: Re: [paceditors] Attn Bob re AB47 Doug,
I may well be in the same position, although having only been doing it a few months, the potential for problems is a lot smaller. Like you I don’t keep a list of updates I make so can’t really check. Might be we just have to move on and fix any problems as and when they arise.
Cheers, Al.
On 15 October 2011 13:51, Douglas Tillie <douglas.tillie@btinternet.com> wrote:
Appreciate your response, Peter.
Given that you were not aware of this problem either I’m now even more concerned……..the thought of deleting and inputting again is scary to say the least (I don’t keep a separate note of each frame I update)…..not just in terms of the numbers of frames involved; more with identifying the records that are suspect.
My question, to Bob, is can he glean the data from my / your copy of each database to fill any gaps……? One other question would be why when an update is produced does it not simply compare the after with before and present the differences…….that’s certainly what I was led to believe at the outset.
I think it’s now essential that we have a standard procedure for all of this……how many other updaters are in the same position as ourselves….?
Kind regards, Doug.
—– Original Message —–
From: peter watson
To: paceditors@googlegroups.com
Sent: Saturday, October 15, 2011 1:35 PM
Subject: RE: [paceditors] Attn Bob re AB47
Hi Doug
Thank you for your note. I, for one, was not aware of this problem and am probably in the same situation as you. In many instances I have updated items prior to submission. In some cases you have to take 2 attempts as not all fields can be accessed on the New record screen. If these are not picked up then a lot of my entries are not complete
As they look ok on the updaters machine I don’t know the answer to these historic items. The only thing I can think of is where we know which records are a problem we need to delete and start again. I think where others have tried to do a subsequent amendment that has not worked
Regards Peter
From: paceditors@googlegroups.com [mailto:paceditors@googlegroups.com] On Behalf Of Douglas Tillie
Sent: 15 October 2011 11:57
To: paceditors@googlegroups.com
Subject: Re: [paceditors] Attn Bob re AB47 Morning Peter and Bob,
That would have been me that added these AB47s……all former French mil examples. All the data I added is showing in my Db however I’ve been reading the thread about editing new entries before they are issued to the membership that appeared while I was away……..is this what is causing the problem do you reckon……? If it is then it is highly unfortunate as I have in the past regularly added new frames then once in the Db add more p.i.s, canx etc.
I had no idea that this was an issue however if this does turn out to be the case then I’ll ensure that a frame is added purely with one reg and then issued in an update before any other info is added……..were all other editors aware of this issue…..as this is surely a significant problem…….does this mean a two level exercise to ensure that all the data is able to be seen for that a/c…….?
Given that my copy of the Db has all the data for each of the frames you mention, Peter, does that mean they only exist on my
copy and if so how do I get the data to show for everybody. Another question, how do we deal with the many other new frames that I’ve added and then edited with p.i.s etc…….a very good / or bad example of mine would be the Oz register where since taking responsibility earlier this year I’ve added several hundred new frames…..and in many cases then added other info before issuing the update…….it seemed correct to get all the info for a frame in place at the one time.
In my updates to you, Bob, does any of the data exist that I added…..and if not how do you want to play it……? Look forward to hearing from you.
Kind regards, Doug.
