How to stop changing data

[hofs]

i have been reading a lot of topics about changing aircraft data in the database explorer.
But what ever i try some aircraft data are going back to the old data after starting up radarbox.
I also have been reading the topic from airnav about database and how it works and if i understood well after finding a mode s first of all it is checking in the data base if its already been written down and if not it wil go to other data base like Gas to see if they have the data.
But i already put the data in the database explorer so why does it go to Gas or airliner to get the wrong  data .
The data that is changing is most of the time german military aircraft.
Please tell me how to stop this.
Fred

[tarbat]

You can stop it by unticking the "Auto-Populate Aircraft Data" in Preferences.  However, you will then have to make any and all updates manually.

The problem itself is well understood, so hopefully will be addressed in a future version.

[hofs]

thanks for your quick reply .
Then we have to wait and see what happens in the future and until then i will stop changing data .
Fred 

[Chris11]

Can someone explain how ANRB auto-populates? When does it pull information from the database?

Here is the problem. If data is pulled down even if the fields are completed (ie corrected locally) then I do not want that as information that I have corrected (or local anomalies) will be overwritten. That means I must switch auto-populate off.

If I turn auto-populate off then my data will not be updated with new information so when I find information on flights in my area and submit them to the database updaters I could be wasting their time as the database could be updated already.

So - do I keep it on and constantly check my info for unwanted changes or do I waste the updaters time?

[DaveReid]

So - do I keep it on and constantly check my info for unwanted changes or do I waste the updaters time?

Hopefully you won't need to do either soon.

We're promised a new release of the RadarBox software which will:

a) include a much more intelligent updating architecture so that changes you make locally aren't overwritten by older data from the AirNav server, and

b) feature a much more up-to-date database incorporating all the work being done by the updaters, so that there should be less need for you to make manual updates anyway

No sign of it yet, though ...

[Chris11]

So - what you are saying is that I should do the latter.... waste the updaters time :) :)

[bearcat]

I think the trick to stop it overwritting your data is to have a photo in your Photo file for the A/c required. Either a copy of a similar A/c or one off the web. Failing that I use a dummy image " Sorry no Photo" and give it the A/c registration, leaving the LK, PT, LK2 ,PT2 fields blank

[DaveReid]

So - what you are saying is that I should do the latter.... waste the updaters time :) :)

Well hopefully the updaters won't consider it a waste of their time(!), but technically yes, you're right, there is no way of knowing whether submitted updates are already in the updaters' master database because those don't find their way into our local RadarBox databases.

[Marpleman]

So - do I keep it on and constantly check my info for unwanted changes or do I waste the updaters time?

Hopefully you won't need to do either soon.

We're promised a new release of the RadarBox software which will:

a) include a much more intelligent updating architecture so that changes you make locally aren't overwritten by older data from the AirNav server, and

b) feature a much more up-to-date database incorporating all the work being done by the updaters, so that there should be less need for you to make manual updates anyway

No sign of it yet, though ...

Totally back you on this one Dave!

It's frustrating to find a lot of info we're asked to check, is actually now (or indeed has been for a few weeks at least) on the central db, prior to the request coming in!

Equally frustrating to continually see threads crop up of this ilk, where there's still a lot of uncertainty and confusion surrounding the way records are maintained/updated

We've discussed this within the Updater team regularly,as we try to get to grips with the mechanics.

The comment made by Bearcat above is one possibility, but it really shouldn't have to get to this fiddly level, as I'm the first to admit to not being over confident in resorting to playing about with the records like this, and I'm sure countless other users aren't also!

Either a re-working of the architecture as you've mentioned above, or a facility to release a new db (as we've been working on) with continual updates at regular intervals (as is the norm with most of the major spotting db's out there) seems to us to be one possible way forward, otherwise it's going to be an ongoing problem, only resolved by completely flushing out one's db ever so often and let the updated info start to re-populate the users db as codes are picked up - not the best I'm sure you'll agree?

We have put our collective suggestions to AirNav, and they are currently being worked on.
Unfortunately we are not in a position to determine what solution will be forthcoming!

In the meantime, keep forwarding your observations and requests, and we'll keep adding/amending accordingly - after all, now the World Cup's finished, we've nothing better to do :-)

Regards

Rich

[tarbat]

It's frustrating to find a lot of info we're asked to check, is actually now (or indeed has been for a few weeks at least) on the central db, prior to the request coming in!

Why can't Airnav generate a CSV file from the central database with all the required fields (MS, AR, AT, AN, AC, CN, PT, LK, PT2, LK2), and anyone could then use the SQLite command line to import the updates into their local database.

It would involve the end-user entering just four commands:
   sqlite3 data/navdata.db3
    .separator ","
    .import aircraft.csv aircraft
    .exit

[Marpleman]

Hi Tarbat

Forgive my lack of technical knowledge (which I'm sure you've already gathered!), but could this be used just to deal with db additions/changes that could be identified by "date stamp", or would it entail a complete re-load of the db every time such a file was produced?

If so we could easily obtain a file of records only updated after a certain date/time.

I presume we would still have the dilema of this continuing to over-write any isolated changes people make themselves independant to the central db?

In my view, this would still be a suitable improvement over the current scenario

Rgds

Rich

[bratters]

Why can't Airnav generate a CSV file from the central database with all the required fields (MS, AR, AT, AN, AC, CN, PT, LK, PT2, LK2), and anyone could then use the SQLite command line to import the updates into their local database.

I am sure I am not alone when I say I don't want to get involved with SQLite or any other, seemingly  "complex" PC centred work. That's was not the idea when buying Radarbox which is simplicity itself and I'm sure sells on that basis.

The final answer to DB updating must not present any sort of challenge for the absolute PC beginner and must be simple and clearly accessible to each and every user.

[Chris11]

I can still not find the answer to my question - under what circumstances does the local database get updated. Does it only update if you left click the aircraft (as indicated in the help file)? Does it update in any filed is empty or does it check for a local photograph (as indicated above). I really do not want to waste Marpleman or Runway 31's time by sending them info they have but on the other hand I do not want my local updates overwritten. I have a number of "local" entries, mainly aircraft that have been imported into my country and still have the Mode S code of the country of origin.

[Marpleman]

Chris

Totally understand your frustrations!

I really think AirNav need to re-visit this urgently by offering/ posting a difinitive concise overview of how this all works.

I'm afraid I personally can't offer any clarification, and to be honest , with the upmost respect to the guys offering suggestions, don't think it's upto others to suggest their understanding, however reliable or helpful it is!

It's blatantly obvious that there is enough ambiguity with the whole process to confuse the majority of us!

Ref your point in sending us info that we already have - it's actually of benefit to receive this in some ways, as it continues to give us some feedback as to the validity of what we presume is actually happening!

Rgds

Rich

[tarbat]

I am sure I am not alone when I say I don't want to get involved with SQLite or any other, seemingly  "complex" PC centred work.

Understood.  But some of us are very happy to use a few commands to correct our local database.  I just wish Airnav would give us the choice.  They could issue a CSV file containing all updates after a certain date, for example.

Give me access to the central database, and I'll have a go at creating a CSV file myself!!!