habe eine Dataset mit SQL-Tabelle, daraus ein Datagridview; beim Timestamp-Feld meckert er bei der Ausführung und bringt eine DatagridView-Ausnahme: Ungültiger Parameter

Kann man ein Timestamp-Feld dort nicht drinlassen?

in .Net gibts keinen Timestamp-Typ Welchen Datentyp hat den die Dataset-DataColumn?

ansonsten - wieso sollte ühaupt ein Timestamp angezeigt werden? ist vlt. eh angesagt, die Spalte aussm DGV rauszulassen - was soll der User damit?

autmatisch wird ein System.Byte() draus gemacht als DataType

jo, System.Byte() wird im DatagridView standardmäßig als ImageColumn dargestellt, und das failt natürlich. Also diese Spalte nicht im DGV anzeigen.

Ich hoffe, du verwendest typisiertes Dataset, sonst macht das bisserl Umstände.

Edit by ErfinderDesRades: unnötiges Vollzitat entfernt

Da du frägst gleich noch ne Frage hinterher; hab bis jetzt alles typisiert und eben mir auch die Variante SQLReader an Datagridview angeschaut.

SQLReader geht halt alles per Hand...da hast du recht, da ist typisiert einfach angenehmer. Aber ich hab noch keine wirklich gute Idee wie ich im Multiuserbetrieb das abbilde. (SQL Datenbank). Das Problem beim typisiertem über Tabeladapter ist, dass ich mir immer die komplette Datenbank ins Gridview hole und dort vorhalte, d.h. für den Multiuserbetrieb eher schlecht.

Mein Gedanke ging in Richtung Timestamp und Sperr-Flag. Aber auch da: Je länger ich das im Dataset halte desto älter werden meine Daten....

Wie machst du das?

MultiUser-Betrieb: gibts kein Patentrezept für.

Allerdings

Checkpoint schrieb:

über Tabeladapter ist, dass ich mir immer die komplette Datenbank ins Gridview hole

ist so nicht richtig.
Man kann den TableAdaptern zusätzliche Queries anfügen, mit denen man parametrisiert ganz gezielt gefilterte Datenmengen abrufen kann.
Aber das ist halt auch immer knifflig, denn alle übergeordneten Datensätze, auf die von einer menge untergeordneter Datensätze verwiesen wird, müssen vorhanden sein.

Also übergeordnete Tabellen schaufel ich, soweit vertretbar, gerne komplett ein, sowas wie Anreden, Krankenkassen u. dgl., weil übergeordnete Tabellen sind üblicherweise ja auch nicht sooo umfangreich.

Tatsächlich verwende ich garkeine typisierten TableAdapter mehr, weilichmir ein Framework gebastelt hab, was flexibler einsetzbar ist, und auch noch weniger Code ist als die Summe aller Tableadapter, die einem bei mw. 10 DataTables ins Dataset generiert werden: DBExtensions

Aber mit MultiUser habich gar keine praktische Erfahrung. Muss man halt überlegen, ob man inne DB eine StoredProcedure oder Trigger oder wasweißich macht, dass nicht 2 User denselben Datensatz bearbeiten können.
Grad mit sonem Timestamp ließe sich ja vlt. was deichseln: Wenn der User in den BearbeitungsModus eines Datensatzes geht, dann wird die Time in die DB gestampt, und annere User können dann nicht mehr mit diesem Datensatz in den Bearbeitungsmodus gehen, jdfs. nicht bevor ein großzügiger Timeout abgelaufen ist.

ja sowas wie Anreden ect. ist nicht das Problem. Das Problem ist eher sowas wie eine Kundentabelle mit mehreren tausend Datensätzen, da hängt dann ja auch noch jede Menge drunter.....die typisiert ins Dataset holen und jedes mal komplett neu reinzuholen weil sich im Multiuserbetrieb was geändert hat ist ein Graus.

Mein Gedanke geht da momentan dahin die per Reader gezielt in ein Gridview per SQLReader (man braucht ja in der Regel nicht alle, sondern nur die gesuchten)....dann bei Auswahl in eine Detail-Read-Ansicht...einen Edit-Modus der ein Flag vergibt und damit für alle andere ein Edit sperrt. Ist er zurückgeschrieben hat er ein anderes Timestamp und das frag ich vor dem Edit-Modus ab. Nur genau diese Einzelabfragen sind das Problem beim typisiertem Dataset oder lieg ich da falsch?

ja und nein.
wie gesagt: man kann generierte TableAdapter problemlos um weitere Abfragen erweitern. Die verfügen auch über die Methode .GetTable(), und damit wird eine neue DataTable erzeugt, die das eigliche Dataset ühaupt nicht berührt.
Also eine Query auf nur einen Datensatz - ob er gesperrt ist - könnte man leicht über .Gettable laufen lassen.

Auch sind die dir geläufigen Zugriffs-Methoden ja nicht aus der Welt. Du kannst ja weiterhin jederzeit ein Command raushauen, was inne DB ein Sperr-Flag setzt oder ausliest oder whatever.
Wenn du dich auf eine einheitliche Strategie einigst, kannst du das sogar sehr generisch proggen, also zwei Methoden GetLock(typisierteDataRow) As Boolean und SetLock(typisierteDataRow, Boolean), und das entsprechende Command kann die Methode ja selbständig generieren, anhand der DataRow.

das mag alles sein, nur am Ende, wenn ich quasi feststelle dass mein Dataset nicht uptodate ist, muß ich mir die kompletten Datensätze reinholen damit ich wieder aktuell bin und weiter arbeiten kann....das ist irgendwie ein Fluch bei vielen tausend Datensätzen...oder kann ich dann gezielt einen Datensatz im Dataset "updaten" ?

Auch das Updaten individueller Datarows ist drin, prinzipiell genauso wie das mittm GetLock/SetLock.
nur dass eben der gesamte Datensatz abgerufen wird - wohlgemerkt! - in eine Extra-DataTable, oder gar mit einem DataReader.

Und die Werte der frischen DataRow überträgt man dann in den ollen Datensatz. DAnn noch DataRow.AcceptChanges aus Gründen der Vollständigkeit.

Vlt. lässt man auch das mittm GetLock, und updatet gleich die DataRow. Die aktualisierte DataRow enthält dann ja auch das Flag, ob sie zur Bearbeitung gesperrt ist oder nicht.

Wie gesagt: Ich konzipiere hier ohne praktische Erfahrung, habe aber den Eindruck, dass sich diese Geschichten problemlos in den typisierten Ado.Net-Kontext integrieren lassen.