# Eine einzelne Zeile schreibschützen im DataSet



## AlexDgg (5. Jun 2007)

Hallo zusammen,

ich habe das Problem, das ich in einem DataSet (Abhängig vom Inhalt der Zeilen) nur einzelne Zeilen schreibschützen will. Habe schon alles ausprobiert... mit Listener... etc.. hat leider nichts funktioniert.

Hat jemand eine Ahnung wie so was geht?


----------



## AlexDgg (5. Jun 2007)

Ich denke ich muss die Problematik noch etwas Präzisieren:

Ich verwende die Borland API dbSwing und habe eine (prinzipiell)editierbare Tabelle (jdbTable), die eine direkte Anbindung an ein DataSet hat. Nun versuche ich in dieser Tabelle einzelne Zeilen mit einem Schreibschutz zu versehen. Das geht aber nicht!


----------



## abollm (5. Jun 2007)

AlexDgg hat gesagt.:
			
		

> Ich denke ich muss die Problematik noch etwas Präzisieren:
> 
> Ich verwende die Borland API dbSwing und habe eine (prinzipiell)editierbare Tabelle (jdbTable), die eine direkte Anbindung an ein DataSet hat. Nun versuche ich in dieser Tabelle einzelne Zeilen mit einem Schreibschutz zu versehen. Das geht aber nicht!



Trotz Präzision die Frage:

Welche DB resp. welches RDBMS verwendest du?


----------



## AlexDgg (5. Jun 2007)

MSSQL Server 2000 mit net.sourceforge.jtds.jdbc.Driver


----------



## abollm (5. Jun 2007)

Mit dem Trum kenn ich mich net so aus. Hast du einmal bei Microsoft wegen der Sperrung auf Datenfeldebene nachgesehen?

Bei Oracle geht das, bei MS SQL Server weiß ich das nicht.


----------



## AlexDgg (5. Jun 2007)

Ich dachte eher, dass ich das in der GUI abfangen kann  ... evlt. im DataSet oder in der Tabelle. Der SQL Server gibt immer so kryptische Fehlermeldungen zurück. Da werden die Nutzer immer verückt.


----------



## AlexDgg (5. Jun 2007)

mir fehlt so etwas wir stopEdit() oder cancelEdit() im DataSet oder in der Tabelle


----------



## abollm (5. Jun 2007)

AlexDgg hat gesagt.:
			
		

> Ich dachte eher, dass ich das in der GUI abfangen kann  ... evlt. im DataSet oder in der Tabelle. Der SQL Server gibt immer so kryptische Fehlermeldungen zurück. Da werden die Nutzer immer verückt.



Ich würde das bevorzugt über die DB machen, aber was _genau_ willst bzw. musst du denn machen?


----------



## AlexDgg (5. Jun 2007)

Also ich habe eine Feld Status. Wenn dies einen Bestimmten wert hat, will ich je nach angemendeten Nutzer entscheiden ob dieser Datensatz geändert werden kann oder nicht (Nutzerrechte). Dies geht nicht über die DB da diese den angemeldeten Nutzer nicht kennt. Nur das FrontEnd kennt ihn. Jetzt könnte ich ein Dialog machen und im Dialog die Rechte prüfen. Das ist alledings beim editieren sehr umständlich.

Ich kenne den Status und ich kenne den Nutzer ich will nur das editieren der Tabelle bei Besagtem Datensatz verbieten oder abbrechen.


----------



## abollm (5. Jun 2007)

AlexDgg hat gesagt.:
			
		

> Also ich habe eine Feld Status. Wenn dies einen Bestimmten wert hat, will ich je nach angemendeten Nutzer entscheiden ob dieser Datensatz geändert werden kann oder nicht (Nutzerrechte). Dies geht nicht über die DB da diese den angemeldeten Nutzer nicht kennt. [..]



Verstehe ich nicht, wieso die DB den angemeldeten Nutzer nicht kennt. Das würde mich arg wundern, wenn der MS SQL-Server das nicht mit bekommt.

Der Ablauf ist doch bei jedem halbwegs professionellen DBMS in etwa stets der folgende:

1. Nutzer meldet sich über Frontend (das schließt auch Web-Oberfläche mit ein) an DB an und macht eine Session auf.
2. DB kennt somit den Nutzer in der betr. Session.
3. Nutzer macht irgendeine oder mehrere Transaktionen/Operationen -> SELECT, INSERT, UPDATE, DELETE
4. Nutzer beendet die Session und wird von DBMS abgemeldet.



			
				AlexDgg hat gesagt.:
			
		

> [..] Nur das FrontEnd kennt ihn. Jetzt könnte ich ein Dialog machen und im Dialog die Rechte prüfen. Das ist alledings beim editieren sehr umständlich.
> 
> Ich kenne den Status und ich kenne den Nutzer ich will nur das editieren der Tabelle bei Besagtem Datensatz verbieten oder abbrechen.



So wie ich dich verstanden habe, willst du das über das Frontend machen. Damit musst du in deiner GUI (JTable vermutlich) die notwendigen Schritte _alle_ komplett steuern Damit verstäßt du in einer Mehrbenutzerumgebung aber u.U. gegen Eindeutigkeitsregeln in der Datenbank, weil du so _niemals_ überprüfen kannst, was gerade andere Nutzer an ihren Frontends machen.

Deshalb überlege dir das noch einmal genau.


----------



## AlexDgg (5. Jun 2007)

Die Datenbank ist im Einbenutzermodus und die Rechte/Zugriffsregelung ist Eigenprogrammiert. Das macht in diesem Fall auch Sinn, da fast alle Rechteprüfungen im Frontend geschehen (und auch geschehen müßen).

Ich will ja nur der verdamten JTable hinter der jdbTable sagen DIESE ZEILE NICHT! Bei Spalten ist dies kein Problem WIESO NICHT BEI ZEILEN???


----------



## AlexDgg (5. Jun 2007)

Übrigens die Regelung der Eindeutigkeit wird über Deadlocksperren geregelt


----------



## abollm (5. Jun 2007)

Ist mir jetzt halbwegs klar. Hab nur grad einen Kunden am Wickel und kann mich gerade nicht darum kümmern. Melde mich nachher nachher noch einmal hier, sofern nicht jemand anders dir die entscheidenden Tipps gibt.


----------



## abollm (6. Jun 2007)

AlexDgg hat gesagt.:
			
		

> Die Datenbank ist im Einbenutzermodus und die Rechte/Zugriffsregelung ist Eigenprogrammiert. Das macht in diesem Fall auch Sinn, da fast alle Rechteprüfungen im Frontend geschehen (und auch geschehen müßen).
> 
> Ich will ja nur der verdamten JTable hinter der jdbTable sagen DIESE ZEILE NICHT! Bei Spalten ist dies kein Problem WIESO NICHT BEI ZEILEN???



Vorweg: Ich kenne mich mit dem JBuilder und den zugehörigen Klassen (z.B. jdbTable) _nicht_ aus.

Angeblich soll jdbTable aber von JTable abgeleitet sein. Du benutzt, wie du selbst geschrieben hast, eine JTable. Folglich musst du ja bereits irgendwie dafür sorgen, dass die Daten vom einen in das andere (Tabellen-)Objekt gelangen. Hier würde ich nun ansetzen und z.B. die Daten in ein geeignetes Objekt zwischenspeichern und dann die Bearbeitbarkeit je nach den Werten im Statusfeld entsprechend behandeln.

Warum du allerdings bestimmte Spalten und nicht bestimmte Zeilen für das Edieren sperren kannst, blicke ich derzeit (noch) nicht. Was hältst du davon, einfach die Daten vor der eigentlichen Bearbeitung durch den Anwender in deine JTable zu schaufeln und die JTable mit einem entsprechenden Listener auszustatten? Der Listener sorgt für die Datensatzsperrung. Dann hast du alle Möglichkeiten (aber siehe auch unten).

Was sagt außerdem die Borland API?

BTW: Eine MS-SQL-Server-Datenbank im Ein-Benutzermodus und zusammen mit Aktionen, wie einzelne Datensätze (-zeilen) sperren, klingt schon arg kompliziert. Aber gut, dazu muss man wohl mehr wissen.


----------

