I.v.m je fout:
Je gaat iets specifieker moeten zijn. Wat is de error code of output die je ziet/krijgt?

Ongerelateerd met je fout:
Kuis je code op! Gebruik indentation, volg de coding conventions. Dit zou toch wel basis kennis moeten zijn.
voor meer info: PSR-2 — Coding Style Guide
Dit maakt het nakijken op het forum makkelijker.

Probeer eens het volgende:
[PHP] <?php class connection { static protected $con; protected $data; - Pastebin.com

Citaat van futur3

Ik heb zelf opnieuw iets geschreven ongeveer het zelfde en het werkt!
Alleen als ik niks invul geeft hij ook geen error's aan maar dat zal ik oplossen.
Maar bedankt voor de antwoorden/tips!
Greetz.futur3

Gebruik in connect() het volgende;
or die(mysqli_error());

Citaat van Teun

Gebruik in connect() het volgende;
or die(mysqli_error());

als je het dan netjes wilt doen middels een class doe je het afhandelen met een try / catch statement. Als je met classes werkt wil jij vrijwel ten alle tijden een die() voorkomen. Desnoods maak je je eigen excepetion class die je extend van de default php exception class zodat je het netjes kan afhandelen (i.e. foutmelding in layout verwerken, ergens naar laten wegschrijven etc.)

Citaat van futur3

Ik heb zelf opnieuw iets geschreven ongeveer het zelfde en het werkt!
Alleen als ik niks invul geeft hij ook geen error's aan maar dat zal ik oplossen.
Maar bedankt voor de antwoorden/tips!
Greetz.futur3

Hey @futur3 zou je de code willen posten zoals je het werkend hebt gekregen? Dan Hebben andere er later misschien ook wat aan Alvast bedankt.

Super! Zo hebben andere leden er ook nog iets aan

En, for the love of all that is good and holy, stel alsjeblieft een character encoding in, bijvoorbeeld utf8 (dit is geen typo, zo heet de UTF-8 character encoding in MySQL).

Dit doe je middels een _set_charset() aanroep, bij voorkeur direct na het maken van een verbinding met je database.

Wanneer je geen of de verkeerde character encoding instelt is er geen garantie dat je _real_escape_string() functionaliteit (waarmee je je queries beveiligt tegen SQL injectie) correct werkt.

Daarnaast kan dit resulteren in het verkeerd encoden van data die je wegschrijft naar je database (lees: de data in je database is dan in feite dus CORRUPT). Hier heb je normaal geen last van (omdat MySQL veel voor je regelt onder de motorkap) totdat je je character encoding goed instelt, en dan heb je stront.

Vervolgens is het het makkelijkste om in je hele applicatie je character encoding gelijk te schakelen. Gebruik daartoe een PHP header() aanroep, of stel het desnoods in in een meta-tag.

Ik kan dit wel op een pamflet stempelen en elke keer uitdelen, want dit wordt keer op keer gewoon vergeten.

Elke developer zou http://www.joelonsoftware.com/articles /Unicode.html eens moeten lezen...

Ik heb die code nog eens bekeken, en die is toch wel heel wollig om enkel een connectie te maken... en regelt verder helemaal niets. Je zou je ook af kunnen vragen waarom je je login credentials zou willen onthouden binnen een object van de klasse? Wat is het nut / de toegevoegde waarde daarvan?

Over try-catch vs die(): als je connectie mislukt omdat je login gegevens verkeerd zijn of de database op een of andere manier onbereikbaar is dan zou ik verdere uitvoer van het script gewoon staken met die(). Dit omdat er op dat moment waarschijnlijk iets grondig mis is in de (server)configuratie. Garanties ten aanzien van het (verder) correct werken van je applicatie kun je dan niet echt meer geven. Het is waarschijnlijk ook geen fout waar je snel (vanzelf) van zult "herstellen".

Soms moet je de boel gewoon laten ontploffen in plaats van dingen tegen beter weten in draaiende proberen te houden. In dat laatste geval kun je er mogelijk pas in een heel laat stadium (of na heel veel onderzoek) achter komen dat iets gewoon niet werkt.

Combinaties van fouten kunnen ook nieuwe fouten opleveren. Dat gaat je op den duur problemen opleveren die je niet meer uit de weg kunt gaan. En dan moet je dus dingen gaan repareren en dan is de kans heel erg groot dat je ineens een heleboel moet repareren als je daarvoor een strategie hanteerde waarbij je alle fouten onder het tapijt veegt.

Om een heel andere reden is het bij PDO wel weer verstandig om je connectie te regelen binnen een try-catch blok. Dit vanwege het feit dat als de connectie (om wat voor reden dan ook) mislukt, er een exception ge-throwd wordt. Een exception die je niet catcht levert een fatal error op. En laten de lichten die bij de ontwikkeling van PDO actief zijn geweest nu bedacht hebben dat je login-gegevens afgedrukt worden in deze exception/fatal error... die liggen dan dus waarschijnlijk op straat als je dit zelf niet netjes afhandelt.

Nadat je connectie "up and running" is (en ook andere objecten die je in je applicatie gebruikt succesvol zijn aangemaakt) zou je natuurlijk altijd een try-catch blok om de rest van je applicatie -en daarmee ook rond de uitvoer van queries- kunnen zetten. Het kan natuurlijk altijd voorkomen dat de uiteindelijke vorm van een query die dynamisch wordt opgebouwd niet goed is. Het is dan wel zo netjes dat eindgebruikers een nette foutpagina zien in plaats van een "or die(mysql_error())" boodschap. In je catch-blok kun je de fout ook ergens loggen zodat je later terug kunt lezen wat er fout ging.

Ik zou zelf voor een wat andere aanpak kiezen als ik een "wrapper" zou schrijven voor mysqli. Eentje met toegevoegde waarde en een zeker gebruikersgemak. Indien gewenst kan ik een vereenvoudigde vorm posten voor wie interesse heeft.