Zoals je hierboven ziet zo ziet het er nu uit.
Hier komen de logs van de ingelogde users.
Maar er kunnen niet 2 dezelfden in 'usern'
dus als peter 1x inlogt komt dit hier te staan
Maar als hij voor de 2e X inlogt komt dit er niet tussen, hoe is dit op te lossen?
Als je op het moment dat iemand inlogt de bovenstaande query uitvoert zou dit gewoon moeten werken mits de tabel geen speciale restricties heeft ten aanzien van kolomwaarden.
Ook moet je natuurlijk zorgen dat je de inlog-informatie op de goede plaats ophaalt, $_REQUEST is nogal algemeen.
Waarom heet deze tabel trouwens USERS en niet login_log ofzo?
Dit is toch niet een tabel voor de opslag van gegevens van bestaande users wel? Anders moet je je aanpak veranderen... Je zou dan een kolom laatste_ip en laatste_login_datum aan kunnen maken en deze informatie altijd bijwerken als iemand inlogt.
Je aanpak wordt bepaald door de betekenis van de tabel.
Als usern de primary key is staat er een UNIQUE constraint op.
Als het de PK is dan is de naam onderstreept als je de tabel structuur bekijkt.
Je kan dit oplossen met ON DUPLICATE KEY UPDATE:
INSERT INTO USERS (usern, ip, id, date)
VALUES('peter', '192.168.0.254', 22, NOW())
ON DUPLICATE KEY UPDATE
ip = VALUES(ip),
id = VALUES(id),
date = VALUES(date)
Als usern de primary key is staat er een UNIQUE constraint op.
Als het de PK is dan is de naam onderstreept als je de tabel structuur bekijkt.
Je kan dit oplossen met ON DUPLICATE KEY UPDATE:
INSERT INTO USERS (usern, ip, id, date)
VALUES('peter', '192.168.0.254', 22, NOW())
ON DUPLICATE KEY UPDATE
ip = VALUES(ip),
id = VALUES(id),
date = VALUES(date)
Hallo,
Ik heb dit geprobeert maar hierbij bleef de pagina wit.
$fname = $_REQUEST['fname'];
$fname1 = $_REQUEST['fname1'];
$fname2 = $ip=$_SERVER['REMOTE_ADDR'];
$fname3 = $_GET['id'];
$fname4 = date('Y/m/d H:i:s');
try {
$conn = new PDO("mysql:host=$servername;dbname=$dbname", $username, $password);
// set the PDO error mode to exception
$conn->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
$sql = "INSERT INTO USERS (usern, ip, id, date)
VALUES ('$fname', '$fname2', '$fname3', '$fname4')";
ON DUPLICATE KEY INSERT
UPDATE ip = $_REQUEST['fname2'];
UPDATE id = $_REQUEST['fname3'];
UPDATE date = $_REQUEST['fname4'];
$conn->exec($sql);
ON DUPLICATE .... hoort bij de insert query, je kan dit letterlijk overnemen uit mijn voorbeeld, je moet alleen de waardes voor de kolommen, vervangen door jouw PHP variabelen.
Voor de volledigheid:
<?php
$sql = "INSERT INTO USERS (usern, ip, id, date)
VALUES('$fname', '$fname2', '$fname3', NOW())
ON DUPLICATE KEY UPDATE
ip = VALUES(ip),
id = VALUES(id),
date = VALUES(date)";
?>
ON DUPLICATE .... hoort bij de insert query, je kan dit letterlijk overnemen uit mijn voorbeeld, je moet alleen de waardes voor de kolommen, vervangen door jouw PHP variabelen.
Voor de volledigheid:
<?php
$sql = "INSERT INTO USERS (usern, ip, id, date)
VALUES('$fname', '$fname2', '$fname3', NOW())
ON DUPLICATE KEY UPDATE
ip = VALUES(ip),
id = VALUES(id),
date = VALUES(date)";
?>
Bedankt, maar dit werkt niet
Ik krijg nu geen error maar hij update de datum etc niet.
$conn = new PDO("mysql:host=$servername;dbname=$dbname", $username, $password);
// set the PDO error mode to exception
$conn->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
$sql = "INSERT INTO USERS (usern, ip, id, date)
VALUES('$fname', '$fname1', '$fname3', '$fname4')
ON DUPLICATE KEY UPDATE
ip = VALUES(ip),
id = VALUES(id),
date = VALUES(date)";
Even buiten wel of niet deze aanpak, ON DUPLICATE KEY UPDATE werkt alleen als een waarde wordt ingevoerd die al bestaat in de tabel voor een kolom met een unieke index.
Blijkbaar is dan usern niet de primary key, het lijkt er zelfs op dat er helemaal geen PK in de tabel aanwezig is, wat natuurlijk wel moet.
Maar goed, de vraag is een beetje: wil (moet) je deze twee verschillende dingen (willen) combineren.
Ik ben toch een beetje voor een doorzichtige werking, hier hang je met deze tabelcreatie extra betekenis aan bepaalde kolommen die gaan over de data die bepaalt wat een INSERT-query doet. Misschien is het handig om dit soort zaken toch te programmeren? Bij een nieuwe registratie zul je ook iets moeten als een gebruikersnaam al bestaat. Een registratie laat je niet "kapot" gaan enkel door de unique restrictie lijkt mij?
Daarnaast, als je het IP gebruikt om (in combinatie met andere informatie) logins te onthouden dan heb je misschien een flexibelere aanpak nodig dan het enkel onthouden van de laatste entry.
Het doel lijkt ook "logging" wat mogelijk het bestaansrecht van een aparte tabel rechtvaardigt.
