Textfile mit mehreren Daten, davon einmal mit Zeilenumbrüchen

[dedlfix]

echo $begrüßung;

Und mit "damit kann ich nichts anfangen" koennen wir wiederum nichts anfangen.
Wenn ich nicht verstehe, was mir das Manual sagt, kann ich nichts anderes, als dies so zu artikulieren.

Weißt du, es ist für uns™ Antwortende nicht möglich, deine Gedankengänge direkt einzusehen oder aus dem bisschen Forumskommunikation eine Analyse deines Verstehensfunktionierens solcherart zu erstellen, dass wir dir eine Anwort präsentieren können, die du unter Garantie verstehst. Ein allgemeines Nixverstehen kann man im Grunde genommen nur mit einer möglichst alles erklärenden Antwort erwidern. Dass diese recht umfangreich ausfallen würde, kannst du dir ja vorstellen. Es hat aber nicht immer jemand Lust, aus reiner Gefälligkeit den dafür notwendigen Aufwand zu betreiben. Denn das mögliche Ergebnis wäre vielleicht: "Danke, aber die Hälfte wusste ich schon." oder "Hmm, wieder nichts verstanden." oder irgendeine andere Antwort, aus der sich ergibt, dass alles oder vieles umsonst war. Die Chancen, daraufhin noch einen hilfreichen Fortgang zu erzielen, sinken nicht selten rapide, ebenso die Antwortbereitschaft bei weiteren Problemen. Das soll alles keine Kritik sein, die du ausschließlich auf dich beziehen musst und auch keine, die dich angreifen oder dergleichen soll. Ich versuche nur, dir deutlich zu machen, warum es für dich als Fragenden so wichtig ist, möglichst detailiert dein Problem zu schildern. Als Antwortender kann man dann seinen Aufwand gezielter einsetzen und es bedeutet damit auch weniger (sinnlose) Arbeit und mehr Erfolgserlebnis. Das gibts dann obendrein auch noch für den Fragenden.

Du weißt aber hoffentlich schon, daß ich nicht nur in diesem, sondern auch in meinem Posting der letzten Tage _sehr wohl_ konkrete Fragen gestellt habe und bemüht bin, zu lernen und hier _nicht_ kommenralos und ohne drüber nachzudenken einen fertiegen Code abholen möchte.

Das hat sich dann noch zu einem positiven Ergebnis entwickelt. Ich weiß nicht, was deine Motivation ist, dich mit dem Programmieren zu beschäftigen. Offensichtlich fällt es dir nicht leicht und meiner Meinung nach hast du ein großes Problem, abstrahieren zu können, eine Vorgehensweise unabhängig vom konkreten Einzelfall verallgemeinern zu können, um ihr Prinzip im nächsten konkreten Fall anwenden zu können. Dein Willen vorwärts zu kommen ist jedenfalls beeindruckend.

Und wenn du Programmieren willst, dann musst du auch mal lernen, die zugehoerigen Dokumentationen zu lesen und zu verstehen. Das ist essentiell.
Was leider, wie ich es immer wieder und wieder sage, oft daran scheitert, daß eine Dokumentation nicht automatisch gleichzusetzen ist mit "dies ist ein didaktisch gutes Lehrbuch".

Das ist ja auch nicht ihre Aufgabe. Sie muss ja auch dem Fortgeschrittenen dienen, der einfach nur mal sehen will, wie die Parameter heißen und welche Werte sie entgegennehmen. Diese Information aus einem umfangreichen Fließtext zu extrahieren ist zu aufwendig.

Es ist nun mal leider so, daß dort Dinge oft so kurz zusammengefaßt sind oder in so einem Technik-Sprech erklärt werden, daß es der "Laie" einfach nicht verstehen _kann_.

Weil das so ist, hat man ja die Tutorials erfunden, die sich mehr Zeit für ein Thema nehmen können. Allerdings ist da der Kompromiss, dass sie dies nicht für jedes spezielle Thema in ausführlichster Form machen können.

Was stört dich den konkret an so einer Handbuchseite, vielleicht am Beispiel von fgetcsv() oder fputcsv()?

Themenwechsel. Versuchen wir™ mal mit diesem Problem weiter zu kommen.

[Datenbankabfrage, die] kein Ergebnis bring? Es kommt weder 0, noch eine Fehlermeldung oder Warnung. Im Quelltext steht dann einfach "<p>es sind  Datensätze vorhanden.</p><hr />" Wo liegt denn da mein Fehler?

Es fehlt dir anscheinend auch noch das Wissen um Debuggingstrategien. Wichtig ist immer, Wunsch und Wirklichkeit miteinander zu vergleichen. Das bedeutet, dass man Kontrollausgaben macht. Unter PHP ist dafür das beste Mittel die Funktion var_dump() (abgesehen von IDEs mit integriertem Debugger). Außerdem kommt da das Handbuch mit ins Spiel. Viele Funktionen, besonders aus dem Datenbankumfeld, liefern neben dem gewünschten Ergebnis im Fehlerfall ein anderes zurück. Wie das konkret aussieht musst du dem Handbuch entnehmen. Hinzu kommt noch, dass die Datenbankfunktionen ihre Fehler nicht an die große Glocke hängen und per Meldung an die Front werfen.

Angenommen das $db->prepare() hätte was zu melden gehabt. Das Handbuch sagt unter Return Values: returns a statement object or FALSE if an error occured. Mit var_dump() kann man sich das Ergebnis, das du einer Variablen zugewiesen hast, anzeigen lassen. Du siehst dabei sowohl, ob es ein statement object ist als auch, wenn es ein false ist. Mit einem echo siehst du das false nicht, weil das als Leerstring ausgegeben wird. Die konkrete Meldung im false-Fall musst du hier mit $db->error abholen. Diese Eigenschaft (Objektvariable) kannst du mit echo ausgeben.

Das hilft dir zwar jetzt beim Entwickeln, aber wenn alles fertig ist, soll die Anwendung einerseits robust sein und andererseits den Anwender nicht mit Interna behelligen, mit denen er sowieso nichts anfangen kann. Der Rückgabewert muss also gegen das false geprüft werden und dann mit einer Alternative im Fehlerfall fortgefahren werden. Ansonsten geht es mit der Datenabfrage weiter.

Dieses Prinzip solltest du überall anwenden. Ich fasse es nochmal zusammen:

1. Informationsbeschaffung: Was liefert mir eine Funktion im Gut- und was im Fehlerfall?
2. Programmcode: Prüfen des Ergebnisses auf den Fehlerwert und Alternativprogramm fahren
3. Ansonsten normal fortfahren, dabei mit der nächsten Funktion wieder bei 1 anfangen.

Und nicht nur die Funktionen liefern Unerwartetes, auch die Variablen enthalten mitunter solches. Auch da hilft eine Kontrollausgabe.

Was du auch noch beachten musst, sind einige PHP-Besonderheiten und womöglich noch konkrete Konfigurationseinstellungen (konkret: deaktivierte Fehlermeldungsausgabe). Es gibt Situationen, die PHP als nicht nennenswert einstuft, dir als Programmierer aber dennoch nicht gefallen. Lesezugriffe auf nicht vorhandene Variablen sind ein Beispiel dafür und Vertipper beim Variablennamen eine nicht seltene Ursache. Um PHP gesprächig zu machen sollte beim Entwickeln stets das error_reporting auf E_ALL stehen (und display_errors auf on). Am besten setzt man das auf der Entwicklungsmaschine in der Konfiguration des Projektverzeichnisses. (Die php.ini ist nicht immer ein gescheiter Ort, besonders wenn man Programme anderer ausführen will, die sich keinen Kopf um die Grundinitialisierung ihrer Variablen gemacht haben.)

Ich habe jetzt jede Menge Allgemeines geschrieben und weniger auf deine Situation bezogenes. Leider ist mir viel anderes (noch) nicht möglich, denn ohne deine Variableninhalte und Funktionsergebnisse zu kennen, gibt es zu viele Möglichkeiten, was die Ursache sein kann. Deshalb musst du erstmal selbst weitermachen und mit den Kontrollausgaben weitere Informationen sammeln. Dafür kann ich dir allerdings konkrete Beispiele geben:

$abfrage = 'SELECT COUNT(003\_id) FROM dbtest003';

Das ist eindeutig. Eine Kontrollausgabe lohnt sich da eigentlich nicht. Schaden kann sie aber nicht.

$abfrageergebnis = $db->prepare( $abfrage );

var_dump($abfrageergebnis);

$abfrageergebnis->execute();
$abfrageergebnis->bind_result( $anzahl);

Bei beiden Funktionen können Fehler auftreten. Werte deren Ergebnis aus.

echo"<p>es sind ".$anzahl." Datensätze vorhanden.</p><hr />\n";

var_dump($anzahl); gibt auf alle Fälle was aus, und sei es nur ein NULL. Daraus kann man schließen, dass die Variable nicht angelegt wurde. Die Ursache wird im vorhergehenden Programmablauf zu finden sein.

abfrageergebnis->store_result();

Da fehlt ein $, hoffentlich nur ein Copy'n'Paste-Fehler. Wenn nicht, gibt dir PHP eine Meldung aus, wenn es nicht zum Schweigen konfiguriert wurde.

echo "$verabschiedung $name";