Ik heb een backoffice programma in php met mysql geschreven. Dit programma heeft de afgelopen 7 jaar zonder enige problemen gedraaid op een webserver. Deze webserver is onlangs geüpdatet. Op dit moment werken 2 zwaardere scripts niet meer. Het gekke is dat ik lokaal WAMP heb draaien met de zelfde PHP versie en Mysql versie.
Lokaal werkt het zonder problemen en op de webserver hebben die 2 scripts problemen en krijgen die niet de data binnen die ze moeten krijgen uit Mysql.
Heeft iemand hier al eens zo een probleem gehad en wat zou hier een mogelijke oplossing kunnen zijn?
Het volgende is al aangepast alleen heeft geen resultaat opgeleverd.
max_execution_time van 30 naar 300 gezet
max_input_vars van 1000 naar 5000 gezet
max_input_time van 60 naar 300 gezet
De memory limit stond op 128M en die heb ik nu op 512 M gezet.
Is er aangegeven wat er exact is geupdate? Soms kan je aan de hand daarvan ook achterhalen waar het probleem mogelijk in zit.
Zelf kijk ik altijd naar de logs of die iets aangeven.
Verder, als dat mogelijk is, bouwde ik vroeger in mijn scripts momenten in dat het bepaalde informatie dumpt (ook bijvoorbeeld het tijdstip dat een deel van een script draait, wanneer het eindigt etc.). Die vergelijk ik dan met wat ik met wamp kreeg en daar kon ik dan vaak wel zien waar iets verschilde en ging er soms een lampje branden.
welke PHP versie was het eerst, en welke is het nu.
En ook voor MySQL.
En was is lokaal gelijk? PHP kan met en zonder de nodige extensies geïnstalleerd worden: wel of geen mysqli of PDO ondersteuning, wel of geen GD, wel of geen SOAP, etc.
En als het aan de PHP versie ligt (of extensie) dan zal daar een foutmelding uit voortkomen die in je log-files terug te vinden is.
PHP versie is van 5.6.40 naar 7.4.26 gegaan
en mysql naar 5.7.38 oude versie weet ik eerlijk gezegd niet.
Alleen het probleem zit in het feit dat ik lokaal dezelfde versies draai als op de webserver en het probleem zich alleen voordoet op de webserver en niet lokaal.
En wat voor fout treedt er op?
Een timeout, of een fatal error of "gewoon" en wit scherm.
In die laatste 2 gevallen zul je de error op moeten zoeken.
--
Ik heb hier nog ergens een applicatie die gebaseerd is op een heel oude versie van Mysql. Daar kon je join-query's in een willekeurige volgorde schrijven.
ipv: select from auto
join wielen
join banden
join ventieldopje
kon je die tabellen ook in willekeurige volgorde gooien, bijvoorbeeld from auto, join ventieldopje join wielen etc.
Dat geeft ook foutmeldingen.
Maar nogmaals: zonder foutmelding kun je oneindig veel scenario's bedenken.
"SELECT
oneplace_bb3.ritten.id,
oneplace_bb3.ritten.lid,
oneplace_bb3.ritten.van,
oneplace_bb3.ritten.naar,
oneplace_bb3.ritten.naam,
oneplace_bb3.ritten.starttijd,
oneplace_bb3.postcode.street,
oneplace_bb3.ritten.huisnummervan,
oneplace_bb3.ritten.toevoegingvan,
oneplace_bb3.postcode.postcode,
oneplace_bb3.postcode.city,
oneplace_bb3.ritten.naam1,
postcode1.street As street1,
oneplace_bb3.ritten.huisnummernaar,
oneplace_bb3.ritten.toevoegingnaar,
postcode1.postcode As postcode1,
postcode1.city As city1,
oneplace_bb3.ritten.postcodeidvan,
oneplace_bb3.ritten.postcodeidnaar
From
oneplace_bb3.ritten Inner Join
oneplace_bb3.postcode
On oneplace_bb3.ritten.postcodeidvan = oneplace_bb3.postcode.id Inner Join
oneplace_bb3.postcode postcode1
On oneplace_bb3.ritten.postcodeidnaar = postcode1.id
Where
oneplace_bb3.ritten.lid = ? And
oneplace_bb3.ritten.naam != ''AND
oneplace_bb3.ritten.starttijd > ?
Group By
oneplace_bb3.ritten.postcodeidvan
Order By
oneplace_bb3.ritten.naam";
Lokaal word deze uitgevoerd en krijg ik de data er van binnen, op de webserver krijg ik geen data binnen en er word ook geen foutmelding gegenereerd.
[size=xsmall]Toevoeging op 20/06/2022 15:39:05:[/size]
Het programma loopt gewoon wel alleen de html select word niet gevuld met keuze opties, er worden ook geen foutmeldingen gegenereerd (afgezien van de verwijzing naar lege opbjecten)
en als je die query uitvoert via iets als PHPMyAdmin?
Wat heeft die GROUP BY daar trouwens te zoeken? Ik zie geen aggregatie-functie (zoals MAX(), AVG() of COUNT()
[size=xsmall]Toevoeging op 20/06/2022 15:43:15:[/size]
oh en als Mysql de (terechte) setting "only full group by" aan heeft staan dan zou er zo maar een query-fout kunnen optreden door deze overbodige group=by
De group by is om te zorgen dat er niet 10 keer de zelfde keuze in de select komt te staan, is niet rekenkundig of zo, puur een stukje opschoning van de resultaten
[size=xsmall]Toevoeging op 20/06/2022 16:09:49:[/size]
only full group by, zou inderdaad het probleem kunnen verolorzaken. Via PHPMyAdmin de query gedraaid en geeft idd een foutmelding op de GROUP BY. Ik krijg straks een terugkoppeling van de hosting provider als hij dat heeft aangepast. Ik laat je weten of het dan idd werkt.
Je kunt natuurlijk de hosting provider vragen om je Mysql in standje kreupel te zetten, maar je kunt ook gewoon je query fatsoeneren.
Dus Group by eruit, en als je kennelijk een hoop dubbelen ophaalt, dan zou DISTINCT na het woordje SELECT soelaas bieden.
(al blijft de vraag of je niet op een andere manier die dubbelen had moeten voorkomen)
[size=xsmall]Toevoeging op 20/06/2022 16:54:37:[/size]
En die setting kun je ook bij het opbouwen van je verbinding naar Mysql meegeven. Staat volgens mij ook in dat genoemde group-by artikel (maar dan juist om hem áán te zetten)
Helaas is het een programma waar vrijwilligers mee werken en data/entry doen. DISTINCT na het woordje SELECT zou goed werken als de naam die er bij werd gezet door iedereen exact het zelfde zou zijn, anders krijg je nog steeds meerdere verwijzingen naar het zelfde adres. B.V. AH - ah - Alberthein - Albert Hein, en de mogelijke typ fouten.
Hoe lelijk deze oplossing misschien is, zo effectief is die ook.
En ik ben er van overtuigd dat er nog wel een aantal dingen in het programma zitten die niet wenselijk zijn, en dat gaat straks bij het modulair opbouwen van de applicatie ook allemaal opgeschoond worden, moet alleen eerst een goed team daar voor bij elkaar zoeken.
