[mySQL&php]Bestimmte Zeilen ab beliebigem Einsprungspunkt ausgeben

[Lagerhaus_Jonny]

Hi Leute, ich habe mal ein kleines PHP-Problem,
zu dem mir bislang noch nicht die zündende Idee gekommen ist.

Und zwar habe ich auf einer PHP-Seite 2 dynamische Tabellen(mySQL) dargestellt.
In jedem ersten Datenfeld der beiden Tabellen befindet sich ein Link auf dessen Klick ein Popup öffnet, das weitere Details zum Datensatz liefern soll, dessen Link geklickt wurde.
Den einen Datensatz zu holen ist kein wirkliches Problem, jedoch:
Ich möchte in das Popup Buttons plazieren, die das weitere durchgehen der Tabellen ermöglichen, also nächster oder vorheriger Datensatz.
Nur wie realisiere ich das ?
Zum einen sind die Tabellen sortiert und zum anderen weiß ich gerade nicht, wie ich an eine bestimmte Stelle innerhalb einer Tabelle springe und von da aus dann linear weiter durchgehen kann.
Mir kamen da so Funktionen wie mysql_num_rows oder fetch_assoc in den Sinn, nur konnte ich daraus nichts sinnvolles basteln.
Ich kann ja auch keine Resource IDs an eine weitere Seite übergeben, die den Query gar nicht ausgeführt hat.. alles etwas schwierig für mich.

Ich sitze allerdings jetzt schon seit 7 Uhr an PHP, JavaScript und SQL von daher brennt mir ein wenig die Birne ^^

Wenn jemand einen heißen Tipp hat, bin ich dankbar.

Ach ich sollte noch erwähnen, das es in meinen Tabellen kein Feld "id" gibt.
Das könnte sich auf eure Lösungsvorschläge auswirken

 

[ein schlauer]

Du musst doch irgendein Kriterium haben mit dem du den Eintrag auswählst?

 

[ZeitGeist]

Du musst sowas wie eine ID haben, sonst könntest du ja keine Details zum Datensatz ausgeben. Oder übergibst du diese an das PopUp? Wenn ja solltest du schleunigst mal eine ID einfügen, sonst wirst du später auch Probleme beim Ändern der Daten haben.

Vor und Zurück in dem PopUp sind recht einfach zu implementieren. Du mußt in dem PopUp nur die Sortierung kennen (falls die vom Benutzer änderbar ist).
Den Datensatz für den Vor-Button erhälst du in dem du folgende SQL Anfrage durchführts

SELECT * FROM `tabelle` 
WHERE `spalte_sorted` >=
(SELECT `spalte_sorted` FROM `tabelle` WHERE `deine_id`=ID)
ORDER BY `spalte_sorted` ASC
LIMIT 1

Wobei spalte_sorted die Spalte ist nach der du sortierst und ID die Id des aktuellen Datensatzes. Wenn du mehrere Spalten hast nach den du sortierst musst du diese mit einem AND in die WHERE-Bedingung hängen. Für zurück brauchst du ein <= und ein DESC statt dem ASC.

 

[Lagerhaus_Jonny]

Jup.
Ich habe mit ziemlich genau 0 Php und 0 MySQL Kenntnissen angefangen,
darum gabs in meiner Datenbank kein autoinkrementiertes Feld "ID".
Das hab ich einfach damals einfach nicht eingesehen, sowas da reinzumachen, weil ich den nutzen nicht erkannte.

Glücklicherweise ist das ganze kein Genickbruch, da ich dafür ein anderes Feld habe, das immer einen einzigartigen Wert besitzt.
Meistens habe ich sogar 2 eindeutige Felder.
Problem ist nur, das deren Werte nicht vorhersehbar sind, so wie autoinkrementierte Werte.
Darum kann ich nicht einfach $i++ sagen um den nächsten Datensatz zu erhalten.
An der Stelle rächt sich das.
Aber gut.. ich werds trotzdem irgendwie hinkriegen.

Was du da mit ASC und DESC geschrieben hattest, hat mir weitergeholfen und mir ein paar Denkansätze gegeben.

Zur Not kann ich natürlich auch das Feld "ID" noch einfügen, allerdings müsste ich danach dann ~15 PHP-Dokumente nochmal stark anpassen, worauf ich nicht so große Lust habe ^^
Darum versuche ich erstmal weiterhin ohne ID auszukommen.

Dankö erstmal.

 

[Albu]

Darum kann ich nicht einfach $i++ sagen um den nächsten Datensatz zu erhalten.
An der Stelle rächt sich das.

Das kannst Du auch bei einem Autoinkrement-Feld nicht unbedingt, es sei denn Du löscht nie Datensätze aus der Tabelle. Was in der Praxis eher unwahrscheinlich ist.

Ansonsten braucht man auch nicht unbedingt ein Feld mit Namen ID (oder beliebiger anderer Name) und es muss auch kein Autoinkrement sein, solange man einen eindeutigen Primärschlüssel hat. Dieser kann aus einer Kombination von mehreren Spalten bestehen. Es kann z.B. auch ein Textfeld sein.
Es zeigt sich nur speziell in der Webprogrammierung, dass es ganz praktisch ist, mit IDs zu arbeiten. Denn als Zahlen sind sie sehr handlich und wenn z.B. ein Eintrag aus einer großen Liste / Tabelle bearbeitet oder gelöscht werden soll, so übergibt der Browser lediglich die ID des gewählten Eintrages. Natürlich funktioniert dies auch mit einem Textfeld, aber wenn es sich um einen zusammengesetzten Schlüssel handelt, dann müssen bei jeder Aktion mehrere Werte (einer pro Spalte des Primärschlüssels) übergeben werden, was die Komplexität erhöht.

Als Lektüre wäre sicherlich irgendwas über Datenbankdesign, mit den verschiedenen Schlüsseltypen, Normalformen und andere Schweinereien.

 

[Lagerhaus_Jonny]

Was Primärschlüssel und Normalformen etc. angeht: da weiß ich bescheid.
Meine Datenbank braucht jedenfalls nicht normalisiert zu werden.
Ich habe gewisse Kontrollmechanismen, sodass keine Inkonsistenzen auftreten sollten.

Einen eindeutigen Primärschlüssel habe ich, wie gesagt.
Werde mal schauen, wie ich das umsetzen kann.

 

[Lagerhaus_Jonny]

Problem Gestern nach viel bastelei gelöst.
Funktionierte überhaupt nicht so, wie hier vorgeschlagen ^^
Das dachte ich mir aber schon.

Das Hauptproblem ist, das ich 2 Querys ausführe, die zwei Tabellen miteinander vergleichen.
Das Ergebnis und die Sortierung sind aber nicht vorhersehbar.

Ich habs jetzt so gemacht:

<?
Mysql-Connection und bla...
....
$nodename = $_GET["name"];
$ip = $_GET["ip"];
$table = $_GET["table"];
$id = $_GET["id"];
$action = $_GET["action"];
$z = $_GET["z"];
$gesamt=$_GET["gesamt"];
if($action == "weiter")
{$z = $z+1;}
if($action == "back")
{$z = $z-1;}
$i=0;
$y=0;

//Debugging----------//
echo "$nodename<br>";
echo "$ip<br>";
echo "$table<br>";
echo "$action<br>";
//-------------------//

if($id == "1")
	{
	$get_name = mysql_query("bla bla");
	while ($name = mysql_fetch_array($get_name))
		{
		$tmp_name = $name['nodename'];
		$tmp_ip = $name['ip'];
		$suche_name = mysql_query("bla bla");
		$row = mysql_fetch_array($suche_name);
		if(count($row) == 1)
			{
			$y++;
			if (($action == "weiter") || ($action == ""))
				{
				$i++;
				if ($z >= $gesamt)
					{
					$i = 1;
					$z = 1;
					}
				if ($i == $z)
					{
					echo "$i-->$z-->";
					echo $tmp_name;
					}
				}
			if ($action == "back")
				{
				$i++;
				if ($z <= 0)
					{
					$z = $gesamt;
					}
				if ($i == $z)
					{
					echo "$i-->$z-->";
					echo $tmp_name;
					}
				}
			
			}
		}
	}
$gesamt = $i;
echo "<br>i=$i<br>";
echo "z=$z<br>";
echo "</form>"."\n";
echo "<form action='infobox.php' method='get'><input type='submit' value='zurück'>"."\n";
echo "<input type='hidden' name='action' value='back'>"."\n";
echo "<input type='hidden' name='name' value='$nodename'>"."\n";
echo "<input type='hidden' name='ip' value='$ip'>"."\n";
echo "<input type='hidden' name='table' value='$table'>"."\n";
echo "<input type='hidden' name='id' value='$id'>"."\n";
echo "<input type='hidden' name='z' value='$z'>"."\n";
echo "<input type='hidden' name='gesamt' value='$gesamt'>"."\n";
echo "</form>"."\n";
echo " "."\n";
echo "<form action='infobox.php' method='get'><input type='submit' name='action' value='weiter'>"."\n";
echo "<input type='hidden' name='name' value='$nodename'>"."\n";
echo "<input type='hidden' name='ip' value='$ip'>"."\n";
echo "<input type='hidden' name='table' value='$table'>"."\n";
echo "<input type='hidden' name='id' value='$id'>"."\n";
echo "<input type='hidden' name='z' value='$z'>"."\n";
echo "<input type='hidden' name='gesamt' value='$gesamt'>"."\n";
echo "</form>"."\n";
?>

Zur Erläuterung:
die übergebene ID ganz oben ist keine ID eines Datensatzes, sondern einfach ein Wert mit dem ich die Hälfte der Tabelle bestimme.
Die Hauptseite besteht nämlich aus einer Tabelle mit 4 Feldern, die aber eigentlich zwei Tabelle mit jeweils zwei Feldern ist.
Die beiden Querys die dort ausgeführt werden müssen, sind abhängig von der Tabelle, dessen Datensatz ich mir anzeigen lassen möchte.
Daher entweder ID=1 oder 2.
Darum auch die IF-Anweisung: if($id == "1")
Variable "z" ist die Summe der Datensätze, die in der Tabelle auf der Seite ID angezeigt werden und ist grundlegend für meinen Lösungsweg.

Ich führe praktisch die kompletten Querys der Hauptseite für die jeweilige Tabelle nochmal aus und nummeriere die Ergebnisse mit Hilfe von i.
z ist dabei mein Index von der Hauptseite, an dem ich mich orientieren kann.

Das praktische war, das ich auf der Hauptseite in jedem Datensatz einen Link gemacht habe, durch den man auf obige Seite kommt (wird einfach dazu da sein um erweiterte Informationen zum Datensatz anzuzeigen).
Den Datensatz anzuzeigen, dessen Link man geklickt hat war von vorne herein kein Problem und der durchaus positive Effekt war, das so immer einmal die komplette PHP durchlaufen ist und alle Variablen gefüllt sind.
Alle nötigen Variablen konnte ich so an die php selbst weitergeben.
Das war ganz wichtig für die Fälle wenn man a) beim 1. Datensatz auf den Zurück-Button klickt und b) beim letzten Datensatz nochmals auf "weiter" klickt.
Hier wollte ich natürlich in Fall a) ans Ende der Datensätze (also vom 1. auf den letzten) und in Fall b) vom letzten auf den ersten Datensatz springen.
Ohne die gefüllte Variable i klappte das aber nicht.

Ich hoffe ich konnte es ein bischen erklären.
Wenn nicht, auch nicht so schlimm, solange ihr nicht mal vor dem gleichen Problem steht ^^
Wobei es ja eh immer mehrere Lösungen gibt.

 

[ein schlauer]

Also mir erscheint deine Fragestellung so, also ob du dich mal intensiver mit sql auseinandersetzen solltest. Du hast ja schon die Abfragen aus deinem Code entfernt. Aber eine Abfrage in einer Schleife deutet daraufhin, dass du einen join machen willst.

 

[Albu]

Irgendwie kommt mir das vor, als würde ich nur die Hälfte von dem verstehen, was Du vorhast. Du hast zwar lang und breit irgendwas erklärt, aber das macht einen ziemlich konfusen Eindruck.

Bestärkt wird dies durch die Aussage:

Das Ergebnis und die Sortierung sind aber nicht vorhersehbar.

Die im krassen Gegensatz zu Deiner zuvor getroffenen Entscheidung gegen Normalisierung steht:

Was Primärschlüssel und Normalformen etc. angeht: da weiß ich bescheid.
Meine Datenbank braucht jedenfalls nicht normalisiert zu werden.
Ich habe gewisse Kontrollmechanismen, sodass keine Inkonsistenzen auftreten sollten.

Wie kann es denn angehen, dass das Ergebnis und / oder Sortierung chaotisch sin, wenn das Datenmodell in Ordnung ist?
Du solltest echt mal einen Schritt zurücktreten und mal kritisch hinterfragen, was Du da eigentlich machst, und ob es nicht eine bessere Möglichkeit gibt. Das ist eventuell damit verbunden, dass Du das Datenmodell ändern musst. Wenn dadurch das Handling leichter, überschaubarer, performanter und für Dritte begreifbarer wird, dann ist der Aufwand 15 PHP Dokumente deswegen überarbeiten zu müssen, eher gering - zumal es ja eh noch nicht funktioniert (Bei 150 Dokumenten würde man sich das schon eher zweimal überlegen, aber bei 15?! Das ist ja lächerlich wenig.)

Das war jetzt eine Langfassung von dem, was "ein schlauer" gesagt hat.

 

[Lagerhaus_Jonny]

Ja, ich glaube das ganze hätte man auch mittels eines Joins machen können, ist schon richtig.
Wäre aber im Grunde nur ein anderer Lösungsweg gewesen und nicht so viel einfacher vom Aufwand her.
Die Querys zu basteln und so auszuführen, das ich das gewünschte Ergebnis erhalte war keine Schwierigkeit.
Der Aufwand liegt in der Darstellung, die bestimmte Anforderungen erfüllen muss.
Statt 4 Querys hätte ich dann 2 Joins ausgeführt.. das hätte den Code wohl etwas vereinfacht, mehr aber auch nicht.

Die im krassen Gegensatz zu Deiner zuvor getroffenen Entscheidung gegen Normalisierung steht:[...]

Wenn ich das Ergebniss nicht kenne, weiß ich auch nicht ob nach A ein B kommt, vielleicht gibts ja im Ergebnis gar kein B ?
Wie soll ich dann die Sortierung vorhersehen ?
Vermutlich verwende ich als jemand, der solche Begriffe nicht in dem starren AE'ler-Rahmen hält einfach anders.
Ich weiß selbstverständlich, das die Darstellung am Ende alphabetisch sortiert sein wird.
Mehr aber auch nicht, daher ist es für mein Verständnis so, das ich die Sortierung nicht kenne.
Wenn ich die Sortierung kenne, kann ich sagen das nach Kreuz-Ass die Kreuz eins kommt, dannach die Kreuz zwei usw.
Das ist hier nicht der Fall.

Das Ergebnis ist deshalb nicht vorhersehbar, weil 2 Tabellen miteinander abgeglichen werden.
Und schon bei der vergleichsweise lächerlichen Menge von 2x ~900 Datensätzen weiß ich nicht, was am Ende rauskommt.
Ändert man einen Datensatz, ändert sich das Ergebnis.
Nennt man das vorhersehbar ?

Was das jetzt mit Normalisierung zu tun hat, verstehe ich nicht.

Chaotisch ist die sortierung der Tabellen an sich keineswegs.
Alle schön alphabetisch sortiert.

Bessere Möglichkeiten kennen Profis mit Sicherheit.
Wie gesagt, bis ich dieses PHP-Tool angefangen hatte, habe ich weder etwas von PHP noch von SQL gehört.
Ich bin aber kein Anwendungsentwickler, darum ist mir im Endeffekt scheißegal wie schrottig mein Code ist: hauptsache es funktioniert.

Für dritte ist das, was ich da gebastelt habe sicher nicht nachvollziehbar, aber auch das ist völlig egal, weil es niemand nachvollziehen muss.

Ich mache das nicht professionell, darum halte ich mich nicht an gern-gesehenen Standards.
Ich kann natürlich verstehen, das es unverzichtbar ist, seinen Code transparent zu gestalten, wenn man sein Projekt irgendwann mal übergeben muss.
Ich kann auch verstehen den Code performant zu machen, aber alle Tabellen in meiner DB kratzen gerade mal an der 1000sten Zeile.
Solange ich keine Endlos-Schleife baue, funktioniert alles ohne Wartezeiten.

Was will ich als jemand, der nur will, das es so aussieht, wie es aussehen soll und das es so funktioniert, wie es soll, mehr ?

Wie gesagt.. ich mache das nicht professionell oder beruflich (nur insofern beruflich, als das ich das für die Arbeit mache, freiwillig, als eigene Herrausforderung)
Ich habe auch einfach nicht die Muße es Perfekt zu machen.
Sobald es läuft, lasse ich es so, wie es ist.

Sicher, ich werde mir mit meinen Ansichten und den Vorraussetzungen (kein ID-Feld, DB nicht normalisiert etc.) selbst das ein oder andere mal ein Beinchen stellen... nehme ich in kauf!
Mir machts Spaß Hürden zu überwinden.. auch wenn ich sie mir selbst aufgestellt habe.

Wie gesagt, ich verstehe was ihr sagen wollt... aber für mich lohnt der Aufwand nicht, erstmal Grundlagen, "wie es sein sollte" nicht nur zu verstehen sondern auch umzusetzen.
Ich begnüge mich mit dem Mist, den ich mir da zusammenschuster ^^

Weiß nicht ob ihr das nachvollziehen könnt.

Für mich sind 15 Dokumente auch schon viel.
Ich habe bei 0 angefangen.
Wie gesagt.. ich stecke da so wenig Energie wie möglich rein.
Das muss nicht perfekt sein.

 

[Albu]

Das Ergebnis ist deshalb nicht vorhersehbar, weil 2 Tabellen miteinander abgeglichen werden.
Und schon bei der vergleichsweise lächerlichen Menge von 2x ~900 Datensätzen weiß ich nicht, was am Ende rauskommt.
Ändert man einen Datensatz, ändert sich das Ergebnis.
Nennt man das vorhersehbar?

Die Sortierung ist abhängig von den Kriterien im ORDER BY. Die Datenbank stellt sicher, dass bei identischer Ergebnismenge, die Daten jedesmal genau gleich sortiert ausgegeben werden. Ob die Sortierung nun alphabetisch, nach numerischen Werten oder nach Datumswerten erfolgt, ist dabei unerheblich. Die Sortierung behandelt alle Mengen gleich.
Welche Tupel in einer konkreten Menge sind, ist abhängig von den Filterkriterien, die auf die Ursprungsmenge angewandt wurden. Sind die Ursprungsmengen gleich, so wird auch die Ergebnismenge identisch sein. Somit sind Ergebnis und Sortierung vorhersagbar, denn SQL ist kein Schätzwerkzeug.
Das ich hier dauernd von Mengen rede liegt daran, dass SQL sehr viel mit der Mengenlehre zu tun hat.

Für dritte ist das, was ich da gebastelt habe sicher nicht nachvollziehbar, aber auch das ist völlig egal, weil es niemand nachvollziehen muss.

Das ist ein extrem schlechtes Vorgehen, weil Du in drei, sechs oder neun Monaten vielleicht eine Erweiterung programmieren willst und dann durch Deinen eigenen Code nicht mehr durchblickst.

Ich kann auch verstehen den Code performant zu machen, aber alle Tabellen in meiner DB kratzen gerade mal an der 1000sten Zeile.

Zwei Tabellen à 1000 Zeilen miteinander verknüpft, schon haben wir eine Millionen Zeilen in der Ergebnismenge. Ist das dann auch noch Larifari?
Vielleicht willst Du mal drei Tabellen miteinander verknüpfen, schwupps haben wir schon eine Milliarde Zeilen. Wird es dann vielleicht langsam brenzlig?

Für mich sind 15 Dokumente auch schon viel.

15 Dokumente sind gar nix. Das Problem ist Deine nicht durchschaubare Programmierung, die Dich bereits jetzt blockiert.

 

[ein schlauer]

Ja, ich glaube das ganze hätte man auch mittels eines Joins machen können, ist schon richtig.
Wäre aber im Grunde nur ein anderer Lösungsweg gewesen und nicht so viel einfacher vom Aufwand her.
Die Querys zu basteln und so auszuführen, das ich das gewünschte Ergebnis erhalte war keine Schwierigkeit.
Der Aufwand liegt in der Darstellung, die bestimmte Anforderungen erfüllen muss.
Statt 4 Querys hätte ich dann 2 Joins ausgeführt.. das hätte den Code wohl etwas vereinfacht, mehr aber auch nicht.

Informiere dich was joins machen, diese Aussage mag im Einzelfall zutreffen, macht aber deinen Code nicht besser. Ist auf jeden Fall grober Unfug. Du sparst dir mindestens die komplette while Schleife.

Aber was du dir auf jeden Fall sparst ist ein Haufen PHP code, wenn du dich ein bisschen in mysql einarbeitest. Was gerade für die von dir genannten Aspekte eine Rolle spielen. Es ist nicht unbedingt so, dass man als "Amateur" immer den größtmöglichsten Umweg gehen muss.

 

[Lagerhaus_Jonny]

Sind die Ursprungsmengen gleich, so wird auch die Ergebnismenge identisch sein.

Ich glaube in meinem Fall nicht.
Was ich tue, ist Tabelle A mit Tabelle B zu vergleichen.
Es wird geprüft ob alle Daten aus Tabelle A auch in Tabelle B vorhanden sind.
In der Ausgabe wird dann ausgegeben, welche Daten in Tabelle A vorhanden sind, in Tabelle B aber nicht.
In der zweiten Tabelle der Ausgabe wird ausgegeben, welche Daten in Tabelle B vorhanden sind, in A aber nicht und daher wahrscheinlich überflüssig sind, da Tabelle A die Referenz ist.
Mehr zur Seite kann man hier erfahren Klick

Das ist ein extrem schlechtes Vorgehen, weil Du in drei, sechs oder neun Monaten vielleicht eine Erweiterung programmieren willst und dann durch Deinen eigenen Code nicht mehr durchblickst.

Richtig

Zwei Tabellen à 1000 Zeilen miteinander verknüpft, schon haben wir eine Millionen Zeilen in der Ergebnismenge.

Ähh... ja, wie gesagt, ich glaube nicht, dass das in meinem Fall zutrifft.

15 Dokumente sind gar nix. Das Problem ist Deine nicht durchschaubare Programmierung, die Dich bereits jetzt blockiert.

Ich wüsste schon wo ich was ändern, erweitern muss.
Problem ist eher meine Faulheit ^^

Ist auf jeden Fall grober Unfug. Du sparst dir mindestens die komplette while Schleife.

Stimmt, die WHILE-Schleifen hätte ich mir damit sparen können.
Allerdings bin ich mir gar nicht mehr so sicher ob genau das was ich da gemacht habe, mit Joins funktioniert.
Aber ist jetzt auch egal, jetzt läuft ja alles.

 

[ein schlauer]

Ich glaube in meinem Fall nicht.
Was ich tue, ist Tabelle A mit Tabelle B zu vergleichen.
Es wird geprüft ob alle Daten aus Tabelle A auch in Tabelle B vorhanden sind.
In der Ausgabe wird dann ausgegeben, welche Daten in Tabelle A vorhanden sind, in Tabelle B aber nicht.
[.....]

Stimmt, die WHILE-Schleifen hätte ich mir damit sparen können.
Allerdings bin ich mir gar nicht mehr so sicher ob genau das was ich da gemacht habe, mit Joins funktioniert.
Aber ist jetzt auch egal, jetzt läuft ja alles.

Genau das was du oben beschreibst, machen joins. ein left join lädt die Daten die in Tabelle A sind und verknüpft diese mit Tabelle B, wenn diese nicht vorhanden sind, sind die Felder der Tabelle B null.

Einführung in Joins

 

[Albu]

Ich glaube in meinem Fall nicht.
........
Ähh... ja, wie gesagt, ich glaube nicht, dass das in meinem Fall zutrifft.

Genausowenig wie Programmieren eine Schätzwissenschaft ist, ist es eine Glaubensfrage. Aber anders als in der Kirche kann man hier durch Tests und Selbstversuche absolute Gewissheit erlangen.
Wenn dennoch unterschiedliche Ergebnisse bei gleichen Ausgangsverhältnissen rauskommen, dann kann es durchaus auch an der Testmethode, an den doch nicht gleichen Ausgangsbedingungen oder an grundlegend falschen Annahmen über das korrekte Ergebnis liegen.

 

[ZeitGeist]

Sind die Ursprungsmengen gleich, so wird auch die Ergebnismenge identisch sein.

Ich glaube in meinem Fall nicht.

Cool ein nicht deterministisches DBS, will ich auch haben, obwohl ich nicht wüßte wo für

Zwei Tabellen à 1000 Zeilen miteinander verknüpft, schon haben wir eine Millionen Zeilen in der Ergebnismenge.

Ähh... ja, wie gesagt, ich glaube nicht, dass das in meinem Fall zutrifft.

Das Jahr 2000 Problem sagt dir was, oder?