Dataset.xml während Programmausführung mit anderem Programm ändern

  • VB.NET
  • .NET (FX) 4.5–4.8

Es gibt 10 Antworten in diesem Thema. Der letzte Beitrag () ist von ErfinderDesRades.

    Dataset.xml während Programmausführung mit anderem Programm ändern

    Hallo Leute
    Ich habe unter anderem 2 Programme.
    In Programm 1 erstelle ich Artikel (Art. NR, EAN, Name, Preise, etc.) - bei Programm2 handelt es sich um ein Inventurprogramm, mit dessen Hilfe ich Bestände erfasse.
    Dabei halten beide DataSets die gleichen Tables, mit den gleichen Rows. Mit dem einen Unterschied, dass es im Inventurprogramm noch eine "Menge Row" gibt, welche in Programm1 nicht vorkommt (weil sie da ja nicht benötigt wird).
    Programm1 hat nun eine Funktion, das (eigene) DataSet - bzw. dessen ArtikelTable zu exportieren. Über Parameterstart des Programmes2 wird diese geladen.
    Nun wird dieser Export, mit der für Programm2 gespeicherten xml verglichen. Bereits vorhandene Artikel werden ggf. geändert (Suche anhand der Artikelnummer - welche Unique ist), nicht vorhandene Artikel werden angelegt.
    Das funktioniert alles wunderbar, mit einer Ausnahme.

    Wenn ich diesen Export durchführe, während das Inventurprogramm geöffnet ist.
    Dann wird beim starten der Inventuranwendung die xml ins DataSet geladen. Nun ändert das Programm1 die xml (aber das Inventurprogramm lädt diese nicht neu).
    Beim schließen der Inventuranwendung, wird nun diese neu erstellte xml gelöscht und eine xml mit den geladenen (falschen) Werten wird gespeichert.

    Gibt es eine Möglichkeit eine Sub in einer anderen Anwendung auszuführen? Oder als Parameter eine Sub zu übergebe, die dann ausgeführt wird?
    Dann könnte ich vor dem Export prüfen, ob der Prozess Inventurprogramm läuft.
    Eine Alternative wäre das schließen der Inventuranwendung mit anschließendem wieder öffnen. Jedoch finde ich zum schließen nur den Kill Befehl, welcher ja dafür sorgt, dass das Close Event der Inventuranwendung nicht ausgeführt wird - also das DataSet nicht gespeichert wird.

    Welche Möglichkeiten habe ich hier?
    Sorry aber deine Erklärungen sind verwirrend.
    ein Dataset liest seine Daten mit Dataset.ReadXml und ein Dataset speichert seine Daten mit Datset.WriteXml und zwar genau dann.
    Ich verstehe die ganzen Erläuterungen nicht, sei es "Export" oder schließen einer Anwendung und wieder öffnen derselben. Wie du deinen Code organisierst ist doch völlig dir überlassen.
    Die Datset-Dateien selbst ,also die XML's werden nur zum Zeitpunkt ".XmlRead" bzw. ".XmlWrite" angefasst. Alle Veränderungen am Dataset sind also verloren, wenn das ".XmlWrite" nicht ausgeführt werden.
    Auch von daher verstehe ich deine Erläuterungen "aber das Inventurprogramm lädt diese nicht neu" etc. einfach nicht. Deine Programme machen ja auch nur was du denen "beigebracht" hast.

    Grundsätzlich ist es so, dass wenn die Datasets nicht identisch sind, dann gehen eben Informationen verloren die Programm A gespeichert hat aber das gleichnamige aber nicht identische Dataset in Programm B nicht kennt.
    Kennt das Programm B in seinem Dataset aber Strukturen die Programm A selbst nicht hat und nicht gespeichert hat, dann sind diese Tabellen eben halt leer aus im Programm B, zumindest direkt nach dem Einlesen.

    Vielleicht solltest du dir überlegen wie du Programm B vom erneuten Einlesen des Datasets überzeugen kannst, entweder über Programm-Programm.Komunikation oder indem du das Filesystem überwachst?
    Auch da lassen sich sicher schönere Methoden finden, ansonsten machst du einen Programmpunkt wo du den "Reload" manuell ausführst.
    @DerSmurf Kommt da eine Fehlermeldung, dass die Datei nicht geöffnet werden kann, weil sie von einem anderen Programm geöffnet ist?
    Wenn Du beide Programme programmierst, lass doch die Programme sich unterhalten, wie auch immer.
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!
    Ich stimme @Dksksm zu: Nimm einen FileSystemWatcher und teile bei XML-Änderung dem User mit, dass sich was getan hat. Dann sollte das Abspeichern im Programm deaktiviert werden, damit da kein Datensalat entsteht. Es ist natürlich die Frage, ob das Inventurprogramm auf Schreibrechte verzichten kann. Aber wenn Du mit ner Inventurkorrektur arbeiten willst, wird es ggf. langsam Zeit, Dich mit Datenbanken zu beschäftigen, denn letztenendes ist das Szenario ein MultiUserSzenario, was mit tDS umständlich wird.
    @RodFromGermany: Die XML-Datei wird nur zu Programmstart geladen und dann in Ruhe gelassen. Alle Daten sind dann im RAM. Wenn 2 Programme die Datei (zu unterschiedlichen Zeitpunkten) laden, kommen sie sich zwar nicht beim Einlesen der Daten in die Quere, aber beide Programme können die Daten, die im RAM und in ihren jeweiligen DataTables sind, verändern. Das Persistieren wird aber zum Problem, wenn für die Variable A von beiden Programmen der Wert 42 eingelesen wird, aber dann Programm1 A den Wert 66 und Programm2 den Wert 0815 zuweist und beide dann speichern. Wenn ProgA seinen Wert zuerst in die XML abspeichert, steht 66 in der XML. Dann kommt ProgB daher und speichert 0815. Und die 66 ist flöten. Allerdings frag ich mich gerade, warum ich Dich dabei "anpinge". Das weißt Du wahrscheinlich eh schon, dass das "Doppelspeichern" das Problem ist und warum.
    Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von „VaporiZed“, mal wieder aus Grammatikgründen.

    Aufgrund spontaner Selbsteintrübung sind all meine Glaskugeln beim Hersteller. Lasst mich daher bitte nicht den Spekulatiusbackmodus wechseln.

    Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von „VaporiZed“ ()

    Jo, ein altbekanntes Problem - inne Datenbänkerei heisst es: "DbConcurrency".
    Es gibt nicht wirklich Lösungen dafür, aber Strategien, damit umzugehen: OptimisticLock, PessimisticLock, Last-In-Wins.
    Datenbanken haben die Möglichkeit, diese Strategien auf einzelne Datensätze anzuwenden.
    Wenn aber mehrere Anwender dieselbe ganze Datei bearbeiten, ist quasi die ganze Datei der Datensatz, der zu locken ist.

    Das ist interessant - man könnte sich eine vierte Strategie ausdenken: NotifyChange - also dass alle anderen User über vorgenommene Änderungen benachrichtigt werden.
    Aber das wird nicht unaufwendig.
    Naja, das könnte ja mit dem FSW gehen. Aber die Konsequenzen daraus sind ja das Problem. Wenn 2 User 500 Datensätze manuell geändert haben, der 1. speichert und der 2. bekommt ne Meldung, dass sich die Daten geändert haben*, kann er sich vielleicht aussuchen, ob er diese überschreiben will, seine Daten über Bord werfen will oder ob der Programmierer irgendeine Merge-Methode (OMG!) bereit stellen will. Wieauchimmer, alles irgendwie doof.

    * So ne Möglichkeit hatte ich mal testweise in eines meiner Programme eingebaut.
    Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von „VaporiZed“, mal wieder aus Grammatikgründen.

    Aufgrund spontaner Selbsteintrübung sind all meine Glaskugeln beim Hersteller. Lasst mich daher bitte nicht den Spekulatiusbackmodus wechseln.
    Moment Moment.
    Es gibt nur einen User!
    Es ist auch absolut nicht notwendig, dass die Daten "live" aktualisiert werden. (Da in der Regel die Daten vorher aktualisiert werden und dann eine Aktualisierung nicht mehr nötig ist).
    Mir ist dieser "Fehler" nur durch Zufall aufgefallen, weil ich vergessen habe, das Inventurprogramm zu schließen.

    Also wenn alles andere (sehr) umständlich ist, schreibe ich eine Abfrage, ob das Inventurprogramm läuft und lasse eine Meldung auf Ploppen, dass erst geschlossen werden muss. Das würde mir eigentlich vollkommen reichen.
    Aber schöner wäre eben ein schließen der Anwendung, und wieder öffnen.

    Also - beim export der Daten prüfen ob Inventurprogramm läuft, wenn ja beenden (sauber beenden, Close Event muss ausgelöst werden), Daten exportieren und Programm wieder starten.
    Wäre so etwas möglich? Oder geht das beenden eben nur mittels Kill?
    Laufen denn die Programme auf dem selben Computer? Die beiden könnten miteinader reden (TCP/IP (Netzwerk oder selber PC), Pipes (nur selber PC)) und das eine Programm kann das andere darum bitten, sich zu schließen.
    Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von „VaporiZed“, mal wieder aus Grammatikgründen.

    Aufgrund spontaner Selbsteintrübung sind all meine Glaskugeln beim Hersteller. Lasst mich daher bitte nicht den Spekulatiusbackmodus wechseln.
    Also generell ist es so, dass die Programme unabhängig voneinander auf verschiedenen PCs laufen sollen.
    Aber! Bei dem Problem, welches bei mir auftaucht, ist es immer so, dass beide Programme auf dem selben PC laufen.
    Ein "miteinander reden", wäre also enorm hilfreich.
    Schön wäre aber, wenn Programm1 Programm2 nicht bittet sich zu schließen, sondern das Programm bittet die Daten zu speichern und die xml neu zu laden.
    Schließen (und evtl. wieder öffnen) würde aber auch gehen.

    Also aktuell sieht mein Code so aus:

    VB.NET-Quellcode

    1. For Each Process In System.Diagnostics.Process.GetProcessesByName("Inventur")
    2. Dim Messageform As New frmMessage
    3. With Messageform
    4. .SetDisplayText = "Exportieren nicht möglich, solange das Inventurprogramm geöffnet ist."
    5. .SetDisplayTime = 2
    6. .SetAutoClose = True
    7. .Show()
    8. End With
    9. Return
    10. Next

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „DerSmurf“ ()

    DerSmurf schrieb:

    Also aktuell sieht mein Code so aus:
    Ich würds dabei belassen.
    Da ist der User informiert, was vor sich geht, und behält die Kontrolle.

    Man könnte nun mit NamedPipes da eine Kommunikation zwischen den Progs aufbauen, und bla...
    Aber das wird ziemlich aufwändig, ohne einen wesentlichen Mehrwert zu erwirtschaften.
    ZB bei einem automatischen Reload geht (üblicherweise) die aktuelle Selectierung verloren - wird darob der User amused sein?
    Kann man natürlich auch deichseln, dass die Selectierung wiederhergestellt wird - aber das kann nu wirklich richtig aufwändig werden...