Speed Probleme bei mehr als 60 Felder

[BB]

Wenn ich ein typisiertes Dataset mit einer Datenbanktabelle
von mehr als 60 Felder habe, braucht das Speichern (drücken
des Diskettensymbols bei Bindingnavigator) bis zu 12 sek.,
beim untypisierten Speichern mit UPDATE aber lediglich nur
wenige millisec. Woran liegt das ?.
Vielen Dank.

[Ralf Jansen]

Woran liegt das ?

Am SQL.
Schau dir im generierten Tableadapter mal das Update SQLStatement an und optimier das.
Höchstwahrscheinlich tauchen im Moment alle 60 Felder in der WHERE Klausel auf
und wenn du mehrere Nullable Felder hast kommen die 60 Felder sogar n*mal vor.

[BB]

Wie kann ich auf den "generierten Tableadapter" zugreifen und
den Code ansehen ?.
Bei mir steht im Code vom CLick auf das Diskettensymbol
Tableadapter.update(dataset.tabelle).

Vielen Dank.

[Jürgen Thomas]

Wie kann ich auf den "generierten Tableadapter" zugreifen und den Code ansehen ?.

Öffne die zugehörige Quelldatei im Code-Editor; diese heißt wahrscheinlich xxx.Designer.cs (jedenfalls ist das beim "einfachen" typisierten Dataset so). Wenn eine solche Datei im Projekt-Explorer nicht steht, dann lass Dir doch die Liste komplett anzeigen: Doppelklick auf das Plus beim TableAdapter.

Gruß Jürgen

PS. Der Designer erleichtert zwar teilweise das Entwickeln, weil man mit wenigen Klicks schnell vorankommt und einiges nicht mehr selbst schreiben muss; aber das Verständnis wird erheblich erschwert, weil vieles nur noch im Hintergrund erfolgt.

[mirkom76]

Hallo,

vielleicht hilft Dir folgende Info weiter.

http://entwickler-forum.de/showthread.php?t=44227

Da wird genau das Thema behandelt.

[BB]

Leider sind die Probleme immer noch da. Im UPDATE Command des
Tableadapters steht in der WHERE Klausel jetzt nur noch ein Wert
(ID=@Original_ID) und es hat sich ein wenig Besserung beim Speed gezeigt, aber nicht viel (zuvor 12sek jetzt ca 8sek). Normalerweise darf man
doch sofortige Änderung (ca.1sek) erwarten.

Wie kann man das erforschen woran es liegt ?.

Vielen Dank.

[Jürgen Thomas]

Hallo,

das entscheidende Problem (siehe #2 von Ralf Jansen) ist nicht die WHERE-Klausel, sondern die Anzahl der Parameter (= Felder), die aktualisiert werden sollen. Du musst also den eigentlichen CommandText und dessen Parameters-Eigenschaft untersuchen.

Wie ich schon schrieb: Wenn Du auf den TableAdapter verzichtest und den DbCommand selbst erstellst, hast Du selbst die Kontrolle darüber, was gemacht wird - kannst also z.B. festlegen, dass nur die zwei wirklich geänderten Felder zur DB übertragen werden und nicht alle 60.

Gruß Jürgen

[BB]

Vielen Dank Herr Thomas,

ich habe den Command Text auf 6 Felder nun reduziert, aber,
immer noch das gleiche Verhalten. Ist da irgendwo etwas in einem
Cache ausgelagert der die DB an die 60 Felder erinnert ?.

[Andreas Kosch]

Hallo,

Woran liegt das ?

ich gehe einmal davon aus, dass der Wizard von Visual Studio eine Batch-Anweisung erzeugt hat, die nach dem INSERT bzw. UPDATE die Ergebnismenge neu vom SQL Server einliest. Der Grund dafür besteht darin, dass alle die vom SQL Server geänderten Feldwerte (Trigger etc.) auch im DataSet sichtbar sein sollen. Wenn als SELECT-Anweisung nur ein SELECT * FROM Tabelle verwendet wird (d.h. es gibt keine WHERE-Einschränkung), muss der TableAdapter im Worst Case immer alle Datensätze der Tabelle abholen.

Wie sieht die im TableAdapter konfigurierte Anweisung konkret aus? Welchen Unterschied zeigt der SQL Server Profiler an, wenn am die vom Programm ausgelösten SQL-Anweisungen direkt im SQL Server mitprotokollieren lässt?

[BB]

Im SQL-Profiler wird der Befehl wesentlich schneller ausgeführt .
Innerhalb weniger als 1 sek. ist gemäss Start/EndZeit die Ausführung
erfolgt, das allerdings länger. Trotzdem blockiert der SAVE-Button
im Bindingnavigator noch ca.8sek.
Duration 146
Die Tabelle hat nur 180 Datensätze.

Was ist für das 8sek. lange blockieren des SAVE-Button zuständig ?

[BB]

Die TableAdapter Anweisungen sind :
UPDATE: UPDATE Feld1,Feld2,Feld3,... Feld60 WHERE ID=@Original_ID
SELECT: SELECT Feld1,Feld2,Feld3,....Feld60 FROM TB

Direkt nach dem Druck auf den SAVE-Button erfolgt auch im Profiler Reaktion
und Ausführung.
Es wird die UPDATE-Anweisung normal ausgeführt.
Danach jedoch erfolgt wie von Ihnen geschrieben eine
SELECT Feld1,Feld2,Feld3...Feld60 FROM TB WHERE Feld1=@Feld1,.....

Wie ist weiter vorzugehen ?
Vielen Dank.

[BB]

Nachdem das Updaten über den TableAdapter offensichtlich nicht die
gewünschte Geschwindigkeit ergibt, habe ich das Updaten über manuelle
Kontrolle zu lösen versucht:

SQL56 = "UPDATE TB SET Kartennummer=@pTicketnummer, AnfangsNr=@pTicketnummer, EndNr=@pTicketnummer WHERE Standort=@pStandort AND Tag=@pTag AND Bediener_Nr=@pBediener_Nr AND Kassennummer=@pKassennummer";

SqlCommand cmd56 = new SqlCommand(SQL56, Conn1);
cmd56.Parameters.AddWithValue("@pSpw", 1);
cmd56.Parameters.AddWithValue("@pStandort", aStandort);
cmd56.Parameters.AddWithValue("@pKuerz_Bezeich", Kuerz_Bezeich);
cmd56.Parameters.AddWithValue("@pKuerz_zHd", Kuerz_zHd);
cmd56.ExeCuteNonQuery().

Dies klappt auch sehr schnell. Nun ist aber mein DataSet /DataGridView
nicht mehr synchron und es kommt ein rotes Ausrufezeichen mit Parallelilätsverletzung. Was muss ich alles tun um wieder auf den zuvor geupdateten Datensatz zu kommen (ID) und um den Fehler Parallelitätsverletzung zu beheben ?

Vielen Dank.

[Andreas Kosch]

Hallo,

der TableAdapter besteht intern doch im Wesentlichen auch "nur" aus 4 SqlCommand-Instanzen, so dass sich das Prinzip nicht vom manuellen Weg unterscheidet.

Dies klappt auch sehr schnell. Nun ist aber mein DataSet /DataGridView nicht mehr synchron...

Dies bestätigt die anfängliche Vermutung, das nicht die UPDATE-Anweisung das Problem ist, sondern die als 2. Schritt innerhalb der Stapelanweisung ausgeführte SELECT-Anweisung. Der Wizard von Visual Studio verbaut für die SqlCommand-Instanz immer dann eine Stapelanweisung für UPDATE, wenn die Mehrbenutzerfähigkeit im Wizard-Dialog nicht abgewählt wurde.

Es bleiben somit nur noch 2 wahrscheinliche Ursachen übrig, so dass ich folgendes prüfen würde:

1. In der Stapelanweisung für das UPDATE muss die nachfolgende SELECT-Abfrage ein WHERE-Kriterium nutzen, das aus dem Primärschlüsselwert der Tabelle besteht. In diesem Fall wird nach dem UPDATE immer nur der geänderte Datensatz neu eingelesen.
2. In einer separaten Testanwendung würde ich dann prüfen, ob das Verhalten auch dann auftritt, wenn im typisierten DataSet nur diese Tabelle enthalten ist (also keine Relationen zu anderen Tabellen bestehen).