24. juli 2016 - 09:12Der er
5 kommentarer og 2 løsninger
Fejl i query
Hej Henter opgaver fra en tabel jeg viser med en while() Til hver opgave er der en eller flere som udfører opgaven. Har derfor lavet en tabel, jobref, med jobid og brugerid Brugerid findes i tabellen kontakter Nå jeg viser opogaver prøver jeg at finde den/dem som evt. er tilknyttet med flg. $sql = "Select navn FROM kontakter as t1 LEFT JOIN (jobref as t2) ON (t2.brugerid = t1.id AND t2.jobref = ".$id.")";
($id får jeg fra opgave tabellen)
Men det fejler: Commands out of sync; you can't run this command now
If you get Commands out of sync; you can't run this command now in your client code, you are calling client functions in the wrong order.
This can happen, for example, if you are using mysql_use_result() and try to execute a new query before you have called mysql_free_result(). It can also happen if you try to execute two queries that return data without calling mysql_use_result() or mysql_store_result() in between.
Jaaa, jeg havde brugt noget kode med $mysqli->prepare() hvilket var unødvendigt, da der ikke kommer input udefra. Har gang i $result = $mysqli->query($coming) og så virker det. Skal blot lige ha' styr på min query til at hente navne. ( Er bare for meget væk fra min computer, desværre. Savner "nørde-dagene" )
Det blev til $sql = "Select navn FROM kontakter as t1 LEFT JOIN jobref as t2 ON (t2.brugerid = t1.id) WHERE t2.jobid = ".$obj->id." ORDER BY t1.navn ASC";
jahh, arne, kan godt følge dig lidt, men jeg ved jo at det er et tal, $id, og jeg kan ikke blande queries da der ikke nødvendigvis er et navn tilknyttet en opgave.
Men noget mere forklaring om hvorfor du anbefaler prepare, vil jeg læse med stor interesse/glæde.
Brug af prepare og parameters har 3 fordele: - beskytter mod SQL injection (baade for tal og streng parametre) - beskytter mod naturligt special tegn a la O'Toole (kun relevant for streng parametre) - kan give bedre perforamance ved flere INSERT
Og der er ikke nogen ulemper af betydning.
Efter min bedste overbevisning er konsekvent brug af prepare of parameters i alle tilfaelde den eneste maade at beskytte mod SQL injection paa i det virkelige liv.
Det er ikke svaert at checke om der er reelt risiko for injection naar koden skrives som ny kode.
Men kode bruges normalt over mange aar og kode skal derfor vedligeholdes (nye funktioner tilfoejes og fejl rettes). Og saa kan en latent risiko for inkjection hurtigt blive til en reel risiko for injection. Den oprindelige programmoer checker at en variabel ikke kan paavirkes af bruger og vaelge at konkatanere. 2 aar senere skal en ny programmoer eller den samme programmoer som bare har glemt alt om den kode tilfoeje noget ny funktionalitet og som en del af den kan den variabel nu pludselig paavirkes af bruger. Og ingen taenkte paa at lave analysen mod SQL injection igen. Ups.
Lige præcis den med at der laves lode som bruges i noget tid, og derefter bliver opdateret ! Det overbeviste mig til fulde om logikken i konsekvent at bruge prepare !
Mange tak, arne !!!
Synes godt om
Ny brugerNybegynder
Din løsning...
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.
