Unknown column 't1.id' in 'where clause' Bij meerder tabellen in 1 query
Ik heb een probleem met MySQLi
Bij de volgende query krijg ik deze fout:
Unknown column 't1.id' in 'where clause'
Weet iemand hier een oplossing op?
De code: (Connectie heb ik weggelaten en andere queries werken gewoon goed)
Haal de ` (quootjes) weg in de MySQL string.
het id zal wel een integer zijn? dan moet je de '' om de 1 weg halen. Sloop de backtics er ook maar uit als je dan toch bezig bent. Die zijn niet nodig.
Mark Coenen op 11/08/2010 16:51:06:
het id zal wel een integer zijn? dan moet je de '' om de 1 weg halen. Sloop de backtics er ook maar uit als je dan toch bezig bent. Die zijn niet nodig.
Als het id wel bestaat maar van een ander datatype is (integer??) dan krijg je geen UNKNOWN Column foutmelding maar een melding dat de datatypes niet matchen.
Gewijzigd op 11/08/2010 16:55:22 door John D
Ik ben gewend om met de "`" te werken maar ik denk dat ik dat maar niet moet doen.
ps. En aangezien jij ze niet meer gebruikt voor dat soort tabelnamen, heb je ze in je gewone queries ook niet meer nodig :-)
Gewijzigd op 11/08/2010 17:07:04 door Joren de Wit
Ok, bedankt ik zal het onthouden :)
Ferry d op 17/09/2010 20:41:16:
Schat, alsjeblieft, please, lees nouw het topic eens door, voordat je post. En kijk eens hoe lang geleden dit al afgerond is...
Verder moet je Blanche's reactie nog eens goed doorlezen.
Ook is het gewoon beter om te selecteren wat je wilt hebben en niet * gebruiken.
Karl Karl op 17/09/2010 20:49:57:
[...]
Ook is het gewoon beter om te selecteren wat je wilt hebben en niet * gebruiken.
Ook is het gewoon beter om te selecteren wat je wilt hebben en niet * gebruiken.
"Ja! Maar ik wil ook alles hebben!"
Dan nog is het beter om los iedere kolom naam te specificeren :)
Karl Karl op 17/09/2010 20:49:57:
Ook is het gewoon beter om te selecteren wat je wilt hebben en niet * gebruiken.
Is dat wel zo? Volgens mij maakt het namelijk geen zak uit. Het enige dat je met die * meer doet is data ophalen (en geheugen heb je genoeg, behalve als je een heel brede tabel hebt met heel brede kolommen, maar dan ben je gewoon slecht bezig).
Ik definieer NOOIT kolomnamen (alleen als ik 1 kolom van 1 specifieke rij op wil halen).
Heb je een soort van reden of achterliggende gedachte om dat te zeggen? Documentatie? Benchmarks?
Toevoeging op 17/09/2010 23:42:30:
En over die backticks (dat is toch ook al 10 jaar een leuke discussie he!)...
Als je in MySQL een VIEW maakt, gooit ie m vol met backticks (doe maar es SHOW CREATE VIEW blaat;), dus in MySQL zal het wel zin hebben... Als je een geweldige database abstractielaag hebt, gooit die de backticks erin voor je als je MySQL gebruikt en niet als je niet MySQL gebruikt.
Rudie dirkx op 17/09/2010 23:40:07:
Is dat wel zo? Volgens mij maakt het namelijk geen zak uit. Het enige dat je met die * meer doet is data ophalen (en geheugen heb je genoeg, behalve als je een heel brede tabel hebt met heel brede kolommen, maar dan ben je gewoon slecht bezig).
Ik definieer NOOIT kolomnamen (alleen als ik 1 kolom van 1 specifieke rij op wil halen).
Heb je een soort van reden of achterliggende gedachte om dat te zeggen? Documentatie? Benchmarks?
Toevoeging op 17/09/2010 23:42:30:
En over die backticks (dat is toch ook al 10 jaar een leuke discussie he!)...
Als je in MySQL een VIEW maakt, gooit ie m vol met backticks (doe maar es SHOW CREATE VIEW blaat;), dus in MySQL zal het wel zin hebben... Als je een geweldige database abstractielaag hebt, gooit die de backticks erin voor je als je MySQL gebruikt en niet als je niet MySQL gebruikt.
Karl Karl op 17/09/2010 20:49:57:
Ook is het gewoon beter om te selecteren wat je wilt hebben en niet * gebruiken.
Is dat wel zo? Volgens mij maakt het namelijk geen zak uit. Het enige dat je met die * meer doet is data ophalen (en geheugen heb je genoeg, behalve als je een heel brede tabel hebt met heel brede kolommen, maar dan ben je gewoon slecht bezig).
Ik definieer NOOIT kolomnamen (alleen als ik 1 kolom van 1 specifieke rij op wil halen).
Heb je een soort van reden of achterliggende gedachte om dat te zeggen? Documentatie? Benchmarks?
Toevoeging op 17/09/2010 23:42:30:
En over die backticks (dat is toch ook al 10 jaar een leuke discussie he!)...
Als je in MySQL een VIEW maakt, gooit ie m vol met backticks (doe maar es SHOW CREATE VIEW blaat;), dus in MySQL zal het wel zin hebben... Als je een geweldige database abstractielaag hebt, gooit die de backticks erin voor je als je MySQL gebruikt en niet als je niet MySQL gebruikt.
Even totaal bezijdens het feit dat als je * vraagt, alle kolommen moeten worden opgezocht in plaats van alleen gecontroleerd dat ze bestaan...
Stel even voor de grap dat ik alle velden uit een bepaalde VIEW selecteer. Ik ga er gewoon van uit dat het allemaal prima werkt. Een collega van me past die VIEW aan, maar omdat ik simpelweg alle velden vraag hoor ik *niks* over dat het resultaat ineens anders is.
Nou, succes met voor al je "SELECT *"-queries tests schrijven om te controleren dat je de goede velden terugkrijgt.
Dit hele probleem heb je totaal niet als je de velden expliciet noemt, verder heb je dan natuurlijk altijd duidelijkheid over wat je selecteert, het *staat* er tenslotte duidelijk. Verder krijg je dan netjes een foutmelding op het moment dat een gek het model verandert.
Denk je nou echt dat al die briljante koppen dit soort dingen voor de lol roepen? Denk eens na, alsjeblieft? Misschien dat jij geen kritieke applicaties draait maar 99.9% van de mensen die ik ken die het wel doen gebruiken nooit *. Het enige waar het voor zorgt is een snelle rit naar verdommenis.
Quote:
Even totaal bezijdens het feit dat als je * vraagt, alle kolommen moeten worden opgezocht in plaats van alleen gecontroleerd dat ze bestaan...
Hmm... Controleren of ze bestaan klinkt als: "ze" opzoeken en dan controleren of ze bestaan. En dat klinkt als meer werk dan alleen maar "ze" opzoeken... Mis ik iets?
Quote:
Denk je nou echt dat al die briljante koppen dit soort dingen voor de lol roepen?
Daar vroeg ik dus naar... Welke briljante koppen? Het klinkt wel leuk, maar IS het ook zo? Wie zegt dat? Vind je het heel erg als ik je niet op je woord geloof? We kunnen namelijk wel een schreeuwwedstrijd houden, maar daar verandert niets door.
Zegt MySQL hetzelfde als jij? Ik heb het namelijk nooit kunnen vinden (het is wel al heel lang geleden dat ik ernaar gezocht heb).
Reageer nu even op de andere punten, dat is wat die briljante koppen roepen namelijk.
Klein beetje off topic ook wel he.
Laten we maar zeggen dat:
* backticks evil zijn en
* kolomnamen heerlijk.
Rudie dirkx op 18/09/2010 00:26:52:
Hmm... Controleren of ze bestaan klinkt als: "ze" opzoeken en dan controleren of ze bestaan. En dat klinkt als meer werk dan alleen maar "ze" opzoeken... Mis ik iets?
Quote:
Even totaal bezijdens het feit dat als je * vraagt, alle kolommen moeten worden opgezocht in plaats van alleen gecontroleerd dat ze bestaan...
Hmm... Controleren of ze bestaan klinkt als: "ze" opzoeken en dan controleren of ze bestaan. En dat klinkt als meer werk dan alleen maar "ze" opzoeken... Mis ik iets?
Het is al een soort van foutcontrole, je moet aangeven welke kolommen je wilt hebben, en die je dus ook verwacht te krijgen. In principe zou de database zo onvriendelijk mogen zijn dat het je maar één kolom terug geeft als je * gebruikt, terwijl je er meer gebruikt. * is namelijk een wildcard. Ook is SQL een self documenting language, door naar de query te kijken snap je dus al wat er gebeurd.
Verder is het eigenlijk altijd zo dat als je SQL op school hebt gebruikt, dat je geen * mag gebruiken. Door * te gebruiken snap je de vraag (query) wellicht niet precies, en geef je verkeerd antwoord op de vraag.
En bovendien, wat moet je met al die extra kolommen? Als je bijvoorbeeld 5 tabellen joint, en in die tabellen zitten weer 10 kolommen elk, dan krijg je ontiegelijk veel extra data die je helemaal niet nodig hebt.