Thomas - 12/07/2014 13:50 (laatste wijziging 12/07/2014 13:58)
Moderator
Volgens mij gaat het POSTen wel goed, maar het uitvoeren van je query niet?
Een INSERT-query werkt meestal als volgt:
INSERT INTO <tabel_naam> (<kolom_1>, ..., <kolom_n>)
VALUES (<waarde_voor_kolom_1>, ..., <waarde_voor_kolom_n>)
In jouw geval komt het aantal kolommen dat je wilt wegschrijven (de VALUES - dit zijn er vijf) niet overeen met het aantal kolommen dat je hebt gedefinieerd in je INSERT-INTO-deel (dit zijn er vier).
Normaal zou je dan een MySQL-error moeten krijgen, geen idee waarom dat niet gebeurt? Je krijgt dus niet de foutmelding van regel 58 te zien als je het formulier verstuurt? Curieus.
EDIT: Je syntax klopt niet eens volgens mij, er staat (weer) een afsluitende accolade op regel 46?! Krijg je geen parse error van PHP? Hoe kun je hier geen terugkoppeling over krijgen :/.
/*!40101 SET CHARACTER_SET_CLIENT=@OLD_CHARACTER_SET_CLIENT */;
/*!40101 SET CHARACTER_SET_RESULTS=@OLD_CHARACTER_SET_RESULTS */;
/*!40101 SET COLLATION_CONNECTION=@OLD_COLLATION_CONNECTION */;
Thomas - 12/07/2014 17:08 (laatste wijziging 12/07/2014 17:11)
Moderator
Heb het laatste relevante code-deel en de tabeldefinitie getest, als ik de volgende waarden invul voor respectievelijk voornaam, achternaam, nummer, nummer2, leeftijd: voornaam, achternaam, een, twee, 88 dan krijg ik netjes "1 record added" en het volgende database record:
Wel klopt er weinig van de syntax van je HTML-document (maar dat zou de werking waarschijnlijk niet moeten beïnvloeden).
Daarnaast zijn er inconsistenties in je character sets. Zoals eerder aangegeven is utf8_unicode_ci geen geldige character set voor een HTML-document voor zover ik weet.
En je database character set is latin1... Maar zoals bovenstaande output laat zien weerhoudt dit mij nog steeds niet van het correct invoegen van informatie.
EDIT: heb je de code ook bijgewerkt waar je deze uitvoert? M.a.w. heb je deze geupload of whatever? Ik weet niet waar je je code inklopt (waarschijnlijk op je eigen -lokale- computer?) en je deze uitvoert (waarschijnlijk op een webserver)? Als deze twee locaties verschillen moet je dus nog je code van A naar B verplaatsen na aanpassing eh.
Ik had met form action naar het verkeerde bestand verwezen
De code werkt perfect!
De charset moet ik inderdaad nog aanpassen naar UTF-8, maar in de database lijkt me dan utf8_unicode_ci de meest voor de hand liggende. Als ik dat beter niet kan kiezen, wat is dan het alternatief?
En de HTML ga ik aanpassen.
Hartelijk dank!
Thomas - 13/07/2014 15:46 (laatste wijziging 14/07/2014 11:51)
Moderator
Niet al te lang geleden heb ik een vrij uitgebreide MySQLi tutorial geschreven. Hierin komt het correct gebruik van character sets ook aan bod.
Dit komt neer op:
- het instellen van de juiste character set van je Content-Type header. Dit kan op twee manieren:
1. via een meta tag (zorg er wel voor dat dit de EERSTE tag in je <head> is dan, nog voor je <title> dus...)
EN / OF
2. via een PHP-header
- het selecteren van de juiste character set bij het maken van een verbinding met je database, meestal is er een ..._set_charset() functie beschikbaar
- het ervoor zorgen dat je tabellen en tabel-kolommen van de juiste character set zijn
- het ervoor zorgen dat je je data op de juiste manier in je database hebt gezet, als je bijvoorbeeld een utf8-tabel hebt in MySQL, maar je had geen character set geselecteerd bij het maken van je verbinding, grote kans dat je dus data met een latin1-encoding hebt opgeslagen in een utf8-tabel
Nota bene: het instellen van een character set voor je database met een ..._set_charset() functie heeft ook implicaties voor de werking van je ..._real_escape_string() functionaliteit. Dit is dus direct van invloed op de veiligheid van / veilig communiceren met je database!
Bij voorkeur stemmen al deze character sets overeen zodat er geen vertaalfouten gemaakt kunnen worden en er ook geen overhead is, MySQL kan namelijk nog het een en ander (proberen te) repareren als je met character set A connect, terwijl je database-data in character set B is opgeslagen, deze probeert die dan terug te vertalen naar A, maar dat is dus niet altijd succesvol...
Een redelijk standaard character set die tegenwoordig wordt gebruikt is UTF-8. Deze is (vele malen) uitgebreider dan latin1 (de default die MySQL gebruikt, maar wellicht is dit inmiddels veranderd). Als ik het goed heb begrepen gebruikt latin1 zelf cp1252 West European, en deze wijkt af van iso-8859-1 al werden deze wel vaak (?) (onbewust) gecombineerd. cp1252 is ook geen standaard...
In een HTML-document wordt aan UTF-8 gerefereerd met UTF-8. In MySQL is dit echter utf8. Ook zijn er ondertussen ook al "uitbreidingen" op utf8 die langere multibyte-karakters ondersteunt:
Maar utf8 zou voor de meeste doeleinden wel genoeg zijn en is in een aantal opzichten handiger dan latin1.
EDIT: vaak is het niet eens duidelijk dat je data op de verkeerde manier wegschrijft naar je database (bijvoorbeeld omdat je een ..._set_charset() aanroep bent vergeten). De ellende begint wanneer je dit vervolgens repareert (je deze aanroep toevoegt). Dan wordt pijnlijk duidelijk dat je data met de verkeerde encodering is opgeslagen - deze wordt dan (doordat je nu via de juiste character set met je database communiceert) mogelijk ook gecorrumpeerd weergegeven. Het is dan zaak dat je voor het toevoegen van nieuwe data of het wijzigen van bestaande data je gegevens repareert want het wordt al helemaal een puinzooi als je zowel juist als verkeerd geëncodeerde data in je database hebt zitten.
Gesponsorde links
Je moet ingelogd zijn om een reactie te kunnen posten.