[PHP/MySQL] Query werkt niet in PHP, wel in phpMyAdmin

[dwilmer]

Hallo tweakers,

Ik heb het volgende stukje code:

PHP:

$query = 'SELECT * FROM users WHERE REPLACE(url, \'-\', \'\') = \''.$parsedPage.'\';';
$result = mysql_query($query) or die(mysql_error());

var_dump(mysql_num_rows($result));
die();

In de users-tabel staat bijvoorbeeld het volgende record:
voornaam: Pietje
achternaam: Precies
url:pietje-precies

Als ik de url parse komt daar 'pietjeprecies' uit (dat komt ook in $parsedPage).

Als deze query door php wordt uitgevoerd, komen er geen rijen uit (de vardump geeft int(0) terug).

Als ik vervolgens de query echo voordat ik hem laat doodgaan en die copy-paste naar phpmyadmin, geeft-ie wel resultaat terug. Hoe kan dat? Of beter: hoe krijg ik het ook in php aan de praat?

Het zal waarschijnlijk een of ander klein dingetje zijn, maar ik zie het niet.

Help!!!

[jhu]

Ik zou beginnen met je query gewoon tussen dubbele quotes te zetten, dan hoef je die enkele niet te escapen met \.

Daar zal het zeker weten wel in zitten.

Dus:

$query ="SELECT * FROM users WHERE REPLACE(url, '-', '') = '$parsedPage'";

[ Voor 21% gewijzigd door jhu op 17-12-2009 12:27 ]

[Pin0]

En waarom laat je mysql de replace doen en doe je dat niet voor de query met php?
imo. is het nooit slim om mysql logica te laten uitvoeren...

[dwilmer]

@jhu
Dat had ik ook eerst (dacht dat het daaraan lag). Maar dit doet het dus ook niet:

PHP:

$query = "SELECT * FROM users WHERE REPLACE(url, '-', '') = '$parsedPage';";
$result = mysql_query($query) or die(mysql_error());

var_dump(mysql_num_rows($result));
die();

@Pin0
Hoe wou je dan 'pietjeprecies' in de variabele vergelijken met 'pietje-precies' in de database?

En daarnaast: dat verklaart niet waarom hij het wel doet in phpMyAdmin.

[ Voor 24% gewijzigd door dwilmer op 17-12-2009 12:35 ]

[jhu]

Pin0 schreef op donderdag 17 december 2009 @ 12:29:
En waarom laat je mysql de replace doen en doe je dat niet voor de query met php?
imo. is het nooit slim om mysql logica te laten uitvoeren...

Nee, normaal inderdaad niet, maar als je in de database als waarde van de 'url' kolom dingen hebt staan met '-' tekens op onverwachte plekken die je niet in PHP hebt, dan moet je het wel zo doen.

[jhu]

dwilmer schreef op donderdag 17 december 2009 @ 12:31:
Dat had ik ook eerst (dacht dat het daaraan lag). Maar dit doet het dus ook niet:

PHP:

$query = "SELECT * FROM users WHERE REPLACE(url, '-', '') = '$parsedPage';";
$result = mysql_query($query) or die(mysql_error());

var_dump(mysql_num_rows($result));
die();

Volgens mij moet je die ; binnen de query ook niet plaatsen?

[CodeCaster]

Sloop de puntkomma er eens uit, volgens mij mag dat niet.

[dwilmer]

Ook zonder puntkomma hetzelfde resultaat.

[CodeCaster]

Als exact dezelfde query in PHP niet werkt, maar in PHPMyAdmin wel is er met de query niets mis, behalve wanneer PHPMyAdmin iets aan de query verandert.

Ben je wel verbonden met dezelfde database, als dezelfde gebruiker?

[dwilmer]

Ik ben inderdaad verbonden met de goede database. Sterker nog: bij sommige andere records wordt-ie wel gevonden.

[CH4OS]

Wat is de exacte error die MySQL geeft en hoe was de query die PHP afvuurde op MySQL (echo de query dus even)?

PHP:

$query = "SELECT * FROM users WHERE REPLACE(url, '-', '') = '". $parsedPage ."';";

Probeer dit eens. Dan weet je zeker namelijk dat je je variabele escaped.

[ Voor 51% gewijzigd door CH4OS op 17-12-2009 12:50 ]

[jbdeiman]

Volgens mij mag dat wel en geef je daarmee gewoon het einde van de query aan.
Variabelen zou ik dan wel weer buiten quotes halen, dat is wel zo netjes.

Wat is eigenlijk de bedoeling van je heel opzet van die tabel?

En daarbij, als je de URL parsed? Wat bedoel je daarmee, vul je zelf de url in zonder streepje of wat?

[cariolive23]

CodeCaster schreef op donderdag 17 december 2009 @ 12:40:
Als exact dezelfde query in PHP niet werkt, maar in PHPMyAdmin wel is er met de query niets mis, behalve wanneer PHPMyAdmin iets aan de query verandert.

Hoezo een openstaande deur intrappen? PMA vern**kt herschrijft de query van a tot z, je weet dus helemaal niets wanneer een query is uitgevoerd. Is dat jouw query of het resultaat van een query na het herschrijven? Gebruik gewoon de tools de MySQL zelf meelevert, die herschrijven de zooi niet. Wanneer je queries dan goed zijn, kun je ze eventueel ook in PMA uitvoeren, je weet dat ze dan goed zijn.

[dwilmer]

MySQL geeft geen error, hij geeft gewoon geen rij terug die wel in de database staat.

Maar ik heb waarschijnlijk de oorzaak gevonden: ik heb de tabel vanochtend met een importer getruncate en opnieuw gevuld, waarschijnlijk staat de oude versie tabel nog ergens in de cache.

Als bijvoorbeeld 'kop-van-jut' wel in de oude versie staat, maar 'pietje-precies' er is bijgekomen, doet 'kop-van-jut' het wel maar 'pietje-precies' nog niet.

Waarom phpmyadmin wel de goede versie pakt en php niet, dat weet ik niet.

EDIT:
@jbdeiman: in de URL kunnen op willekeurige plekken streepjes, spaties en hoofdletters voorkomen. Om de urls in de database leesbaar te houden (ze kunnen ook worden ge-emaild) worden er streepjes tussen gezet.

Maar het probleem ligt niet bij de replace, zie hierboven.

EDIT 2:
Hoe kan ik nu de cache, waar de oude versie nog in staat, omzeilen of vullen met de nieuwe versie van de tabel?

Iedereen in ieder geval bedankt voor de snelle respons.

[ Voor 31% gewijzigd door dwilmer op 17-12-2009 13:01 ]

[Voutloos]

De diverse caches in mysql kunnen een dergelijke fout niet veroorzaken, dus het ligt toch echt aan je debug kunsten. Bekijk nou eens de letterlijk uitgevoerde query, bekijk de tabel inhoud, doe eens een keer SELECT REPLACE(wa,wa,wiewa) om te zien of dat doet wat jij verwacht etc. etc.

[NMe]

GJtje schreef op donderdag 17 december 2009 @ 12:44:
Wat is de exacte error die MySQL geeft en hoe was de query die PHP afvuurde op MySQL (echo de query dus even)?

PHP:

$query = "SELECT * FROM users WHERE REPLACE(url, '-', '') = '". $parsedPage ."';";

Probeer dit eens. Dan weet je zeker namelijk dat je je variabele escaped.

Zou je mij misschien eens uit kunnen leggen hoe dat beter escaped is dan dit?

PHP:

$query = "SELECT * FROM users WHERE REPLACE(url, '-', '') = '$parsedPage';";

[MueR]

Met NMe.
Not to mention de dikke error die je gaat krijgen door de query separator :x

[BCC]

Ja, en je query is waarschijnlijk nogal vatbaar voor SQLinjectie op deze manier.

[ Voor 12% gewijzigd door BCC op 17-12-2009 13:37 ]

[Woy]

Sowieso lijkt het me handig om de query die je met PHP probeert uit te voeren gewoon eens te printen, en te kijken wat exact het resultaat is.

Dus gewoon

PHP:

echo $query;

en dan kijken of het echt wel exact hetzelfde is als de query die je in phpMyAdmin uitvoert.

[dwilmer]

Met als URL 'Pietje Precies' komt dit eruit (met echo $query):

SELECT * FROM users WHERE REPLACE(url, '-', '') = 'pietjeprecies'

Het maffe is: records die voor de import ook al bestonden, gaan wel goed, maar velden die bij de import zijn toegevoegd doen het niet.

@BCC:
$parsedPage wordt niet rechtstreeks van de URL geplukt, maar wordt eerst ge-escaped uiteraard.

EDIT: De import bestaat uit een truncate, gevolgd door een stuk of 150 insert-statements.

[ Voor 11% gewijzigd door dwilmer op 17-12-2009 14:24 . Reden: Wat informatie ter verduidelijking ]

[NMe]

dwilmer schreef op donderdag 17 december 2009 @ 14:23:
Het maffe is: records die voor de import ook al bestonden, gaan wel goed, maar velden die bij de import zijn toegevoegd doen het niet.

10 tegen 1 dat er een newline achteraan je string staat waar je mank op gaat. Doe eens dit:

SQL:

SELECT * FROM users WHERE url <> TRIM(url)

[dwilmer]

Geeft een lege set terug in zowel php als phpmyadmin

[NMe]

Deze dan?

SQL:

SELECT * FROM users WHERE url LIKE CONCAT('%', CHAR(10))

[jbdeiman]

@dwilmer
Weet je zeker dat je niet een nieuwe table hebt aangemaakt die wordt gebruikt in je code, of dat je wel de goede database hebt geselecteerd. Ik werk hier met databases van meer dan 200 tabellen, en als daar wat in veranderd (wat dan ook!) wordt het altijd meteen opgepakt.

[dwilmer]

Laat maar, ik heb het al gevonden: het is toch een andere database. Ik had hem eerst op een bepaalde database gezet, toen is vervolgens een van de scripts (die het ophaalt) op een andere database gezet, zonder dat ik het wist.

Kortom: CodeCaster had toch het goede antwoord.

Bedankt allemaal voor jullie respons, en om Homer J. Simpson te citeren: 'D'OH!'

[CodeCaster]

cariolive23 schreef op donderdag 17 december 2009 @ 12:48:
[...]

Hoezo een openstaande deur intrappen? PMA vern**kt herschrijft de query van a tot z, je weet dus helemaal niets wanneer een query is uitgevoerd. Is dat jouw query of het resultaat van een query na het herschrijven? Gebruik gewoon de tools de MySQL zelf meelevert, die herschrijven de zooi niet. Wanneer je queries dan goed zijn, kun je ze eventueel ook in PMA uitvoeren, je weet dat ze dan goed zijn.

Ik heb speciaal voor deze opmerking even de phpMyAdmin-source gedownload en het pad gevolgd dat de POST naar het querywindow afloopt tot deze bij mysql_query($query, $link); uitkomt. Long story short: you're wrong.

Het enige dat aan de query wordt veranderd in import/sql.php is dat alle commentaar uit de query wordt gesloopt. Behalve dat wordt de query zelf door een tiental functies heen en weer gepassed, maar wordt niet meer veranderd.

@dwilmer: LOL.

[NMe]

CodeCaster schreef op donderdag 17 december 2009 @ 14:44:
[...]

Ik heb speciaal voor deze opmerking even de phpMyAdmin-source gedownload en het pad gevolgd dat de POST naar het querywindow afloopt tot deze bij mysql_query($query, $link); uitkomt. Long story short: you're wrong.

Het enige dat aan de query wordt veranderd in import/sql.php is dat alle commentaar uit de query wordt gesloopt. Behalve dat wordt de query zelf door een tiental functies heen en weer gepassed, maar wordt niet meer veranderd.

..behalve dan het toevoegen van wat whitespace voor de weergave, maar dat boeit niet.

[CodeCaster]

NMe schreef op donderdag 17 december 2009 @ 14:48:
[...]

..behalve dan het toevoegen van wat whitespace voor de weergave, maar dat boeit niet.

De functie PMA_importRunQuery($sql...) wordt eerst aangeroepen, deze importeert de van commentaar gestripte SQL. Pas daarna worden PMA_SQP_parse($sql_query) en PMA_SQP_analyze($parsed_sql) aangeroepen, en die laten de variabele die de originele SQL bevat met rust.

[CH4OS]

NMe schreef op donderdag 17 december 2009 @ 13:33:
Zou je mij misschien eens uit kunnen leggen hoe dat beter escaped is dan dit?

PHP:

$query = "SELECT * FROM users WHERE REPLACE(url, '-', '') = '$parsedPage';";

Ik weet dat je als je string begint met ", je dan gewoon de variabelen '$var' kan zetten. Voor de zekerheid doe ik dat altijd schrijven als '". $var ."', omdat ik had begrepen dat dat het 'mooiste' escapen is, welke altijd correct werkt. Vandaar.

[jip_86]

Double quotes icm je variabelen direct in de string is minder efficiënt zeker met meer variabelen. PHP trekt dan namelijk zelf je hele string nog uit elkaar om te controleren. Ik heb laatst een vergelijking gelezen waarbij de tijd vergeleken werd.

[CodeCaster]

Inderdaad, bij een miljoen stringbewerkingen scheelt het al snel een honderdste seconde!

[Woy]

jip_86 schreef op donderdag 17 december 2009 @ 19:21:
Double quotes icm je variabelen direct in de string is minder efficiënt zeker met meer variabelen. PHP trekt dan namelijk zelf je hele string nog uit elkaar om te controleren. Ik heb laatst een vergelijking gelezen waarbij de tijd vergeleken werd.

Echter zal je daar nooit wat van merken zolang je niet duizenden strings aan het bewerken bent. Het is dus wat dat betreft ook geen goed argument om de een of de andere manier te gebruiken

[NMe]

GJtje schreef op donderdag 17 december 2009 @ 17:55:
[...]
Ik weet dat je als je string begint met ", je dan gewoon de variabelen '$var' kan zetten. Voor de zekerheid doe ik dat altijd schrijven als '". $var ."', omdat ik had begrepen dat dat het 'mooiste' escapen is, welke altijd correct werkt. Vandaar.

Misschien kun je dan beter eerst even opzoeken wat escapen is want dat doet jouw voorbeeld net zo min als de code die je quotet.

jip_86 schreef op donderdag 17 december 2009 @ 19:21:
Double quotes icm je variabelen direct in de string is minder efficiënt zeker met meer variabelen. PHP trekt dan namelijk zelf je hele string nog uit elkaar om te controleren. Ik heb laatst een vergelijking gelezen waarbij de tijd vergeleken werd.

Ehm... Als je script zoooo traag draait dat je winst moet halen uit dit soort micro-optimalisaties die je letterlijk een paar microseconden per operatie besparen dan durf ik te beweren dat je een veel groter probleem hebt.

[Gomez12]

jip_86 schreef op donderdag 17 december 2009 @ 19:21:
Double quotes icm je variabelen direct in de string is minder efficiënt zeker met meer variabelen. PHP trekt dan namelijk zelf je hele string nog uit elkaar om te controleren. Ik heb laatst een vergelijking gelezen waarbij de tijd vergeleken werd.

Yep en code-uitlijning is ook inefficient, new-lines gebruiken in je code is ook inefficient, variabele namen langer dan 1 char zijn ook inefficient, commentaar is ook inefficient.

Het valt allemaal enkel te detecteren als je je code 1 biljoen keer oid gaat draaien op een commodore 64.
Praktisch totaal niet boeiend en alleen maar irritant allemaal, maar theoretisch is het misschien inefficient.

[CH4OS]

NMe schreef op donderdag 17 december 2009 @ 19:42:
Misschien kun je dan beter eerst even opzoeken wat escapen is want dat doet jouw voorbeeld net zo min als de code die je quotet.

Hoe heet dat dan wat ik bedoel? Met '". $var ."' en zo. Escapen is het voorkomen dat PHP strings te vroeg afbreekt, dan is het inderdaad iets anders als wat ik bedoel.

[NMe]

GJtje schreef op vrijdag 18 december 2009 @ 12:26:
[...]
Hoe heet dat dan wat ik bedoel? Met '". $var ."' en zo. Escapen is het voorkomen dat PHP strings te vroeg afbreekt, dan is het inderdaad iets anders als wat ik bedoel.

Da's wel een heel vage uitleg van wat escapen is. En wat jij bedoelt het concatenation. Of je dat nou wel of niet doet zou niet uit mogen maken, mits je een goeie editor gebruikt.

[.oisyn]

CodeCaster schreef op donderdag 17 december 2009 @ 19:33:
Inderdaad, bij een miljoen stringbewerkingen scheelt het al snel een honderdste seconde!

Nou het is wel iets erger, ik kom op een verschil van 3 seconden op totaal 4 seconden, oftewel een factor 4, bij 1 variabele in een string. Daarbij maakt het niet uit of je bij de concat-versie enkele of dubbele quotes gebruikt. Neemt niet weg dat het een micro-optimalisatie blijft. Gelukkig zijn variabelen buiten strings sowieso leesbaarder, dus het is een win-win situatie om ze wel gewoon buiten je strings te trekken

[ Voor 20% gewijzigd door .oisyn op 18-12-2009 12:43 ]

[NMe]

.oisyn schreef op vrijdag 18 december 2009 @ 12:41:
[...]

Nou het is wel iets erger, ik kom op een verschil van 3 seconden op totaal 4 seconden, oftewel een factor 4, bij 1 variabele in een string. Daarbij maakt het niet uit of je bij de concat-versie enkele of dubbele quotes gebruikt. Neemt niet weg dat het een micro-optimalisatie blijft. Gelukkig zijn variabelen buiten strings sowieso leesbaarder, dus het is een win-win situatie om ze wel gewoon buiten je strings te trekken

Hangt van je editor af. Mijn editor kleurt variabelen in strings prima als variabelen en maakt ze dus net zo leesbaar als de concatenated versie.

[jbdeiman]

@NMe
Klopt dat sommige editors dat doen, maar niet iedereen heeft daar beschikking over. Daarbij moet je voor het gebruiken van variabelen in een string de dubbele quotes gebruiken en deze worden minder snel verwerkt, omdat dat wel door de parser wordt gehaald.
Als je single quotes gebruikt, dan zit je met Heel andere regeltjes en kan je de variabelen er niet zomaar in knallen. Wel wordt de string dan niet door de parser gehaald, maar gewoon letterlijk zo teruggegeven. Of gebruik jij alleen de single qoutes wanneer je de naam van de variabele (dus letterlijk $dollar) wilt terug geven?

[NMe]

jbdeiman schreef op vrijdag 18 december 2009 @ 12:51:
@NMe
Klopt dat sommige editors dat doen, maar niet iedereen heeft daar beschikking over. Daarbij moet je voor het gebruiken van variabelen in een string de dubbele quotes gebruiken en deze worden minder snel verwerkt, omdat dat wel door de parser wordt gehaald.

Doe eens een paar berichten hierboven lezen. Dat verschil is zó marginaal dat je er niet moeilijk over moet doen voor de gemiddelde website. Oh, en het niet tot je beschikking hebben van een goeie editor is niet mijn probleem natuurlijk. Ik schrijf mijn code op een manier die voor mij en mijn directe collega's leesbaar is, iemand anders die er problemen mee heeft leert er maar mee leven.

Als je single quotes gebruikt, dan zit je met Heel andere regeltjes en kan je de variabelen er niet zomaar in knallen. Wel wordt de string dan niet door de parser gehaald, maar gewoon letterlijk zo teruggegeven. Of gebruik jij alleen de single qoutes wanneer je de naam van de variabele (dus letterlijk $dollar) wilt terug geven?

Nee, ik gebruik altijd single quotes tenzij ik met een query zit te werken. Of tenzij ik veel moet concatenaten. Of wanneer ik een control character à la \n wil opnemen in mijn string.

[.oisyn]

jbdeiman schreef op vrijdag 18 december 2009 @ 12:51:
Daarbij moet je voor het gebruiken van variabelen in een string de dubbele quotes gebruiken en deze worden minder snel verwerkt, omdat dat wel door de parser wordt gehaald.

En dát is dus onzin. Enkele quotes moeten ook geparsed worden op escale sequences. Dat er minder van zijn (alleen een \ en geen $) doet er niet zoveel toe. Mijn test liet dat ook zien. Wat dat betreft vind ik het wel frappant dat een variabele in een string meer kost dan een variabele buiten een string. In beide gevallen moet tekst geparsed worden en moeten en strings geconcateneerd worden. Dat er een verschil is is voornamelijk een quirck van PHP, niet iets dat inherent aan de syntax is.

NMe schreef op vrijdag 18 december 2009 @ 12:59:
Oh, en het niet tot je beschikking hebben van een goeie editor is niet mijn probleem natuurlijk.

Te kort door de bocht. Een editor die variabelen in strings niet goed weergeeft is niet meteen geen goede editor. Ik gebruik zelf doorgaans vs.php, een PHP plugin voor Visual Studio. Werkt perfect, het enige wat ie niet goed kan is variabelen in strings goed duidelijk weergeven.

[ Voor 50% gewijzigd door .oisyn op 18-12-2009 13:07 ]