Geen weergave
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
2
3
4
5
6
7
8
9
10
11
12
13
14
15
<?php
$sql = "SELECT favorites.favo_user_id, favorites.favo_add_id_bot
FROM favorites
INNER JOIN user_profiles
ON user_profiles.profile_id = favorites.favo_add_id_bot
WHERE favorites.favo_user_id='".$_SESSION['user_id']."'";
$result = mysql_query($sql);
while($row=mysql_fetch_array($result))
{
echo $row['user_profiles.profile_id'];
echo "<br>";
}
?>
$sql = "SELECT favorites.favo_user_id, favorites.favo_add_id_bot
FROM favorites
INNER JOIN user_profiles
ON user_profiles.profile_id = favorites.favo_add_id_bot
WHERE favorites.favo_user_id='".$_SESSION['user_id']."'";
$result = mysql_query($sql);
while($row=mysql_fetch_array($result))
{
echo $row['user_profiles.profile_id'];
echo "<br>";
}
?>
Hij zou nu 2 records moeten weergeven. Enkel krijg ik geen foutmelding maar geeft hij ook niks weer.
Kan iemand mij de juiste richting inschoppen?
Quote:
Doe eens een print_r($row) binnen je while loop. 10 euro zegt dat de kolom die je vraagt niet bestaat in je resultset.
2 hints:
1. Je selecteert de kolom niet
2. Kolomnamen in resultsets zijn altijd alleen gevormd door de kolomnaam, de tabelnaam zit er niet aan vast.
Gewijzigd op 09/02/2017 23:01:30 door Ben van Velzen
Zonder code alleen platte tekst:
SELECTEER X.a, X.b, X.c
VAN
iets
hussel bij elkaar
X = iets van Y = iets
ik doe een loop:
ik wil rij['poep'] zien... die ik niet heb geselecteerd... :)
Beter kan ik het denk ik niet uitleggen.
Gewijzigd op 09/02/2017 23:25:41 door Bart V B
Je zult nu direct "undefined index" meldingen krijgen.
Fouten zoals die van de topicstarter vallen toch een beetje onder de rubriek "te weinig koffie" en kunnen door een nette werkhouding en een goed ingerichte ontwikkelomgeving eenvoudig zelf gedetecteerd + opgelost worden.
EDIT: ben je trouwens nieuwe code aan het schrijven met mysql_-functies? Ik zou je dringend willen verzoeken over te schakelen naar MySQLi of PDO want de MySQL-extensie is
Gewijzigd op 10/02/2017 09:08:49 door Thomas van den Heuvel
Toevoeging op 10/02/2017 23:10:07:
Toch gelijk maar even opgepakt :)
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
2
3
4
5
6
7
8
9
10
11
12
13
14
<?php
$result = mysqli_query($link,"SELECT favorites.favo_user_id, favorites.favo_add_id_bot
FROM favorites
INNER JOIN user_profiles
ON user_profiles.profile_id = favorites.favo_add_id_bot
WHERE favorites.favo_user_id='130'");
while($row = mysqli_fetch_array($result))
{
echo $row['favorites.favo_user_id'] . " " . $row['favorites.favo_add_id_bot'];
echo "<br>";
}
?>
$result = mysqli_query($link,"SELECT favorites.favo_user_id, favorites.favo_add_id_bot
FROM favorites
INNER JOIN user_profiles
ON user_profiles.profile_id = favorites.favo_add_id_bot
WHERE favorites.favo_user_id='130'");
while($row = mysqli_fetch_array($result))
{
echo $row['favorites.favo_user_id'] . " " . $row['favorites.favo_add_id_bot'];
echo "<br>";
}
?>
Maar nu krijg ik de volgende errors
Warning: mysqli_query(): Couldn't fetch mysqli in on line 23
Warning: mysqli_fetch_array() expects parameter 1 to be mysqli_result, null given in on line 25
De foutmeldingen zijn redelijk to-the-point. Lees goed wat er staat, dit legt meestal direct de vinger op de zere plek.
Raadpleeg ook de documentatie, in vergelijking met de oorspronkelijke MySQL extensie zijn er mogelijk parameters verschoven en/of nu verplicht.
En als je verstandig bent leer je direct werken met de object-georiënteerde aanpak en vat je je mysqli-functionaliteit in een of meer wrapper classes zodat wanneer de MySQL implementatie de volgende keer verandert je niet heel je code door hoeft te ploeteren maar in het meest ideale geval enkel de implementatie van je wrappers hoeft aan te passen. In zekere zin ben je met directe aanroepen van mysqli-functies dingen aan het hardcoden en dat is mogelijk iets dat je zou moeten vermijden.
Wel maak ik een kleinere wrapper in de vorm van een extend. Hiermee extend ik de MySQLi class en kloon de de query-method alwaar ik daar directe foutafhandeling in bouw. Uiteraard zou ik in de exceptionhandler wel controleren of men de technische foutmeldingen mag zien. Want je wilt bezoekers niet voorzien van lastige niet-relevante foutmeldingen of zelfs hackers meer wijsmaken over de bouw van je applicatie.
Code (php)
Code (php)
Overgenomen uit deze tutorial.
Gewijzigd op 11/02/2017 11:44:47 door - Ariën -
Een wrapper zou je ook werk uit handen moeten nemen. Zo zou je dus een eigen constructor kunnen schrijven die allerlei instellingen automatisch voorziet van een standaard waarde. Zoals: de host (gebruik bij voorkeur een IP en niet "localhost" of een andere hostname), de poort (standaard 3306) en niet te vergeten (héél belangrijk, maar ontbreekt in het bovenstaande voorbeeld) een expliciete character encoding (mogelijke default: utf8). Je hoeft dan enkel afwijkende instellingswaarden op te geven bij connectie wat in de praktijk neerkomt op enkel een gebruikersnaam, wachtwoord en database-naam.
Ook kun je in een wrapper een heleboel (micro-)optimalisaties doorvoeren en functies/methoden bundelen.
Dit komt niet helemaal uit de verf in het bovenstaande (en enigszins triviale) voorbeeld.
pro tip: stop deze in een bookmark, heb ik ook gedaan, want met de zoekfunctionaliteit van deze site kan ik mijn eigen topics niet eens terugvinden.
Gewijzigd op 11/02/2017 13:20:49 door - Ariën -
Iemand die mij de juiste kan wijzen.
Thomas van den Heuvel op 11/02/2017 12:13:34:
Zoals: de host (gebruik bij voorkeur een IP en niet "localhost" of een andere hostname)
En hier zou ik dus juist weer het tegengestelde advies geven: gebruik als het enigszins mogelijk is géén IP-adres. In mijn ervaring zijn IP-adressen veranderlijker dan hostnames en het heeft me al menig uur gekost om allerlei configfiles door te akkeren waarin IP-adressen werden gebruikt om te verwijzen naar de een of andere server.
Gewijzigd op 12/02/2017 18:45:56 door Willem vp
Lokaal is altijd sneller ;-)
Gewijzigd op 12/02/2017 20:02:39 door - Ariën -
Willem vp op 12/02/2017 18:45:17:
En hier zou ik dus juist weer het tegengestelde advies geven: gebruik als het enigszins mogelijk is géén IP-adres. In mijn ervaring zijn IP-adressen veranderlijker dan hostnames en het heeft me al menig uur gekost om allerlei configfiles door te akkeren waarin IP-adressen werden gebruikt om te verwijzen naar de een of andere server.
Okay, maar dat is een praktische (ontwerp)beslissing waarbij je performanceverlies pakt (geen resolving lijkt mij altijd sneller?) omdat je er blijkbaar niet van uit kunt gaan dat de partijen waarmee je zaken doet te pas en te onpas schuiven met servers. Tis maar net hoe netjes zij werken en hoe alert / klantvriendelijk / meedenkend zij te werk gaan bij aanpassingen / migraties nietwaar.
Dit doet dus ook niet af aan mijn variant waarbij mijn voornaamste argument performance was, maar als dat om praktische redenen niet kan gebruik je een hostname uiteraard.
Maar daar gaan trouwens ook af en toe dingen mis als er iets spaak loopt in de resolving zelf. Dat kost dan ook tijd om uit te zoeken.
Zelf heb ik overigens wel eens een enkele keer gehad dat ik niet kon connecten met MySQL op 'localhost', maar wel weer op '127.0.0.1'. Maar dat was gewoon een slecht geconfigureerde server. Vanaf installatie af aan moet dit gewoon al goed werken.
- Ariën - op 13/02/2017 16:31:53:
Zelf heb ik overigens wel eens een enkele keer gehad dat ik niet kon connecten met MySQL op 'localhost', maar wel weer op '127.0.0.1'. Maar dat was gewoon een slecht geconfigureerde server. Vanaf installatie af aan moet dit gewoon al goed werken.
Euh, dat kwam dan toch alleen omdat je een aanname deed over wat jij dacht dat het had moeten zijn. Alles wat daar van afwijkt = slecht? Je had natuurlijk ook kunnen informeren naar hun beweegredenen voor hun aanpak in plaats van het op voorhand afschrijven van een andere insteek.