✔ jtable und Datenbank

F

floggie

Mitglied
Hallo,

Mein Problem ist folgendes:

Ich fülle eine Jtable mit dem Ergebnis einer Anfrage aus einer Datenbank. Nun kann es vorkommen, dass eine zeile der jtable gelöscht werden soll und natürlcih gleichzeitig der Datensatz in der DB. Die Problem ist jetzt die Identifikation des Datensatzes, da in der Jtable selbst per Definition keine eindeutige id stehen soll. Wie kann man das am besten bewerkstelligen.

Grüsse

floggie
 
Hi,

ähm, ja. die Id kommt ja schon aus der DB, will die bloss nicht in die Tabelle reinschreiben, da sie keinen was angeht. Oder verstehe ich dich da jetzt falsch?

Grüsse

floggie
 
Würde nicht das entsprechende SQL Statement reichen, in dem du alle Felder auf Übereinstimmung prüfst?

so was wie

DELETE from tabelle where Feld1="Wert" AND Feld2="Wert".... ;

keine besonders perfomante Lösung, aber funktioniert

MFg
Dom
 
Ok, ich glaube ich drücke mich schlecht aus. Was ich will ist eine eindeutige Zuordnung des JTable-Datensatzes zu dem DB-Datensatz. Die einfachste Lösung ist wohl den Primary Key mit in die JTable zu ziehen und einfach die entsprechende Spalte nicht anzuzeigen. Die Lösung empfinde ich aber als, naja sagen wir mal unschön.

Grüsse

floggie
 
Was ist daran unschön?
Alternativ kannst Du natürlich auch schauen, anhand welcher Felder sonst noch eine eindeutige Zuordnung möglich ist (auch in Kombination) und diese dann benutzen. Aber ich bevorzuge eindeutig die erste Möglichkeit.
 
Hi,

Information die gar nicht dargestellt werden soll wird "versteckt dargestellt". Nun gut so schlimm ist es auch nicht. Mit dem Verstecken der Spalte kann ich auch leben.

Grüsse

floggie
 
>Information die gar nicht dargestellt werden soll wird "versteckt dargestellt".

Hä?

>Nun gut so schlimm ist es auch nicht. Mit dem Verstecken der Spalte kann ich auch leben.

Also unter verstecken verstehe ich etwas anderes, nämlich absichtliches Entfernen aus einer (An-)Sicht. Das bedeutet implizit, dass etwas unter normalen Umständen ohne Verstecken schon in der (An-)Sicht vorhanden wäre. Das ist doch aber bei vernünftigem TableModel gar nicht der Fall mit der ID. Ich weiß ich schreib mir die Finger wund, aber vielleicht stoße ich ja immer mehr auf offene Ohren, wenn ich die Verwendung von TableRows empfehle. Damit wird pro Datensatz eine Tabellenzeile dargestellt.

Ein Beispiel:
Man nehme eine Adressverwaltung. Eine Adresse hat Name, Vorname, Anrede, Beruf, Straße, Hausnummer, PLZ, Ort, Geburtsdatum, Familienstand.
Jede Adresse entspricht einer Tabellenzeile. Aber was ich anzeigen lasse im TableModel, entscheide ich doch direkt selbst. Ob ich zu getName noch getVorname hinzufüge, ob ich das Geburtsdatum noch anzeige usw. Das ist für mich kein verstecken.
Verstecken ist: ich habe in jeder Hand eine Orange, halte eine Hand aber hinterm Rücken, so dass Du sie nicht siehst. Meine Methode sorgt hingegen dafür, dass gar nicht erst in jeder Hand eine Orange liegt. --> nix verstecken.
 
Hi Snape,

Also mit dem TableModel sprichst du genau den wunden Punkt an. Genau so würde ich gerne arbeiten.
Dass du dir die Finger zum Thema TableModel wundgeschrieben hast habe ich längst gemerkt beim Suchen im Forum. Ein Datensatz = ein Tabellenzeile finde ich super, weil dann vieles einfacher wäre bzw. weniger umständlich. Nun muss ich mal sagen dass ich auf den SUN-Seiten die "Using Tables" Artikel durchgelesen haben, aber die Umsetzung d. oben angesprochenen ist mir trotzdem nicht ganz klar. Wenn du einen guten Link hast, der genau dein Beispiel mal aufgreift -> :) . Ansonsten bin ich "froh", dass Du dir die Finger wundschreibst, sonst hätte ich wohl weniger Antworten bekommen -> DANKE

Grüsse

floggie
 
Moin,
ich hab mir mal ein kleines Beispiel gebastelt, aber iirc war das mit XML einlesen. Ich versuch das mal zu finden und etwas zu kappen, dann wird daraus beizeiten vielleicht noch ein Tutorial. Scheint mir auf jeden Fall sinnvoll zu sein, da dieses Thema immer wieder in schöner Regelmäßigkeit hier auf den Tisch kommt.
 
Um antworten zu können musst du eingeloggt sein.

Neue Beiträge

Zurück