SQL + PHP
Martin
- datenbank
0 Geistiger Hohlraum0 Martin0 Fabian St.
0 Tom0 Badboy46
Hallo,
ich hab hier eine Abfrage,
$abfrage1 = "SELECT interpret FROM interpreten";
$ergebnis1 = mysql_query($abfrage1);
while($row = mysql_fetch_object($ergebnis1))
$dbinterpret = $row->interpret;
echo "<td><p><select name='album' size="1">";
echo "<option>";
echo $dbinterpret;
echo "<br>";
echo "</option>";
echo "</select></p>";
Das ganze soll dann als Dropdown Menü zur Auswahl stehen.
Dachte eigentlich, das es mit einer while Schleife klappt. Aber anscheinend durchläuft er alle Einträge aus der DB und nimmt dann nur noch den letzten.
while($row = mysql_fetch_object($ergebnis1))
$dbinterpret = $row->interpret;echo "<td><p><select name='album' size="1">";
echo "<option>";
Dachte eigentlich, das es mit einer while Schleife klappt. Aber anscheinend durchläuft er alle Einträge aus der DB und nimmt dann nur noch den letzten.
Dann überlege Dir mal, wo die Schleife anfängt und ganz besonders, wo sie aufhört.
Dann überlege Dir mal, wo die Schleife anfängt und ganz besonders, wo sie aufhört.
Hilft mir jetzt nicht so weiter,
da die Ausgabe von
$row->interpret; ja alles was in der DB ist zurückgibt. Aber gut muß ich weiterschauen...
Hi!
Hilft mir jetzt nicht so weiter,
da die Ausgabe von
$row->interpret; ja alles was in der DB ist zurückgibt. Aber gut muß ich weiterschauen...
Doch, das sollte dir schon weiterhelfen:
echo "<td><p><select name='album' size="1">";
while($row = mysql_fetch_object($ergebnis1))
{ # Du hast diese Klammer vegessen
$dbinterpret = $row->interpret;
echo "<option>";
echo $dbinterpret;
echo "</option>";
} # und auch diese!
echo "</select></p>";
Grüße,
Fabian St.
Hallo Fabian,
danke für deine schnelle Hilfe. Oft sieht man wohl den Wald vor lauter Bäumen nicht mehr. Jetzt klappts auch. Danke nochmal
Hallo,
Hilft mir jetzt nicht so weiter,
da die Ausgabe von
$row->interpret; ja alles was in der DB ist zurückgibt. Aber gut muß ich weiterschauen...
Doch, das sollte dir schon weiterhelfen:
echo "<td><p><select name='album' size="1">";
while($row = mysql_fetch_object($ergebnis1))
{ # Du hast diese Klammer vegessen
$dbinterpret = $row->interpret;
echo "<option>";
echo $dbinterpret;
echo "</option>";
} # und auch diese!echo "</select></p>";
müsste es nicht
$abfrage1 = 'SELECT interpret FROM interpreten';
$ergebnis1 = mysql_query($abfrage1);
$dbinterpret = '';
while($row = mysql_fetch_object($ergebnis1))
$dbinterpret .= '<option>'.$row->interpret.'</option>'."\n";
echo '<td><p><select name="album" size="1">'."\n";
echo $dbinterpret;
echo '</select></p>'."\n";
lauten?
Hello,
echo "<td><p><select name='album' size="1">";
while($row = mysql_fetch_object($ergebnis1))
{ # Du hast diese Klammer vegessen
$dbinterpret = $row->interpret;
echo "<option>";
echo $dbinterpret;
echo "</option>";
} # und auch diese!echo "</select></p>";
müsste es nicht
$abfrage1 = 'SELECT interpret FROM interpreten';
$ergebnis1 = mysql_query($abfrage1);
$dbinterpret = '';
while($row = mysql_fetch_object($ergebnis1))
$dbinterpret .= '<option>'.$row->interpret.'</option>'."\n";echo '<td><p><select name="album" size="1">'."\n";
echo $dbinterpret;
echo '</select></p>'."\n";lauten?
Ja!
Das müsste so lauten. Und wenn ich den Thread bis zum Ende gelesen hätte vor meinem Posting, dann hätte ich mir das auch sparen können, denn DU hast ja sogar an die Initialisierung des in der Schleife benutzten Wertes $dbinterpret gedacht. Dafür bekommst Du (zumindest von mir) 10 von 10 Punkten.
Und Außerdem hast Du an die resultierende Zeilenlänge im Browser gedacht (\n). Die darf nämlich offiziell 1000 Zeichen inclusive Zeilenumbruch nicht überschreiten. Eigentlich müsste es ja auch (\r\n) heißen, aber das sehe ich auch immer nicht so eng.
Harzliche Grüße aus http://www.annerschbarrich.de
Tom
Hallo,
[...]
Und wenn ich den Thread bis zum Ende gelesen hätte vor meinem Posting, dann hätte ich mir das auch sparen können, denn DU hast ja sogar an die Initialisierung des in der Schleife benutzten Wertes $dbinterpret gedacht.
$dbinterpret = ''; hatte ich mal vor geraumer Zeit vergessen und bekam eine schöne Fehlermeldung...
so ein fehler macht man nur einmal *g*
Dafür bekommst Du (zumindest von mir) 10 von 10 Punkten.
fein ;-)
Und Außerdem hast Du an die resultierende Zeilenlänge im Browser gedacht (\n). Die darf nämlich offiziell 1000 Zeichen inclusive Zeilenumbruch nicht überschreiten.
das wusste ich noch nicht, dass es nur 1000 Zeichen sein dürfen
Eigentlich müsste es ja auch (\r\n) heißen, aber das sehe ich auch immer nicht so eng.
wenn ich mir das dann aber mit einigen Editoren anschaue,
hab ich dann immer eine Leerzeile...
wenn ich nur \n verwende nicht
Und Außerdem hast Du an die resultierende Zeilenlänge im Browser gedacht (\n). Die darf nämlich offiziell 1000 Zeichen inclusive Zeilenumbruch nicht überschreiten.
Wo steht denn das geschrieben? In http://www.w3.org/TR/html4/ konnte ich auf die Schnelle nichts dazu finden.
Eigentlich müsste es ja auch (\r\n) heißen, aber das sehe ich auch immer nicht so eng.
Und das halte ich nun wirklich für ein Gerücht (es geht hier um HTML, nicht HTTP).
ASCII-Wagenrücklauf und -Zeilenvorschub sind in HTML lediglich Leerzeichen ohne jegliche weitere Bedeutung (mit der Ausnahme vorformatierten Textes). Eine Begrenzung der Zeilenlänge mag sinnvoll sein, dass \r\n vorgeschrieben ist, kann ich mir hingegen nicht vorstellen.
Hello,
Und Außerdem hast Du an die resultierende Zeilenlänge im Browser gedacht (\n). Die darf nämlich offiziell 1000 Zeichen inclusive Zeilenumbruch nicht überschreiten.
Wo steht denn das geschrieben? In http://www.w3.org/TR/html4/ konnte ich auf die Schnelle nichts dazu finden.
Eigentlich müsste es ja auch (\r\n) heißen, aber das sehe ich auch immer nicht so eng.
Und das halte ich nun wirklich für ein Gerücht (es geht hier um HTML, nicht HTTP).
ASCII-Wagenrücklauf und -Zeilenvorschub sind in HTML lediglich Leerzeichen ohne jegliche weitere Bedeutung (mit der Ausnahme vorformatierten Textes). Eine Begrenzung der Zeilenlänge mag sinnvoll sein, dass \r\n vorgeschrieben ist, kann ich mir hingegen nicht vorstellen.
stell Dir vor, was Dein Hohlraum zulässt *gg*
Das Thema hatten wir hier jedenfalls schon öfter und selbst einige extrem Fortgeschrittene mussten nachher einsehen, dass das die offiziellen Aussagen sind. Ich habs mir dann halt nur gemerkt, denn warum soll ich Fehler Anderer Wiederholen, wenn sie doch so ehrlich waren und diese als Fehler erkannt und beschrieben haben?
Harzliche Grüße aus http://www.annerschbarrich.de
Tom
Hallo,
Das Thema hatten wir hier jedenfalls schon öfter und selbst einige extrem Fortgeschrittene mussten nachher einsehen, dass das die offiziellen Aussagen sind. Ich habs mir dann halt nur gemerkt, denn warum soll ich Fehler Anderer Wiederholen, wenn sie doch so ehrlich waren und diese als Fehler erkannt und beschrieben haben?
Du irrst Dich. Es gibt keine Vorschrift, dass in einem HTML-Dokument überhaupt ein \n, \r bzw. \r\n vorkommen muss. Interpretiert werden ohnehin nur Tags. Für den HTML Parser ist \n, \r oder \r\n einfach white-space. http://www.w3.org/TR/html4/struct/text.html#line-breaks
Was Du meinst ist die maximale Länge eines URI. Die ist zwar theoretisch auch unbegrenzt, wird aber von vielen Browsern nicht unbegrenzt akzeptiert.
Nur in HTTP ist CRLF vorgeschrieben z.B. als Abschluss von Request-Line. http://www.w3.org/Protocols/rfc2616/rfc2616-sec5.html#sec5.1
viele Grüße
Axel
Hello,
Du irrst Dich. Es gibt keine Vorschrift, dass in einem HTML-Dokument überhaupt ein \n, \r bzw. \r\n vorkommen muss. Interpretiert werden ohnehin nur Tags. Für den HTML Parser ist \n, \r oder \r\n einfach white-space. http://www.w3.org/TR/html4/struct/text.html#line-breaks
Was Du meinst ist die maximale Länge eines URI. Die ist zwar theoretisch auch unbegrenzt, wird aber von vielen Browsern nicht unbegrenzt akzeptiert.
Nein. URIs meine ich nicht.
Nur in HTTP ist CRLF vorgeschrieben z.B. als Abschluss von Request-Line. http://www.w3.org/Protocols/rfc2616/rfc2616-sec5.html#sec5.1
Es gibt keine "HTML-Dokumente", die unter normalen Request-Response Bedingungen an den Browser ausgeliefert werdern, sondern nur HTTP Streams. Diese können natüelich dann im Body die "HTML-Dokumente" enthalten.
Für den HTTP-Stream gilt aber, dass er spätestens innerhalb aller 1000 Zeichen einen definierten "Zeilenumbruch" enthalten muss. Das HTTP-Protokoll ist ein zeilenorientiertes Textformat.
Ob da jetzt "\n" oder "\r\n" im Body benutzt werden muss, darum streite ich mich (heute) nicht.
Wenn man hier im Archiv sucht, findet man auch noch die RFC, aus der eindeutig die maximale Zeilenlänge hervorgeht.
Das gilt übrigens einheitlich für eMails und für HTTP-Files.
Harzliche Grüße aus http://www.annerschbarrich.de
Tom
Hallo,
Für den HTTP-Stream gilt aber, dass er spätestens innerhalb aller 1000 Zeichen einen definierten "Zeilenumbruch" enthalten muss.
Nein.
Response:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec6.html#sec6
message-body, entity-body:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec7.html#sec7.2
OCTET:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec2.html#sec2.2
Das HTTP-Protokoll ist ein zeilenorientiertes Textformat.
Nein.
http://www.w3.org/Protocols/rfc2616/rfc2616-sec1.html#sec1
viele Grüße
Axel
Hello,
http://www.w3.org/Protocols/rfc2616/rfc2616-sec6.html#sec6
http://www.w3.org/Protocols/rfc2616/rfc2616-sec7.html#sec7.2
http://www.w3.org/Protocols/rfc2616/rfc2616-sec2.html#sec2.2
http://www.w3.org/Protocols/rfc2616/rfc2616-sec1.html#sec1
genauso haben wir und da schon einmal rangehangelt. Dann sagte einer 2822 (und nicht JEHOVA) und ein Posting ergab das andere. Und plötzlich stand da auf dem Schirm, dass das, was für mailbodies gilt, auch für "normale" HTTP-Responses gilt, natürlich als Zitat aus einer RFC.
Wenn ich mir den Thread doch nur bookmarked hätte!
Harzliche Grüße aus http://www.annerschbarrich.de
Tom
Hallo,
genauso haben wir und da schon einmal rangehangelt. Dann sagte einer 2822 (und nicht JEHOVA) und ein Posting ergab das andere.
Ja, für 7-bit-US-ASCII-Text-Messages mag das gelten (gegolten haben). HTTP-Bodys sind aber nun mal ausdrücklich *OCTET und _nicht_ US-ASCII und auch nicht 8-bit-Text. Wie sollte sonst UTF-8 transportiert werden können?
viele Grüße
Axel
genauso haben wir und da schon einmal rangehangelt. Dann sagte einer 2822 (und nicht JEHOVA) und ein Posting ergab das andere.
Ja, für 7-bit-US-ASCII-Text-Messages mag das gelten (gegolten haben). HTTP-Bodys sind aber nun mal ausdrücklich *OCTET und _nicht_ US-ASCII und auch nicht 8-bit-Text.
Zeilenumbruch:
Die MIME-Spezifikation RFC 2046 4.1 verlangt von text/*-Typen CRLF als Zeilenumbruch. Dies ist im Speziellen auch noch in RFC 2854 für text/html angegeben, allerdings gleich mit dem Hinweis auf eine Ausnahmeregelung, die bei HTTP in RFC 2616 3.7.1 angegeben ist: "HTTP relaxes this requirement and allows the transport of text media with plain CR or LF alone representing a line break".
Unterm Strich ist es also egal. Niemand wird ernsthaft einen Unterschied zwischen per HTTP empfangenen und zum Beispiel von der Festplatte gelesenen HTML-Dateien machen, zumal HTML selbst kein Zeilenendformat definiert. Die ganze Geschichte musste wohl in gewisser Hinsicht zwangsweise wegen MIME hintenrum auf HTML aufgeladen werden.
Zeilenlänge:
Die Zeilenlänge ist für text/, für text/html, für HTML und erst recht nicht für HTTP festgelegt. Gerade bei HTTP wäre so etwas kontraproduktiv, wie sollten sonst Binärdateien (bekanntermaßen ohne Kodierungen wie base64 oder uu) transportiert werden.
Die Begrenzung auf 998 Zeichen + CRLF gibt es nur für Nachrichten im Internet Message Format (Hauptanwendung: email) gemäß RFC 2822. HTTP bezieht sich auf den Vorgänger von RFC 2822, RFC 822, dort allerdings ausschließlich auf Abschnitt 3.1, der sich lediglich allgemein mit dem Nachrichtenkopf befasst, nicht mit dem Nachrichtenkörper, um den es bei HTML gehen müsste. Und obwohl man RFC 822 als durch RFC 2822 ersetzt ansehen kann, wäre kurioserweise anzumerken, dass in RFC 822 generell überhaupt keine Rede von einer begrenzten Zeilenlänge ist (nur eine Empfehlung von 72 Zeichen zur besseren Lesbarkeit)
So, und nun möge man mir das Gegenteil mit Textnachweisen darlegen, ein "ich habe mal gehört" reicht mir nicht.
Hallo,
Zeilenlänge:
Die Zeilenlänge ist für text/, für text/html, für HTML und erst recht nicht für HTTP festgelegt. Gerade bei HTTP wäre so etwas kontraproduktiv, wie sollten sonst Binärdateien (bekanntermaßen ohne Kodierungen wie base64 oder uu) transportiert werden.
Schlechtes Beispiel. Die haben einen anderen Content-type. Deshalb habe ich angemerkt, dass es bei der von Tom geforderten Begrenzung auf 1000 OCTETs schon schwierig wäre Unicode zu transportieren. Da sind das nämlich weniger als 998 Zeichen + CRLF.
Die Begrenzung auf 998 Zeichen + CRLF gibt es nur für Nachrichten im Internet Message Format (Hauptanwendung: email) gemäß RFC 2822.
Ja, und zwar, weil SMTP das so erfordert. http://www.faqs.org/rfcs/rfc2821.html
text line
The maximum total length of a text line including the <CRLF> is
1000 characters (not counting the leading dot duplicated for
transparency). This number may be increased by the use of SMTP
Service Extensions.
Deshalb muss man _bei SMTP_, _nicht_ bei HTTP, non-textual data in "seven-bit bytes representable as printable US-ASCII characters" umwandeln. http://www.faqs.org/rfcs/rfc2045.html (1. Introduction)
viele Grüße
Axel
Hello,
echo "<td><p><select name='album' size="1">";
while($row = mysql_fetch_object($ergebnis1))
{ # Du hast diese Klammer vegessen
$dbinterpret = $row->interpret;
echo "<option>";
echo $dbinterpret;
echo "</option>";
} # und auch diese!
Das ist hässlich!
EVA-Prinzip nicht eingehalten!
echo "</select></p>";
Harzliche Grüße aus http://www.annerschbarrich.de
Tom
Hi!
Das ist hässlich!
EVA-Prinzip nicht eingehalten!
Verzeih mir bitte ;-)
Arbeite noch nicht so lange wie du mit PHP.
Grüße,
Fabian St.
Hello,
Hallo,
ich hab hier eine Abfrage,
$abfrage1 = "SELECT interpret FROM interpreten";
$ergebnis1 = mysql_query($abfrage1);
$dbinterpret ="";
while($row = mysql_fetch_object($ergebnis1))
{
$dbinterpret .= " <option>".$row->interpret."</option>\n";
}
echo "<td><select name='album' size="1">\n";
echo $dbinterpret;
echo "</select></td>\n";
Und was passiert jetzt?
Harzliche Grüße aus http://www.annerschbarrich.de
Tom
Hallo,
[...]
Und was passiert jetzt?
das hatte ich auch schon vor 10min geschrieben ;-)