PHPmyadmin geeft andere resultaten als PHP
Code (php)
1
2
3
4
5
6
2
3
4
5
6
$pro = mysqli_query($DBD->conn(),"SELECT p.ean as ean,pt.ean, pt.category, pt.bestaat FROM prijzen p , producten_temp pt WHERE pt.bestaat != 'ja' AND pt.ean = p.ean AND CHAR_LENGTH(p.ean) = 13 group by p.ean");
while ($rtt = mysqli_fetch_array($pro))
{
$rt = mysqli_query($DBD->conn(),"insert into geen_img (category, ean ) VALUES ('".$rtt['category']."','".$rtt['ean']."')") or die (mysqli_error($DBD->conn()));
}
while ($rtt = mysqli_fetch_array($pro))
{
$rt = mysqli_query($DBD->conn(),"insert into geen_img (category, ean ) VALUES ('".$rtt['category']."','".$rtt['ean']."')") or die (mysqli_error($DBD->conn()));
}
Het punt is dat ik via PHP geen 13 cijferige ean codes terug krijg en hij grouped ze ook niet, steeds dezelfde ean codes ook. Ook geen foutmeldingen.
In phpmyadmin krijg ik de juiste resultaat.
Hoe nu verder om dit te debuggen ?
Doublecheck dat even.
Waarom een 'ja' en geen integer ( 0 of 1).
Veel handiger!
Gewijzigd op 10/06/2019 09:10:01 door - Ariën -
Quote:
Waarom een 'ja' en geen integer ( 0 of 1).
Is waar.
Ja zeker weten op dezelfde server. Nog nooit eerder meegemaakt.
Quote:
Het punt is dat ik via PHP geen 13 cijferige ean codes terug krijg en hij grouped ze ook niet, steeds dezelfde ean codes ook.
Sja, dat zou al een indicatie moeten zijn van wat er misgaat natuurlijk.
Kijk eens goed wat je opvraagt:
Code (php)
1
SELECT p.ean as ean,pt.ean, ...
Je vraagt daar twee keer een EAN kolom op. Denk niet dat in MySQLi results onderscheid wordt gemaakt tussen kolommen met dezelfde naam maar een andere prefix. Waarschijnlijk wordt dus de eerste EAN kolom overschreven door de tweede. Probeer ze anders eens verschillende namen te geven?
(en als het tweede geen EAN is (geen x-karakters-tellende-code) waarom noem je het dan zo?)
En ja, alles in een transactie zetten zou niet misstaan. Je wilt namelijk dat deze hele batch in zijn geheel wordt doorgevoerd, of geheel niet. Maar niet half of wat dan ook.
Gewijzigd op 10/06/2019 12:39:44 door Thomas van den Heuvel
Daniel van Seggelen op 11/06/2019 12:01:18:
Klopt maar het punt was een index van een category kolom wat in de weg zat
Die volg ik niet helemaal? Is het probleem nu opgelost?
Overigens, als je dingen moet doen als het controleren van lengtes en het controleren van een tekstuele waarde die eigenlijk een ja/nee veld is (waarom dan niet opslaan als TINYINT 1/0?eventueel met index als je hier op wilt kunnen zoeken) dan klinkt het alsof de formattering van de tabelkolommen en de opslag van de data niet echt fantastisch is.
Voordat data de database ingaat zou deze gevalideerd moeten worden zodat je vervolgens de garantie hebt dat je ook echt met gestructureerde data bezig bent.
Een database is geen afvalcontainer waar je maar alles inkiepert, en als je dan iets nodig hebt dat je hier dan een keer doorheen wroet. En hier ligt dan misschien ook direct de oorzaak van de opschoningsactie waar je nu mee bezig lijkt te zijn?
Mogelijk is het ook handiger om in plaats van AND pt.ean = p.ean een fatsoenlijke JOIN op te stellen om de tabellen aan elkaar te knopen. Hierin kun je tevens tot uiting laten komen hoe de data in de tabellen zich tot elkaar verhoudt, dat is dan meteen een stukje impliciete documentatie.
Op dit moment is het onduidelijk hoe vaak een record met dezelfde EAN-code voorkomt in welke tabel. Om te kunnen (helpen) doorgronden waarom een query "niet werkt" is het vaak ook handig om te weten hoe het gedrag van de data luidt.
Gewijzigd op 11/06/2019 13:16:35 door Thomas van den Heuvel