Snippets - Diskussionsthread

[MrToiz]

Bei mir regelt das die Query-Klasse, hier mal die relevante Funktion:

/* Fehlermeldungen verarbeiten */
function _handle_error()
{
	if(@mysql_errno()) {
		$this->_errno	= mysql_errno();
		$this->_errmsg	= mysql_error();
		if(!$this->_errlog) {
			$this->_errlog	= @fopen(dirname(__FILE__).'/mysql.err', 'a');
		}
		if($this->_errlog) {
			fwrite($this->_errlog, '['.date('r').'] '.$this->_errno.': '.$this->_errmsg.($this->_query ? "\r\n\t".$this->_query : '')."\r\n");
		}
	}
}

Aufruf erfolgt innerhalb der query()-Funktion so:

if($this->_result) {
	return $this->_result;
}
else {
	$this->_handle_error();
	return FALSE;
}

Müsste denke ich leicht an deine Bedürfnisse anpassbar sein.

 

[php]

[...]Aufruf erfolgt innerhalb der query()-Funktion so:

if($this->_result) {
    return $this->_result;
}
else {
    $this->_handle_error();
    return FALSE;
}

Müsste denke ich leicht an deine Bedürfnisse anpassbar sein.

HUH? Das heisst wie müsste ich folgendes anpassen:

$query = "SELECT * FROM `Login` WHERE `nickname` = '$nickname'";
$sql = mysql_query($query) or die(mysql_error());;

Nur so:
or die(mysql_error());; ==> or die(handle_error());;

 

[MrToiz]

HUH? Das heisst wie müsste ich folgendes anpassen:

$query = "SELECT * FROM `Login` WHERE `nickname` = '$nickname'";
$sql = mysql_query($query) or die(mysql_error());;

Nur so:
or die(mysql_error());; ==> or die(handle_error());;

Wenn die Skriptausführung bei Query-Fehlern abgebrochen werden soll - ja!
Allerdings würde ich dann in die handle_error(); noch ein "echo 'Es trat ein MySQL-Fehler auf! Blablabla';" einbauen.
Außerdem muss die Funktion noch auf die Verwendung außerhalb der Klasse angepasst werden, also:

/* Fehlermeldungen verarbeiten */
function handle_error($query = '')
{
    static $_errlog = FALSE;
    if(@mysql_errno()) {
        $_errno     = mysql_errno();
        $_errmsg    = mysql_error();
        if(!$_errlog) {
            $_errlog    = @fopen(dirname(__FILE__).'/mysql.err', 'a');
        } 
        fwrite($_errlog, '['.date('r').'] '.$_errno.': '.$_errmsg.($query ? "\r\n\t".$query : '')."\r\n");
        echo 'Es trat ein MySQL-Fehler auf!';
    }
}


1:
2:
		
$query = "SELECT * FROM `Login` WHERE `nickname` = '$nickname'";
$sql = mysql_query($query) or die(handle_error($query));

 

[tleilax]

Sorry für meine paar Cents, aber wenn es hier schon um das Maskieren von Parametern und Fehlerbehandlung geht, sollte man evtl auch langsam dazu raten, dass für sowas ein eigener DB-Abstraktionslayer um einiges besser ist als der durch Funktionen entstehende Overhead in den Dateien.

 

[ice-breaker]

Sorry für meine paar Cents

du bist nicht zufällig Engländer und deutscht alle Posts ein?
Falls nicht: Denglisch an die MAcht, juhu

 

[php]

Wenn die Skriptausführung bei Query-Fehlern abgebrochen werden soll - ja!
Allerdings würde ich dann in die handle_error(); noch ein "echo 'Es trat ein MySQL-Fehler auf! Blablabla';" einbauen.
Außerdem muss die Funktion noch auf die Verwendung außerhalb der Klasse angepasst werden, also:

Ah und ohne ausgabe dann so:

$sql = mysql_query($query) or handle_error($query);

EDIT: Das Ergebniss

Fatal error: Using $this when not in object context in C:\Scriptes\XAMMP\xampp\htdocs\login2\include\config.php on line 48

 

[MrToiz]

Ah und ohne ausgabe dann so:

$sql = mysql_query($query) or handle_error($query);

EDIT: Das Ergebniss

Was ist denn Zeile 48?

BTW: Um wirklich keine Ausgabe zu haben, ersetze am Ende der Funktion das "echo" durch "return".

 

[php]

Zeile 48 war:

$this->_errno    = mysql_errno();

 

[ZeroCCC]

lass mal das this-> weg, dass am ende nur noch $_errno dasteht... du hast das scheinbar aus einer DB klasse raus kopiert und in eine funktion gepackt. das geht aber nicht so einfach... dazu muss der code angepasst werden. zb alles was this-> heißt muss geändert werden.

 

[DocTrax]

@ActionScripter

[..] zuerst ein SELECT und dann eine entscheidung, ob ein INSERT oder ein UPDATE verwendet werden soll (zu sehen z.b. bei doctraxs_besucher_counter von DocTrax weiter oben).
[..]
dabei gibt es doch eine mysql-anweisung, die das alles in nur einem schritt ausführt:

INSERT INTO DocTraxs_counter_{$_VAR['countertabelle']} (ip,time) VALUES ('{$_SERVER['REMOTE_ADDR']}', NOW()) ON DUPLICATE KEY UPDATE time=NOW()

Geht aber leider erst ab MySQL ab 4.1.0! Ich würde es wegen der Abwärtskompatibilität nicht nehmen.
Und es ist auch nicht ganz eindeutig. Bei dem Counter z.B. ist id die UNIQUE-Spalte und nicht die ip-Spalte. Der Grund ist einfach, der dass eine Ip dynamisch vergebn wird und nach der festgelegten Reloadsperre nochmal die selbe IP gezählt werden muss, wenn sie noch nicht gelöscht ist. In dem Fall wäre die Abfrage einfach falsch und es würde falsch gezählt.

viele tabellen sehen für eine IP ein 15-stelliges varchar-feld vor. warum??

Aus Faulheit schätze ich mal Ausser dem ist ein Script so schneller, weil es weniger Rechenzeit braucht, auch wenn es etwas mehr Speicher braucht.
Diese Umrechnung mit MySQL-Funktionen ist jedenfalls unötig nur um in der einen Spalte 30% Speicherplatz zu sparen.
Um Speicherplatz zu sparen benutze ich lieber das DELETE.

falsch:
INSERT INTO table SET field1=val1,field2=val2,field3=val3

richtig:
INSERT INTO table (field1,field2,field3) VALUES (val1,val2,val3)

die set-syntax funktioniert zwar, ist aber FALSCH und wurde nur aus kompatibilitätsgründen (historisch bedingt) zu update eingeführt.

Die "richtige" INSERT-Variante sollte man sich aber blos nicht angewöhnen. Schon alleine aus Übersichtsgründen.

* LIMIT 1 *
an jeden sicheren query gehört ein LIMIT. ganz egal, ob man etwas limitieren möchten, oder auch nicht. das hat nicht nur logische gründe, die sich auf den aufbau eines query beziehen, sondern auch rein praktische.

Macht dem Counter aber nichts - im Gegenteil: man müsste dann auch noch eine while Schleife einbauen.
Man kann das nicht so allgemein sagen.


Und noch was: Diese Posts in dem Snippets Thread gehören nicht dort hin, sondern in diesen Thread hier. Sie enthalten nämlich keine Snippets.

 

[ZeroCCC]

Geht aber leider nur ab MySQL ab 4.1.0! Und es ist nicht ganz eindeutig. Bei dem Counter z.B. ist id die UNIQUE-Spalte und nicht die ip-Spalte. Der Grund ist einfach, der dass eine Ip dynamisch vergebn wird und nach der festgelegten Reloadsperre nochmal die selbe IP gezählt werden muss, wenn sie noch nicht gelöscht ist. In dem Fall wäre die Abfrage einfach falsch und es würde falsch gezählt.

also wenn du ne relaodsperre für ein was machst, dann ist die ip schon richtig als schlüssel. wenn du mehrere reloadsperren hast musst du noch ne zusätzliche id einführen und dann bildest du aus der reloadsperren id und der ip ein schlüssel. nen extra id einführen braucht man hier nicht...

 

[ice-breaker]

Die "richtige" INSERT-Variante sollte man sich aber blos nicht angewöhnen. Schon alleine aus Übersichtsgründen.

Bullshit
Warum sollte man eine nach dem SQL-Standard syntaktisch falsche Schreibweise nutzen, die nur MySQL (noch) unterstützt (Support wird irgendwann entfernt, da schon deprecated) statt den korrekten SQL-Standard zu nutzen, den auch ALLE Datenbanken unterstützen.
Also das war doch eben mal eine komplett idiotische Aussage nur um zu legitimieren, dass du es genutzt hast ?

Macht dem Counter aber nichts - im Gegenteil: man müsste dann auch noch eine while Schleife einbauen.
Man kann das nicht so allgemein sagen.

waas?
nen while brauchst du nur, wenn du mehrere Ergebnisse bekommst, was durch LIMIT 1 nicht möglich ist.

Also irgendwie verdrehst du alle Tatsachen

 

[DocTrax]

Bullshit
Warum sollte man eine nach dem SQL-Standard syntaktisch falsche Schreibweise nutzen, die nur MySQL (noch) unterstützt (Support wird irgendwann entfernt, da schon deprecated) statt den korrekten SQL-Standard zu nutzen, den auch ALLE Datenbanken unterstützen.
Also das war doch eben mal eine komplett idiotische Aussage nur um zu legitimieren, dass du es genutzt hast ?

Bei SET sieht man sofort welcher Wert welcher Spalte zugeordnet wird und bei der anderen eben nicht so leicht. Wenn eine Tabelle entsprechend viele Spalten hat ist man mit SET eindeutig besser bedient.

waas?
nen while brauchst du nur, wenn du mehrere Ergebnisse bekommst, was durch LIMIT 1 nicht möglich ist.

Es ging um DELETE, wenn wegen des LIMIT 1 nur eines gelöscht wird, obwohl mehrere gelöscht werden sollten, dann funktiuonierte s eben nicht so wie es soll. Und wenn man nicht weiss wie viele gelöscht werden sollten nützt das LIMIT auch nix.

Also irgendwie verdrehst du alle Tatsachen

Ich sicher nicht.

 

[ice-breaker]

das ist aber kein richtiges SQL
das ist absolut dreckig zu nutzen, es gehört nicht zum SQL-Standard und wurde nur aus Kompatibilitätsgründen zu MySQL hinzugefügt (für die ganzen Leute die das net checken mit der richtigen Syntax) aber da dies noch kaum verwendet wird, wird es sicherlich irgendwann rausgeworfen.
Worüber streite ich mich eigentlich? Es ist im Prinzip ne falsche Art und fertig, und die Aussage, dass dies besser sei ist absoluter Humbug, 99.99% können net irren

 

[DocTrax]

das ist aber kein richtiges SQL
das ist absolut dreckig zu nutzen, es gehört nicht zum SQL-Standard und wurde nur aus Kompatibilitätsgründen zu MySQL hinzugefügt (für die ganzen Leute die das net checken mit der richtigen Syntax) aber da dies noch kaum verwendet wird, wird es sicherlich irgendwann rausgeworfen.

Es gibt eben keine richtige oder falsche Syntax wenn beides funktioniert.
In MySQL 5.1 ist es übrigends noch drinne.

Nun zu dem OT:

Worüber streite ich mich eigentlich? Es ist im Prinzip ne falsche Art und fertig, und die Aussage, dass dies besser sei ist absoluter Humbug,

Die Frage hast Dir ja schon selbst beantwortet: Über Dein Prinzip.

99.99% können net irren

Hohles Geschwätz - auch das Gegenteil kann stimmen.

 

[Bububoomt]

das ist aber kein richtiges SQL
das ist absolut dreckig zu nutzen, es gehört nicht zum SQL-Standard und wurde nur aus Kompatibilitätsgründen zu MySQL hinzugefügt (für die ganzen Leute die das net checken mit der richtigen Syntax) aber da dies noch kaum verwendet wird, wird es sicherlich irgendwann rausgeworfen.
Worüber streite ich mich eigentlich? Es ist im Prinzip ne falsche Art und fertig, und die Aussage, dass dies besser sei ist absoluter Humbug, 99.99% können net irren

Naja was ist schon richtig und was ist falsch, wenns unterstützt wird ist es doch nicht falsch und wenn es genutzt wird dann auch nicht (vielleicht veraltet). Eigentlich sollten Programmiersprachen so sein wie echte Sparchen, was genutzt wird sollte auch eingeführt/bebehalten werden.
Sprache lebt!

Und du willst doch nicht abstreiten das es um einiges übersichtlicher ist?
Wenn du ein update hast, was 10 Spalten hat, und du eine netfernen willst, mußt du dann natürlich erstmal teilweise abzählen, wo da nun entfernen mußt...

Da ist das mit set schon einfacher, da siehst du es halt sofort.

P.S. nun es handelt sich hierbei um mysql und nicht um sql, da gibt halt nun mal nciht nur diesen unterschied sondern viele!!

P.S. bei uns an der HS gibt es noch ne sql version da funktiniert limit 1 noch nichtmal... das sollte mal geändert werden

 

[ZeroCCC]

das ist aber kein richtiges SQL
das ist absolut dreckig zu nutzen, es gehört nicht zum SQL-Standard und wurde nur aus Kompatibilitätsgründen zu MySQL hinzugefügt (für die ganzen Leute die das net checken mit der richtigen Syntax) aber da dies noch kaum verwendet wird, wird es sicherlich irgendwann rausgeworfen.
Worüber streite ich mich eigentlich? Es ist im Prinzip ne falsche Art und fertig, und die Aussage, dass dies besser sei ist absoluter Humbug, 99.99% können net irren

seit wann ist bitte der INSERT INTO SET syntax deprecated? aber wie schonmal gesagt wenn man mit einem dbms arbeitet kann man auch dessen features nutzen! oder willst du mir erzählen das du kein auto_increment verwendest, oder limit? das sind zwei sachen die gehöhren so auch nicht zum sql standard drotzdem werden sie verwendet und darüber meckert keiner. vielleciht weiß auch keiner dass sie nicht zum sql standard gehöhren ok das sei hiermit gesagt... also noch nen grund mehr zu schreien beim nächsten query der gepostet wird. *lol*

 

[DocTrax]

also wenn du ne relaodsperre für ein was machst, dann ist die ip schon richtig als schlüssel. wenn du mehrere reloadsperren hast musst du noch ne zusätzliche id einführen und dann bildest du aus der reloadsperren id und der ip ein schlüssel. nen extra id einführen braucht man hier nicht...

Es werden Aufrufe innerhlab einer bestimmten Zeit gezält, wenn erneut geladen wird wird der Anfangszeitpunkt nach vorne verlegt. Wenn der Zeitraum überschritten ist wird wenn die selbe IP kommt wieder eine neue Zeile mit neuer ID angelegt und die alte vermutlich gelöscht, aber nicht mehr aktualisiert. Genau das macht die Abfrage von Actionscripter und ist damit falsch.

 

[ZeroCCC]

Es werden Aufrufe innerhlab einer bestimmten Zeit gezält, wenn erneut geladen wird wird der Anfangszeitpunkt nach vorne verlegt. Wenn der Zeitraum überschritten ist wird wenn die selbe IP kommt wieder eine neue Zeile mit neuer ID angelegt und die alte vermutlich gelöscht, aber nicht mehr aktualisiert. Genau das macht die Abfrage von Actionscripter und ist damit falsch.

nein macht sie nicht... sie fügt ein eintrag hinzu oder updatet das datum. den query rufst du ja nur auf wenn du einen neuen user in die reload sperre aufnehmen willst. das haut schon so hin...

 

[DocTrax]

nein macht sie nicht... sie fügt ein eintrag hinzu oder updatet das datum.

Das reicht nicht.