Suchergebnisse

Wenn zwei Programminstanzen laufen, hat jedes für sich zu Programmstart die Daten, die in der Datei stehen. Nach Programmstart werkelt jede Proramminstanz für sich weiter. Ein Fortsetzen der AutoIncrement-ID kann eigentlich nur dann bei diesem Szenario erfolgreich sein, wenn nach Neuerstellung einer TableRow die Daten gleich in der XML abgespeichert werden und die andere Programminstanz per FileSystemwatcher diese Änderung mitbekommt und dann die Daten neu einliest. Oder ist die "Kommunikation" …

Zitat von Madde: „Hier kommt der Fehler, die Datei wird von einem anderen Prozess verwendet.“ Da solltest Du grundsätzlich mal dem Neueinlesen eine Pause von ca. 3 Sekunden vorsetzen. Denn das Schreiben und Freigeben der XML von Prog1 kann etwas dauern. Wenn das klappt, dann kannst Du auch statt der 3-Sekunden-Wartezeit ne Delay-Schleife einbauen, in der z.B. 5x alle 0,5 Sekunden getestet wird, ob der Zugriff auf die Datei möglich ist. Wenn Deine genannte Exception kommt, dann eben nochmal warte…

Bei der dts.Adapter.Save-Zeile kann ich nicht weiterhelfen. Ich vermute, dass das was mit TableAdaptern zu tun hat, die Du eh nicht in Deinem Projekt hast. Das mit der ID versteh ich insofern nicht, weil doch die 2. Programminstanz nur lesen soll und keine eigenen TableRows erstellt. Oder hab ich da was falsch verstanden? Oder tritt das ID-Problem allein in der ersten ProgInstanz auf? Was heißt eigentlich willkürlich? Reihenfolge bei Erstellung ist -1, 58, 666, -42, 513? Was passiert, wenn Du nu…

Lass Dir doch mal alle IDs anzeigen. Vielleicht sind ja mehr Daten im tDS als erwartet.

Vor dem Speichern, nach dem Speichern, vor dem Laden, nach dem Laden und nach dem Auftreten der unsinnigen nächsten ID mal bitte jeweils das hier ausführen und Werte notieren/hier posten VB.NET-Quellcode (3 Zeilen)

Hm. Leider fehlen jetzt die gewünschten Kennzahlen. Vor allem RowCount ist interessant. Die nächste Frage, die Du Dir stellen solltest, ist: Wieviele Rows hat vor und nach jeder der genannten Aktionen Deine DataTable.

Was passiert mit einer neuen, von anderen DataTables unabhängigen Dummy-DataTable? Gleiches ID-Problem oder nicht?

Leg doch mal ein neues Projekt an, kopier Dein DataSet-Inhalt rein und bring es zum Laufen (erstmal ohne die XML-Datei). Wenn das mit Testdaten klappt, dann mit XML-Datei. Dann kannst Du viel besser entscheiden, ob es an den Daten liegt (eher nicht), den tDS-Einstellungen (möglich) oder am Projektcoderest (wahrscheinlich).

Ah, ok. Jetzt kann ich das Problem zumindest nachstellen. Wobei das mit der Nachstellung sich sehr leicht zeigt. Man nehme eine DataTable mit AutoIncrement-Spalte, ein daran gebundenes DGV, bei dem man Zeilen hinzufügen kann und gehe in die letzte Zeile. Es wird eine neue Zeile mit erhöhter ID erstellt. Verlässt man die Zeile ohne Dateneigabe, wird diese Zeile entfernt. Geht man wieder in die letzte Zeile, wird wieder eine neue Zeile erstellt, allerdings nicht mit der gleichen ID, sondern mit de…

Sowohl den Speicherort der ID als auch den Workaround habe ich gepostet. Du könntest es wohl mit der Lösung von EdR machen, indem Du beim Auftragsanlegen eben diesen Merge machst.

Das mit dem Dateilock ist an sich schnell gemacht: VB.NET-Quellcode (5 Zeilen)

Ein Wort sagt mehr als tausend Bilder.

Du vergleichst jetzt aber Äpfel mit Glühbirnen. Das hat ja nix mit meinem Vorschlag zu tun. Application.StartupPath ist ein String, keine Methode. Und wenn man EinString(wasauchimmer) schreibt, versucht der Compiler dieses wasauchimmer als Zahl zu interpretieren, um das xte Zeichen + 1 wiederzugeben. Also "Test"(0) gibt T wieder, "Test"(2) ergibt s. Da aber "edit.txt" nicht als Zahl interpretiert werden kann, meckert der Compiler.

Und dann noch den VB6-Namespace drin. Du willst aber auch provozieren, oder?

In diesem speziellen Code das mit MsgBox. Aber das steht alles in dem Thread drin, den EdR in Post#52 verlinkt hat.