Problemen met verwerken van de fouten in de database

Dat bedoel ik dus... ;-)

Laten we even alles op een rij zetten met al je relevante code, en wat er nu precies gebeurt.

[size=xsmall]Toevoeging op 29/12/2016 16:38:50:[/size]

Thomas van den Heuvel op 29/12/2016 16:36:47

@Ariën het is te allen tijde zowel voor beginners als gevorderden belangrijk om verschillende taken en verantwoordelijkheden in code te scheiden om zo het overzicht te bewaren.

Maakt niet uit of dit beginnerscode of geavanceerd spul is: wanneer je teveel combineert resulteert dit in een onoverzichtelijke brei waarin weinig tot niets aangepast kan worden zonder dat de hele toren instort.

Met turbo-taal bereik je niks. Geef dan ook praktische voorbeelden als je moeilijke theorie uitlegt. En OOP/OO voor een beginner is toch een stapje te ver.

Niet iedereen heeft bovendien kennis die gelijk is aan jou.

Dude... Lees de vorige edit op mijn reactie. Je zegt elke keer dat ik doordraaf in mijn antwoorden en dat iedereen maar procedurele code moet blijven schrijven?

Hell, het probleem is hier wederom niet eens het probleem.

Het is weer een vraagstuk waarbij de topicstarter de foutmelding niet begrijpt. Zie mijn vorige edit. De functies mysqli_error() en mysqli_errno() worden gewoon verkeerd aangeroepen.

Ik vind het grappig dat ik bekritiseerd wordt door aan te geven wat nodig (noodzakelijk?) is terwijl de topicstarters niet worden teruggefloten omdat ze mogelijk duidelijk met dingen bezig zijn die nu boven hun pet gaan.

Jij hebt liever dat iemand een modderig zijpad inslaat en dapper voortploetert totdat ze iets hebben wat werkt maar niet precies weten waarom, ik leid ze liever terug naar een verharde weg en vertel hun dat ze die eerst maar een eindje zouden moeten volgen.

Daarnaast lijken we hier *zo* gebrand om een direct antwoord te geven zonder analyse hoe iets anders of mogelijk beter kan.

Ik geeft liever ideeën dan oplossingen want de gebruikte oplossing doet er in wezen niet toe (en is in veel gevallen ad hoc, hardcoded en niet herbruikbaar). De onderbouwing van een oplossing is wat mij betreft belangrijker dan de oplossing zelf.

Thomas van den Heuvel op 29/12/2016 16:45:11

Dude... Lees de vorige edit op mijn reactie. Je zegt elke keer dat ik doordraaf in mijn antwoorden en dat iedereen maar procedurele code moet blijven schrijven?

Nee, dat zeg ik niet, maar je komt wel een beetje overhit en aanvallend over naar mij.

En tja, als de topicstarter opeens na je 'turbo-taal' je niet snapt (waar ik voor gewaarschuwd heb) dan is het punt wel duidelijk.

Okay, waar te beginnen. Allereerst, ik heb mijn vorige twee reacties nog eens overgelezen. Hier staan echt niet zulke moeilijke dingen in. En waar mogelijk nieuwe termen worden geïntroduceerd licht ik toe wat deze betekenen. Dit is geen turbo-taal of wat voor denigrerende term je hiervoor ook wilt gebruiken maar redelijk normale vaktaal.

Bij het leren van nieuwe dingen komt het vaak voor dat je zaken niet direct oppikt. Dit is normaal. Net zoals bij het leren van een spreektaal is herhaling een belangrijke factor. Zolang je termen maar vaak genoeg hoort en (met toelichting) voorbij ziet komen leer je deze taal op den duur vanzelf spreken. Aan de ene kant moet deze gevoed worden maar aan de andere kant moet de persoon ook een inspanning verrichten om iets op te pikken. Hierbij maakt het niet uit dat iemand initieel maar 10% oppikt.

Het helpt natuurlijk wel/ook als je een beetje een onderzoekende aard hebt en openstaat voor nieuwe dingen. Daarom snap ik ook niet goed waarom niet direct begonnen wordt of zou kunnen worden met het verschil uitleggen tussen procedurele en object georiënteerde code (of, en misschien belangrijker, hoe je iets moet debuggen). Sommige individuen willen het moment van introductie van het laatste zover mogelijk vooruit schuiven. Waarom?

** knip **

Ik heb helaas een hoop dingen gelezen hier waar ik niet zo heel veel aan heb. Dit projectje ga ik dan denk ik ook maar even parkeren. De foutmelding is er en blijft bestaan. Dan maar verder zonder dit deel te begrijpen.

Lees namelijk veel over een mee te geven waarde en dergelijke maar daarmee heb ik het nog niet begrepen of zijn de foutmeldingen nog niet weg.

wat voor melding krijg je als je de regel $db = 'null'; uit je config bestand verwijdert?

Waar Ariën op doelt, is volgens mij dat wij gewoon Jip en Janneke taal moeten gaan gebruiken ipv allemaal "dure" woorden te gaan gebruiken waar een beginner niks aan heeft en de logica helemaal niet meer begrijpt omdat de vraagstuk open blijft staan. Naar mijn mening hebben beide heren gelijk ;-)

Ontopic:
Rubensky, je begint met deze topic met een stukje code EN je geeft 2 foutmeldingen mee.

Om te beginnen:

De error:
Warning: mysqli_errno() expects parameter 1 to be mysqli, string given in /public/sites/mijnsite/php/Gastenboek/functions.php on line 40

Wat is het probleem
- Het probleem zit hem op regel 40.
- mysqli_errno() verwacht een parameter, er is een string gegeven.

Als we naar je code kijken, doe je het volgende:

mysqli_errno($db)

In $db gebruik je een "string", zoals men al heeft aangegeven:

$db = 'null';

is wat anders dan (zoals Frank al aangaf ):

$db = null;

Als we jou stukje code nu eens helemaal "handmatig" gaan invullen op basis van je "config bestanden"

dan ziet jou code er zo uit (afhankelijk van de waarde $db ), zie hieronder voor overige uitleg:

<?php
// DEBUG_MODE staat op true
if (DEBUG_MODE) {
  if (!$result = @mysqli_query('null', 'null')) {
    die("{'Er is een fout opgetreden bij het werken met de database'})
    <br> uitgevoerde query: 'null' .
    <br> MySQL-foutnummer: ". mysqli_errno('null') .
    "<br>MySQL-melding: " . mysqli_error('null'));
  }
}
?>

Dus eigenlijk, gaat het al helemaal fout bij de eerste "if", en de overige errors op je pagina, zijn "vervolgschade" door een eerder gemaakte fout.


Je zegt tevens ergens dat je dit al eerder toepast:

if (!$db = mysqli_connect($host, $gebruiker, $wachtwoord, $database)) {
    echo '<h2>Het openen van de database is mislukt</h2>';
    echo 'De MySQL-foutmelding luidt: ' . mysqli_connect_error();
    exit; 
}

Tot aan hier, gaat het niet mis.
Maar je volgende "stap" ( waar je de topic mee opende) , daar gaat het fout.
Vul is in je config tabel bij $query iets in, bijvoorbeeld: $query = 'SELECT * FROM tabel';
Je zult merken dat je direct tegen een ander probleem aanloopt.

Mocht dit niet het geval zijn, post alle code die je hebt ;-)
Tip: Kijk nog eens goed naar deze pagina en zoek de verschillen:
http://php.net/manual/en/mysqli.query.php

"wat voor melding krijg je als je de regel $db = 'null'; uit je config bestand verwijdert?"
Deze wordt niet gebruikt ;-) dus kan simpelweg verwijderd worden.

Nou, dat vroeg ik me af: bij mysqli_connect() kan niet veroorzaakt worden dat $db een string bevat.

Wél in de configfile.

Zit me intussen af te vragen of de configfile mogelijk 2x geinclude wordt.

Ik heb het net enigszins naproberen te bootsen:

<?php
define ('DEBUG_MODE', true);
$ERRORS ['QUERY_ERROR_USER'] = 'Onze excusus er is iets mis gegaan met de database neem eventueel contact op met de beheerder';
$ERRORS ['QUERY_ERROR_ADMIN'] = 'Er is een fout opgetreden bij het werken met de database<br>';

$host = 'localhost';
$gebruiker = 'root';
$wachtwoord = '';
$database = 'local';
$query = 'null';
//$db = 'null';

if (!$db = mysqli_connect($host, $gebruiker, $wachtwoord, $database)) {
    echo '<h2>Het openen van de database is mislukt</h2>';
    echo 'De MySQL-foutmelding luidt: ' . mysqli_connect_error();
    exit; 
}

if (DEBUG_MODE) {
	if (!$result = @mysqli_query($db, $query)) {
		die("{$ERRORS['QUERY_ERROR_ADMIN']}
		<br> uitgevoerde query: $query .
		<br> MySQL-foutnummer: ". mysqli_errno($db) .
		"<br>MySQL-melding: " . mysqli_error($db));
	}
	else {
		return $result;
	}
}
else{
	if (!$result = @mysqli_query($db, $query)){
		die ($ERRORS ['QUERY_ERROR_USER']);
	}
	else {
		return $result;
	}
} 
?>

output:

Er is een fout opgetreden bij het werken met de database

uitgevoerde query: null .
MySQL-foutnummer: 1064
MySQL-melding: You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near 'null' at line 1

Verander ik $query in bv SELECT * FROM tabel --> dan zijn de errors weg.
Welliswaar geen output ;-)