Nabeel

Also, you guys have to DROP those two tables, I've made structure changes, so you don't want any trouble with the next updates. Thanks!

I like the second one

The title has it, just the issues with some fields showing up with a value of 2010

The addon isn't included, only the back-end data collection peice. The rest, with the front-page display, isn't. I'm not sure what tpls they are, I imagine they'd be as part of the download.

I think in another thread the column was still refernced as landing_stat when its landingrate, so you have replace all instances with that

Ah I see, can you try importing both of those files into both and see how it goes?

Revision 866: 2010 bug fix23 January 2010, 6:00 pm2010 bug fixSource: Revisions of /Download from http://downloads.phpvms.net/phpvms.beta.zip

Revision 865: 2010 bug fix23 January 2010, 5:56 pm2010 bug fixSource: Revisions of /Download from http://downloads.phpvms.net/phpvms.beta.zip

Yup, just into the same DB. I also included the other navdata table. Thanks!

You're on a dedicated though, right? I hope it'd work

A quick inquiry to all of your - I'm introducing navdata into phpVMS, for routes, just mainly a cosmetic thing. But it's quite a bit of overhead, to be honest. Here's how I've worked it out - Navigation data - fixes, waypoints, etc are on the API server. On first "use" they'll be retrieved, and stored in your database, though I'll make it available for you to load completely, locally. The reason I did this was because it's over 200,000 rows - about 6mb worth of data. It's also indexed, so that brings it to maybe 12mb size - quite a bit. But again, I'll have the .sql dumps available for download, in case you do want to load all of it locally. It doesn't do anything except take up space. The other part are airways, which is a smaller dataset - about 800kb, also indexed, about 1.5mb is size total then. Just over 8100 rows. This, I plan to distribute with phpVMS installs, since it's the more "intensive" dataset, determining the entry/exit points with the route, and which airway. This will be queried heavily, and it's a huge load on my end, and I can't effectively cache it for thousands of queries. But - on the clientside I can easily file-cache the lookups, so it's near instantaneous. The downside is the dataset size. So what I did, was link to the .sql file for the airways, and if you guys can just load it up in phpMyAdmin, and let me know if that import works. From there I'll determine if I'll include it, or do the same strategy I've done with the navdata. http://dev.phpvms.net/routeload/airways.sql And here's the navdb with the 200k+ rows: http://dev.phpvms.net/routeload/navdb.sql Also, include the type of hosting you're on - free, shared, etc. Thanks!!

What are your airlines?

I will check, might have missed adding the restriction in the code.

Have you looked in the database table to see what it looks like?

Yep, known bug. It's been fixed in beta though. Though if you're feeling adventurous http://bugs.phpvms.net/browser/trunk/admin/modules/Maintenance/Maintenance.php#L56 Line 56 and 57, find that code in that file (not sure if its the same line numbers), and replace those with that line 56 and 57 from above

Are you using http:// in front of the url setup?

In the admin panel, or the pilot side?

$_POST

OK, I've been able to duplicate the 2010 bug.

Ok for financials, can you go through by hand and calculate and make sure? They will be different from before, hopefully more accurate now

So where does the data show improperly?

Then a close bracket is missing

It could get corrupted on upload (FTP does that sometimes)

Yup, I said from SITE_ROOT, which is where phpvms is installed. Perhaps I could have worded it better.

UTF-8 is the right one. There's a configuration setting in local.config.php, PAGE_ENCODING, which you also have to set to UTF-8