Hoe krijg ik de foutmelding over de array_sum weg?

[FabiandJ]

Ik heb een stuk code waar ik de volgende foutmelding op krijg, namelijk "Warning: array_sum() expects parameter 1 to be array, null given". Dit gaat over regel 20 in de code hieronder.

code:

$totalcars=3;
$select = "SELECT DISTINCT autoid FROM coureur WHERE leagueid=".$leagueid.""; 
$res = mysql_query($select) or die(mysql_error()); 
while($row = mysql_fetch_assoc($res))
{
    $e=0;
    while ($e < $count)                                 
    {
        $j=0;
        $selectpunt="SELECT q_punten AS qpunten, r_punten AS rpunten, r_snelstepunt AS snelstepunten, r_bonuspunt AS bonuspunten, r_puntaftrek AS strafpunten FROM uitslagen WHERE autoid=".$row['autoid']." AND raceid=".$raceidpuntenc[$e]."";
        $respunt = mysql_query($selectpunt) or die(mysql_error()); 
        while($rowpunt = mysql_fetch_Assoc($respunt))
        {
            $autoidpunten[$j]=$rowpunt['qpunten']+$rowpunt['rpunten']+$rowpunt['snelstepunten']+$rowpunt['bonuspunten']-$rowpunt['strafpunten'];
            //echo "".$row['autoid'] ." Race ".$e." - ".$autoidpunten[$j]." - ".$j."<br>";
            $j++;
        }           
        if ($j<= $merkpunten)
        {
            $totalpunt[$row['autoid']][$e]=array_sum($autoidpunten);
        }   
        else 
        {                   
            $array = $autoidpunten;
            $array_count=count($array);   
            for($i=1;$i<=$merkpunten;$i++)
            {
                $max_val[$i]=max_key($array);
                $view=$array[$max_val[$i]];
                unset($array[$max_val[$i]]);
                $totalpunt[$row['autoid']][$e]=$totalpunt[$row['autoid']][$e]+$view;
            }   
        }           
        $e++;
        unset ($autoidpunten);
    }
    $totalpoints[$row['autoid']]=array_sum($totalpunt[$row['autoid']]);
}

Wat is de oplossing om dit te verhelpen?

[borft]

Je doet een array_sum() over een niet geinitialiseerde variabele. De oplossing is dus voor de while:

PHP:

$autoidpunten = [];

toe te voegen. Ik zou hem op een lege array initialiseren, ipv hem steeds te unsetten.

Overigens, als ik jou was, zou ik me eens inlezen in SQL injection, prepared statements en PDO

[ Voor 37% gewijzigd door borft op 17-03-2016 19:04 ]

[FabiandJ]

borft schreef op donderdag 17 maart 2016 @ 19:01:
Je doet een array_sum() over een niet geinitialiseerde variabele. De oplossing is dus voor de while:

PHP:

$autoidpunten = [];

toe te voegen. Ik zou hem op een lege array initialiseren, ipv hem steeds te unsetten.

Overigens, als ik jou was, zou ik me eens inlezen in SQL injection, prepared statements en PDO

Bedankt dat werkt, ik ben me bewust van de SQL injection mogelijkheid.
Ik ben er sinds vandaag weer in de code geweest, de laatste keer was 3 a 4 jaar geleden

[Bee.nl]

Zorg dat je in ieder geval error_reporting(-1) en ini_set('display_errors', 1) bovenaan je script zet om alle fouten te tonen. Zo lijkt $count op L7 ook niet geinitialiseerd te zijn, al heb je mogelijk niet de volledige code laten zien.

Ennuh, spaties bijten niet Zorg dat je code leesbaar blijft. Met name de opsomming op L14 is slecht te lezen.

[FabiandJ]

Bee.nl schreef op donderdag 17 maart 2016 @ 19:09:
Zorg dat je in ieder geval error_reporting(-1) en ini_set('display_errors', 1) bovenaan je script zet om alle fouten te tonen. Zo lijkt $count op L7 ook niet geinitialiseerd te zijn, al heb je mogelijk niet de volledige code laten zien.

Ennuh, spaties bijten niet Zorg dat je code leesbaar blijft. Met name de opsommingen op L14 is slecht te lezen.

Ik heb inderdaad niet alle code hier gezet 600 regels is iets teveel van het goede

[NMe]

Bee.nl schreef op donderdag 17 maart 2016 @ 19:09:
Zorg dat je in ieder geval error_reporting(-1) en ini_set('display_errors', 1) bovenaan je script zet om alle fouten te tonen. Zo lijkt $count op L7 ook niet geinitialiseerd te zijn, al heb je mogelijk niet de volledige code laten zien.

Ho, zeg daar wel even bij dat je dat niet moet laten staan op een live-omgeving. Hackers vinden niks zo fijn als gedetailleerde foutmeldingen.

[DJMaze]

FabiandJ schreef op donderdag 17 maart 2016 @ 18:58:

code:

$select = "SELECT DISTINCT autoid FROM coureur WHERE leagueid=".$leagueid."";

Ook al zo'n heerlijke beginners fout. Waar leren ze dit toch?
SQL injection daar gelaten, het gebeurt ook met normale strings.
Vooral de punt met aanhalingstekens op het eind stoort mij enorm.

code:

$select = "SELECT DISTINCT autoid FROM coureur WHERE leagueid={$leagueid}";

[Wiebeltje]

Ik snap niet wat voor een beginners fout dit is (op sql injection na).

Het is afhankelijk van je IDE, vaak doen die niet aan syntax highlighting in strings. Ik haal mijn variabelen altijd buiten een string. Alleen die laatste lege string zou ik weg laten. Je code wordt zo veel beter leesbaar imo. Maar zal vooral een persoonlijke voorkeur zijn.

[Voutloos]

Pff DJMaze, beetje overdreven over een lege string aan het einde.

En de keuze tussen PDO args, sprintf(), string concat of inline met curly braces is puur voorkeur qua code style^*. Waarbij curly braces in de context van queries zo maar de minst populaire stijl kan zijn. Dit is geen verdere discussie waard; het blijft subjectief, dus als jij inline curly braces gebruikt en dat consistent doet is dat dikke prima.

Het is hoe dan ook mierenneuken vergeleken met andere punten, bv de injections, en de 'or die($errorDieDeBuitenwereldNeverNooitNietMagZien)'.


^*: Waarbij enkel PDO args ook een technisch voordeel biedt.

[ Voor 7% gewijzigd door Voutloos op 18-03-2016 11:52 ]

[FabiandJ]

Wat betreft de 'or die(mysql_error()' die moeten er dus overal uit als ik het goed begrijp.
Want iedereen die de site bezoekt en er een foutmelding komt krijgt deze dan te zien.

Wat betreft de injections, we hebben ook meerdere pagina's waar we gebruik maken van mysql_real_escape_string, maar ik lees ook verhalen dat ook dit niet secure is. Voorbeeld van een regelcode:

code:

$query = "replace INTO teams_leagues (leagueid, historicteamnaam, teamid) VALUES(" . mysql_real_escape_string($leagueidnew[$a]) .",'" . mysql_real_escape_string($historicname[$a]) ."'," . mysql_real_escape_string($teamid) .")";

Hoe zou bovenstaand voorbeeld er dan uit moeten zien?

[HollowGamer]

DJMaze schreef op donderdag 17 maart 2016 @ 22:58:
[...]

Ook al zo'n heerlijke beginners fout. Waar leren ze dit toch?
SQL injection daar gelaten, het gebeurt ook met normale strings.
Vooral de punt met aanhalingstekens op het eind stoort mij enorm.

code:

$select = "SELECT DISTINCT autoid FROM coureur WHERE leagueid={$leagueid}";

Ik heb altijd geleerd gekregen dat dubbele aanhalingstekens langzamer waren dan enkele.
Tegenwoordig boeit het mij niet meer zoveel.

Betreft jou oplossing.. niet doen. Point mensen naar de select() methode icm. PDO.
mysqli zou ook nog kunnen, alleen zou PDO toch iets beter moeten zijn (niet alleen als je van database-backend wisselt).

[incaz]

Het is me nog niet helemaal duidelijk wat je wilt doen, maar sums en max_values kun je ook rechtstreeks op je database doen. 1 keer je query goed schrijven, met een goede join en group by.

Deze opzet, met steeds nieuwe query's, is echt beduidend meer performance killend dan welk soort aanhalingstekens dan ook.

[DJMaze]

Statements zijn langzamer dan directe query's.
Daarnaast maken veel mensen de fout om PDO te laten connecten met 'localhost' terwijl '127.0.0.1' sneller is.
Het klinkt stom, maar elke 35ms telt.

Gewoon PDO roepen heeft niet zoveel zin als je de randvoorwaarden niet vermeld.

[Voutloos]

FabiandJ schreef op vrijdag 18 maart 2016 @ 12:41:
Wat betreft de injections, we hebben ook meerdere pagina's waar we gebruik maken van mysql_real_escape_string, maar ik lees ook verhalen dat ook dit niet secure is. Voorbeeld van een regelcode:

code:

$query = "replace INTO teams_leagues (leagueid, historicteamnaam, teamid) VALUES(" . mysql_real_escape_string($leagueidnew[$a]) .",'" . mysql_real_escape_string($historicname[$a]) ."'," . mysql_real_escape_string($teamid) .")";

Hoe zou bovenstaand voorbeeld er dan uit moeten zien?

mysql_real_escape_string() kan wel veilig zijn, maar enkel en alleen als het ook echt een string in je query is. En dat hier _niet_ het geval. Je eerste en laatste call hebben namelijk geen quotes in de query. Je kan dan een waarde maken welke deels ook als extra query syntax gezien wordt.

Voorbeeld: Als teamid nu de waarde '42, (foo, bar, buz)' heeft, insert je opeens 2 rows ipv 1. En zo is er nog veel meer narigheid mogelijk. Wellicht leerzaam om dit voorbeeld even met het handje uit te voeren / te beredeneren, en dat nogmaals te doen met quotes om waar de string variabele in je query gaat komen

DJMaze schreef op vrijdag 18 maart 2016 @ 13:49:
Statements zijn langzamer dan directe query's.
Daarnaast maken veel mensen de fout om PDO te laten connecten met 'localhost' terwijl '127.0.0.1' sneller is.
Het klinkt stom, maar elke 35ms telt. [..]
Gewoon PDO roepen heeft niet zoveel zin als je de randvoorwaarden niet vermeld.

Gewoon wat tweaks roepen heeft niet zoveel zin als je niet eerst gemeten hebt. Wellicht werkt het (wederom al was het voor jou), maar hier is het offtopic en voorbarig.

En ik zou zelf eerst meer naar de basics kijken, dan security, en dan pas performance tweaks. En met een beetje mazzel zie je als je beter bent met de basics dat bijvoorbeeld het idee van incaz is wat je wil en zit de performance al snor.

[ Voor 24% gewijzigd door Voutloos op 18-03-2016 13:54 ]