Vielen Dank für die Tips und dazu mein Feedback
- Ja, die Tabelle hat einen Primarykey
- Das Verhalten ändert sich nicht ob ich Insert oder Append verwende. Ich glaube nicht, dass Dataset hier überhaupt einen Unterschied macht. In beiden Fällen liefert DataSet.State = dsInsert und schau ich mir im MsSQL-Profiler an, was dort geschieht, sehe ich beide male
Code:
exec sp_executesql N'SET NOCOUNT OFF; INSERT INTO "TestDB".."analysis" ("Bezeichnung") VALUES (@P1); SELECT SCOPE_IDENTITY() AS SCOPE_ID_COLUMN',N'@P1 nvarchar(6)',N'Insert'
(Diese Beispiel stimmt nicht mit der Datenstruktur oben überein, sondern war nur kurzer Test)
- DataSet hat einen Filter. Der ist so gesetzt, dass er nur die Daten der aktuellen Workstation anzeigt. Der neue Datensatz erfüllt diese Bedingung. Ich selber verwende nie Filter sondern filtere immer schon im SQL mit where. Ich werden den Filter eliminieren, auch wenn er keine Rolle spielen sollte.
- Ich habe alle Post - Edit entfernt. Ganz zum Schluss brauch ich dann aber doch eines, da in bestimmten Fällen, die erzeugte PK in eine Feld geschrieben wird. Das funktioniert jetzt zwar, aber da ich auch nicht sicher weiß warum die Exception auftritt, bin ich auch nicht sicher, ob ich in jedem Fall die korrekte PK zurück bekomme.
- Es gibt keine weiteren Ereignishandler in DataSet oder DataSource. Ich suche aber noch, ob vieleleicht auf einem der Editfelder was passiert.
Ich werde den kompletten Insert in eine eigenes Dataset legen, würde aber gern bei Insert - Post bleiben. Per
SQL ist mir im Moment der Aufwand zu groß um eines für Insert und eines für Update mit den XX-Feldern zu schreiben. Da diese Dataset mit keinerlei Filtern oder Ereignissen verknüpft sein wird, ist ja wohl sichergsetellt, dass der Datensatz nach dem Post derselbe ist wie der, der gepostet wurde.
Welche Möglichkeiten gäbe es denn sonst noch um sicherzustellen, dass man nach dem Post auf dem korrekten Datansatz steht? Bei den Daten, die ich selber mit
Code:
Insert Into..
// hängt immer ein
select SCOPE_IDENTITY() as ID');
// Dran um die erzeugte ID zurück zu bekommen.
Gibt es sowas bei Post auch?
Mein Problem im vorliegenden Fall: Außer der PK, die ja erst beim Post erzeugt wird, habe ich keine eindeutigen Suchkey. Wenn, dann am ehesten das CreatDate. Da bin ich mir aber nicht sicher ob das immer funktioniert. Ich hatte mit
MsSQL bei Realzahlen schon das Problem, dass die Originalzahl und die in der
DB gespeicherte Zahl in den letzten Bits nicht übereingestimmt haben, ein Vergleich
Code:
Where rOriginal = Feld.Value
also fehlschlug.
Zitat
Baum-Darstellung
