Pireps not submitting correctly

[Strider]

I have an issue that I dont know why it is happening. No pireps have been recorded today yet pilots have flown and have filed the pireps as I have gotten the emails stating they have. But they are not submitted, but it shows on the front page as they have flown, but the pirep ID is some really big number but the ID in the pirep table is not that big. Anyone know what could cause an issue like that? Or has anyone encountered this problem and fixed it, if so how did you fix it. I had to move to a new db, recently, and had to reimport the schedules db. Could that have caused a problem with the bids?

[ProAvia]

Were PIREPS working properly prior to today or the last few days?

Did your host happen to "upgrade" your PHP or MySQL/MariaDB version?

What have you added/edited in the last week or so?

Manual PIREPS, automated PIREPS (what ACARS program?), or both?

Have you checked the error_log file in main phpVMS directory and in /admin directory for any errors?

 

phpVMS version?

PHP version?

MySQL/MariaDB version?

 

Maybe check to see if the PHP configuration has changed in the last week. Maybe create a phpinfo.php file to check. For others who read this that don't know how... https://www.hostinger.com/tutorials/how-to-create-phpinfo-file

 

 

[Strider]

phpvms version 5.5.2

php version 7.1

mysql/mariadb version: 10.3.23-MariaDB-cll-lve

 

It was working fine up until yesterday. Now nothing is really working the way it should do. I can add schedules and codeshares, but sending airmail, submitting pireps are not working. The subitting pireps sends the email a pirep has been submitted, and it shows on the front page but with the wrong url the pirep id is way outside the number it should be, and when i check the db the pirep is not there. So it seems that it has given itself it's own db

[ProAvia]

A few members have reported issues with MariaDB 10.2 and higher - don't remember exactly what the issues were though. Rolling back to MariaDB 10.1 resolved the issues for them. Of course, rolling back is not an option for all though.

 

I can't comment on your use of PHP 7.1 with phpVMS 5.5.2 - I know that 5.5.2 won't work for me on PHP 7.2 (that was my main reason for updating 5.5.2 to 5.5.2.72 as my host forced us to PHP 7.2).

 

I have never heard of the info showing on the front page of the site and not being in the DB. Have you looked thru your DB tables to see if you can find the info? Obviously the data is getting to the site if a submittal email goes to you and the info is present on the front page. Wrong PIREP ID is strange too. What happens with a manual PIREP submittal? Maybe try a fresh install in a separate directory - keep it totally default and then tie it to your present DB to try to debug the issue. Any change this might have anything to do with your recently updated code share module or any others you may be using?

 

I can't comment on your use of PHP 7.1 with phpVMS 5.5.2 - I know that 5.5.2 won't work for me on PHP 7.2 (that was my main reason for updating 5.5.2 to 5.5.2.72 as my host forced us to PHP 7.2). You could also try installing 5.5.2.72 on a test site and then tie your existing DB (or a copy of it) to that test install. There are a few minor DB changes between 5.5.2 and 5.5.2.72 - but those have to do with date and datetime default parameters for MySQL 5.7 and shouldn't cause any issues. But, you may wish to explore those changes as they may apply to MariaDB 10.3 as well.... https://stackoverflow.com/questions/45537777/phpvms-incorrect-date-value-0000-00-00-for-column-lastlogin-at-row-1/

[Strider]

There is no data in the pages it shows. https://malaysiava.org/index.php/pireps/view/11450513

that number is a mystery to me as i have no idea where it has come from, the pirep id's that are in the pireps table dont go above 33k

[ProAvia]

Anything in your error_log file or in the console? What about the /admin error_log?

That PIREP ID number is a strange issue. Any other table that they might be in?

[Strider]

No, no table that has an id anywhere near that number. If you go into the page it doesn't show anything. I think this is a problem with my update to my codeshare module

[ProAvia]

Maybe pull the codeshare module out and try it that way. Does your codeshare module have any DATE or DATETIME fields?

 

I have no idea how it could send an email on a new submittal and show it on the front page without there being a DB entry.

[Strider]

That is what i am confused about. it is getting to most things but when it comes to insert the data into the db it fails. I asked my host could they roll back the version of mariadb, they said they cant. I do have date and time fields that caused some trouble in adding. but work now with adding. codeshares. But come to think of it, the changes i made to the schedules table i made on the 30th of june and i still got pireps on the 1st of July. So something happened between the 1st and 2nd. I am on shared, I wonder has another site caused trouble. I am not thinking of going with a VPS to have more control over what is one the server.

[ProAvia]

Yeah - that high record number is a bit odd. Might be beneficial to undo any changes you've made in the past few days and see if it resolves itself. Other than that, I am out of ideas. 

[Strider]

If i try to file a pirep manually i get a schedule doesnt exist error. 

[ProAvia]

Have you tried on a fresh development install using the same phpVMS and PHP version?

[Strider]

I installed it onto phpv 5.6 but i cant get into the admin db, says i dont have permission

[ProAvia]

What happens if you use the same PHP version?
Have you tried phpVMS 5.5.2.72 with PHP 7.1?

 

[Strider]

I am in the process of getting a new site done with icrew, i have set smartcars to icrew, which is at the moment on php v 5.6. It is not working from that either.

[Strider]

What is baffling me, is it is trigering the email saying there is a pirep waiting for approval. But it is failing to enter the detauils into the db. I have tried adding an entry in manually but it failed, so my guess is, there is something wrong with the pireps table. I have not touched that table. That table is the only one that seems to have a problem with data entry, all others work fine. I have tried moving databases but to no avail.

[ProAvia]

Have you by any chance tried using kACARS_Free as a test to see if it works?

[Strider]

This I think is coming from a problem i had with the schedules table a few days ago. It got corrupted, and i had to migrate to a new table as i couldn't fix that. I wonder could that have damaged the db so much that some code cant see it. As i have edited my codeshare module, so that it doesn't require the removal of a foreign key constraint.

[web541]

Have you tried optimizing your tables through the maintenance page? Not sure if it will help but it's worth a try. It's possible that the phpVMS foreign key constraints have been messed up due to the high IDs, if you are continuing to have issue then I would recommend setup a second site, have a fresh install/DB and migrate your data over. If importing it retains the high IDs then you may have to write a script that takes the old data dump and inserts them one at a time from the start.

It's definitely weird that things are working but the data is ending up in some sort of 'pseudo table' and not showing in the DB.

[Strider]

I have tried all that. I even tried optimising it from the table itself. I am going to be moving to a VPS to have more control over it. it seems the insert function for the pireps is not working the way it should do. I have replaced those files with ones from backups but that did not help.

[Strider]

I have moved to a VPS now, but still have this problem.

[ProAvia]

Can you check you PHP configuration and make sure "bcmath" is running and that "allow_url_open" is set to ON ?

 

Maybe install a phpinfo.php file and run it to see exactly the PHP configuration for the directory the phpVMS is installed in. 

[Strider]

those settings are set to on.

[Strider]

[07-Jul-2020 20:04:15 Europe/Dublin] PHP Warning:  mysqli::__construct(): (HY000/1045): Access denied for user 'malaysi1_icrew_user'@'localhost' (using password: YES) in /core/classes/ezdb/ezdb_mysqli.class.php on line 101
[07-Jul-2020 20:04:15 Europe/Dublin] PHP Fatal error:  Uncaught <blockquote><font face=arial size=2 color=000099><b>Last Error --</b> [<font color=000000><b>Access denied for user 'malaysi1_icrew_user'@'localhost' (using password: YES) (1045)</b></font>]<br />[<font color=000000><b></b></font>]</font><p>
					</blockquote><hr noshade color=dddddd size=1>
  thrown in /core/classes/ezdb/ezdb_mysqli.class.php on line 106

I get that error when i submit a manual pirep can someone shed some light on how to fix that as it is only the pirep form that is causing that error. as all other forms work without error, and submit the data.

[Strider]

I fixed the above problem, but i still can't file pireps. Can anyone give me code to log the SQL query to see what it being passed or if anything is being passed to the DB

[Strider]

I have resolved this problem. I had to change the pirepdata class to one from the V2 from nabeel's github, and change some columns to allow null values if none for those are submitted. Looks like something got set to strict or something not sure. But am happy this is now fixed.