Variable is leeg met mysqli_fetch_assoc

[moijamie]

Goede middag,

Ik heb een probleem met data stoppen in een variable.
Ik probeer data te stoppen uit een database in een variable op deze manier:

Mijn post:

HTML:

<form method="POST" enctype="multipart/form-data">

PHP:

<?php

                 $dbc = mysqli_connect("localhost","username", "wachtwoord", "database"); 

                $sql = "SELECT naam FROM tbl_winkels";

                $result = mysqli_query($dbc,$sql);
                if ($result != 0) {
                    
                    echo '<p><select name="winkel">';
                   
                    $num_results = mysqli_num_rows($result);
                    for ($i=0;$i<$num_results;$i++) {
                        $row = mysqli_fetch_array($result);
                        $name = $row['naam'];
                        echo '<option value="'.$name.'">'.$name.'</option>';
                    }
                   
                    echo '</select></p>';
                    
                }
                ?>

HTML:

<p><button type="submit" name="go" class='contactknop' style='width:80px;margin-top: 5px; margin-bottom: 5px;'>Maak aan!</button></p>

Mijn code:

PHP:

if(isset($_POST['go']))
        {
$dbc = mysqli_connect("localhost","username", "wachtwoord", "database") or 
                                 die('could not connect: '. mysqli_connect_error());
 $wdata = mysqli_fetch_assoc(mysqli_query($dbc,"SELECT * FROM tbl_winkels WHERE naam=".$_POST['winkel'].""));
        }

maar als ik var_dump($wdata); doet krijg ik NULL terug.
verder geen errors.

Iemand enig idee waarom?

[RobIII]

Je mist quotes om naam. M.a.w. je query moet worden: … WHERE naam='foo' i.p.v. … WHERE naam=foo.

Los daarvan: gebruik in vredesnaam prepared statements; je bent nu vatbaar voor SQL injection. En zet error_reporting op -1 of E_ALL ofzo; dan zie je errors waar ze optreden i.p.v. dat je je loopt af te vragen wat er mis is.

[ Voor 130% gewijzigd door RobIII op 18-09-2014 14:03 ]

[moijamie]

RobIII schreef op donderdag 18 september 2014 @ 13:35:
Je mist quotes om naam. M.a.w. je query moet worden: … WHERE naam='foo' i.p.v. … WHERE naam=foo.

Los daarvan: gebruik in vredesnaam Parametrized Queries; je bent nu vatbaar voor SQL injection. En zet error_reporting op -1 of E_ALL ofzo; dan zie je errors waar ze optreden i.p.v. dat je je loopt af te vragen wat er mis is.

Bedankt! het werkt nu.
Ik ga wel even proberen het nu te doen met Parametrized Queries en error_reporting(E_ALL); aangezet bedankt voor de tip

[RobIII]

Sowieso is dit geen handige constructie:

PHP:

$wdata = mysqli_fetch_assoc(mysqli_query(...

mysqli_query kan fout gaan (lees: returned false) en dan voer je dus false aan mysqli_fetch_assoc. Je kunt beter zoiets doen:

PHP:

$qryresult = mysqli_query($dbc,"SELECT * FROM ...");
if (!$qryresult) {
    die(mysqli_error($dbc));
} else {
    $wdata = mysqli_fetch_assoc($qryresult);
}

(Beter nog gooi je gewoon een exception maar da's een ander verhaal...)

[ Voor 16% gewijzigd door RobIII op 18-09-2014 13:50 ]

[moijamie]

RobIII schreef op donderdag 18 september 2014 @ 13:47:
Sowieso is dit geen handige constructie:

PHP:

$wdata = mysqli_fetch_assoc(mysqli_query(...

mysqli_query kan fout gaan (lees: returned false) en dan voer je dus false aan mysqli_fetch_assoc. Je kunt beter zoiets doen:

PHP:

$qryresult = mysqli_query($dbc,"SELECT * FROM ...");
if (!$qryresult) {
    die(mysqli_error($dbc));
} else {
    $wdata = mysqli_fetch_assoc($qryresult);
}

(Beter nog gooi je gewoon een exception maar da's een ander verhaal...)

Ik heb het aangepast maar geen parametarized querys gebruikt maar mysqli_real_escape_string() (Is dat ook veilig?)

PHP:

          $postwinkel = mysqli_real_escape_string($dbc, htmlentities($_POST['winkel']));
          
          $qryresult = mysqli_query($dbc,"SELECT * FROM tbl_winkels WHERE naam="."'".$postwinkel."'"."");
          if (!$qryresult) {
              die(mysqli_error($dbc));
          } else {
              $wdata = mysqli_fetch_assoc($qryresult);
          }

[NMe]

Dat is ook veilig indien goed gebruikt (en dat doe je zo te zien in dit geval wel). Parameterized query's hebben echter wel nog steeds de voorkeur omdat ze makkelijker zijn in het gebruik en je bijna niet per ongeluk toch nog kan vergeten om spul te escapen.

Overigens is die htmlentities voordat het de database in gaat niet erg gebruikelijk. De database is voor opslag, niet voor presentatie, tenzij je een goede reden hebt om het vooraf vast te converteren. Ik vermoed niet dat dat hier het geval is. Meestal wil je pas bij het tonen van je gegevens functies als htmlentities gebruiken.

[ Voor 17% gewijzigd door NMe op 18-09-2014 14:10 ]

[moijamie]

NMe schreef op donderdag 18 september 2014 @ 14:09:
Dat is ook veilig indien goed gebruikt (en dat doe je zo te zien in dit geval wel). Parameterized query's hebben echter wel nog steeds de voorkeur omdat ze makkelijker zijn in het gebruik en je bijna niet per ongeluk toch nog kan vergeten om spul te escapen.

Overigens is die htmlentities voordat het de database in gaat niet erg gebruikelijk. De database is voor opslag, niet voor presentatie, tenzij je een goede reden hebt om het vooraf vast te converteren. Ik vermoed niet dat dat hier het geval is. Meestal wil je pas bij het tonen van je gegevens functies als htmlentities gebruiken.

Okay. dus ik kan htmlentities gewoon weglaten?
Zal in me volgende project parametarized querys gebruiken maar aangezien ik nu al stuk of 50 paginas op deze manier heb gedaan kan ik sneller alles escapen denk ik.

[RobIII]

moijamie schreef op donderdag 18 september 2014 @ 14:16:
[...]


Okay. dus ik kan htmlentities gewoon weglaten?
Zal in me volgende project parametarized querys gebruiken maar aangezien ik nu al stuk of 50 paginas op deze manier heb gedaan kan ik sneller alles escapen denk ik.

Als je 50 "pagina's" (ik neem aan dat je doelt op "php bestanden") op een dergelijke manier hebt gedaan heb je een heel ander probleem: waarom heb je in hemelsnaam 50x dergelijke constructies lopen copy/pasten i.p.v. daar een functie (of beter: ORM of DAL o.i.d.) voor te gebruiken?

Verder: NMe zegt 't heel voorzichtig maar die htmlentities daar is totáál onzinnig Heb je V&D in de database staan bij 'winkelnaam' of V&D?

[ Voor 37% gewijzigd door RobIII op 18-09-2014 14:24 ]

[moijamie]

RobIII schreef op donderdag 18 september 2014 @ 14:19:
[...]

Als je 50 "pagina's" (ik neem aan dat je doelt op "php bestanden") op een dergelijke manier hebt gedaan heb je een heel ander probleem: waarom heb je in hemelsnaam 50x dergelijke constructies lopen copy/pasten i.p.v. daar een functie (of beter: ORM of DAL o.i.d.) voor te gebruiken?

Verder: NMe zegt 't heel voorzichtig maar die htmlentities daar is totáál onzinnig Heb je V&D in de database staan bij 'winkelnaam' of V&D?

De database is tot noch toe leeg en word niet gevuld door mij.
maar als een winkel aangemaakt word door een admin straks gaat hij het in vullen als V&D en word het dus als V&D in de database opgeslagen(neem ik aan).

[TheRookie]

Probeer het eens, wellicht kom je voor een verrassing te staan