probleem lokaal v.s. webserver
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.
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.
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.
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.
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.
Toevoeging op 20/06/2022 15:39:05:
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)
Wat heeft die GROUP BY daar trouwens te zoeken? Ik zie geen aggregatie-functie (zoals MAX(), AVG() of COUNT()
Toevoeging op 20/06/2022 15:43:15:
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
https://www.phphulp.nl/php/tutorial/databases/group-by/846/
Toevoeging op 20/06/2022 16:09:49:
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.
Voor zo ver super bedankt voor het mee denken!!
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)
Toevoeging op 20/06/2022 16:54:37:
En die setting kun je ook bij het opbouwen van je verbinding naar Mysql meegeven.
zie ook https://stackoverflow.com/questions/23921117/disable-only-full-group-by
Gewijzigd op 20/06/2022 16:56:46 door Ivo P
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.
Als het niet uitmaakt dat er op het ene scherm AH staat en op het volgende Albert Heijn, dan kun je dit toepassen.
Want je laat het nu aan je database welke naam hij ophaalt.
Natuurlijk is het ideaalste als je je data normaliseert en 1 naam-postcode-straatnaam combinatie hebt in een tabel en daar dan het ID gebruikt om naar te verwijzen.
Ik zie namelijk een potentieel probleem als je op de postcode matcht.
Zelf doe ik iets met onder andere bouwmarkten en ik weet dat het vaker zo is dat de "praxis" en de "gamma" of "karwei" vlak naast elkaar zitten op een meubelboulevard en dan dezelfde postcode kunnen hebben.
Toevoeging op 20/06/2022 22:26:53:
korte zoektocht levert op dat MAX() ook op niet numerieke waarden werkt:
Code (php)
1
2
3
4
5
6
7
8
2
3
4
5
6
7
8
SELECT
MIN(ritten.naam) AS naam,
andere,
kolommen
FROM ..
GROUP BY
andere,
kolommen
MIN(ritten.naam) AS naam,
andere,
kolommen
FROM ..
GROUP BY
andere,
kolommen
zou daarmee de alfabetisch eerste naam opleveren
En dit kun je ook doen met de andere namen in je query.
Als je de rest van de gewone kolommen maar in de group-by gooit.
KlantIndex (KIX). Je zou dus kunnen groeperen op die drie kolommen samen.
Na verloop van tijd krijg je op een adres altijd een andere naam, omdat mensen en bedrijven verhuizen. En ter ziele gaan. Als namen per adres variëren, is het daarom logischer om uit te gaan van de laatst toegevoegde data.
De drie-eenheid postcode + huisnummer + huisnummertoevoeging geeft in Nederland altijd een unieke index en een uniek adres. PostNL noemt dat zelfs de Na verloop van tijd krijg je op een adres altijd een andere naam, omdat mensen en bedrijven verhuizen. En ter ziele gaan. Als namen per adres variëren, is het daarom logischer om uit te gaan van de laatst toegevoegde data.
Dus dan sla je het beste bij een adres de naam samen met een datum op.
Alleen uitgaan van postcode+huisnummer om de naam te zoeken, kan ook weer een issue geven als zowel "Albert Heijn" als "postnl-agentschap" op dat adres gevestigd zijn.
Iedereen bedankt voor het mee denken het was inderdaad only full group by.