Genau das war der Grund warum ich danach fragte ;) Man h�tte sonst den ODBC auf Exclusiv stellen k�nnen um so eine gleichzeitge Bearbeitung zu verhindern. Ausserdem h�tte man die DB damit vom Client zum Server ziehen k�nnen, um das erst mal auseinander zu bringen. Geht aber so halt nicht. Aber das Teil unters�tzt die Reservierung per Web von Haus aus? Dann sollte es da eine def. Schnittstelle geben, an die Du gehen kannst. Das schwierige wird nur sein, diese zu finden (sofern der Hersteller das Modul verkaufen will, legt er diese meist nicht offen ;) ). Wenn der Webserver bei Dir im Haus steht, w�rde ich eher mit transactions arbeiten (da kann man im Zweifel ein Rollback machen), als mit der XML Geschichte, da Du dann direkt in die DB schreiben kannst. Wenn Du die Daten von einem "draussen" stehenden Webserver abholen musst h�rt sich die XML Idee soweit ganz gut an. Ich w�rde allerdings pro Datensatz einen gesonderten Tag im XML File machen. Dann kannst Du Dir das ganze hin und herkopieren der DB sparen, weil Du jeden einzelnen Datensatz vor dem einf�gen gegen die DB checken kannst. Ausserdem w�rde ich die DB Connection im Moment des einf�llens der www Daten auf exclusiv stellen, so dass vom Client in dem Moment keine Aktionen auf die DB m�glich sind. Die geschichte mit dem DB Diff kann ich nicht nachvollziehen. Sicher hat sich zwischen den www Daten Einspeisungen auf dem Client was getan, aber warum willst Du wissen, was sich da getan hat? Die Daten sind doch in der DB. Im Zweifel bau ein Feld Timestamp mit ein, das automatisch den Zeitstempel des Datensatzes setzt. Dann kannst Du anhand des Timestamps sehen, was nach dem letzten Lauf Deine App1 gelaufen ist.
Ich w�rde aber die XML Files aus sicherheits- und Bequemlichkeitsgr�nden nur per SCP abolen. Dann sind die Plain Text XML Files wenigstens verschl�sselt auf Ihrem weg durchs b�se Internet ;). Ich weiss zwar nicht, was Deine Reservierung ist, aber ich denke, dass da einige pers�nlich Angaben notwendig sind, oder? Ich find das eh immer schon urkomisch, wenn sich die Leute mit irgendwelchen "Verisign Secure Certifiqates" schm�cken bei der Dateneingabe der Kunden und im Hintergrund schicken sie die Daten dann per Mail zur weiteren verarbeitung nach Hause ;) Dann brauchts auch kein SSL Zertifikat ;) Mit freundlichen Gr�ssen Mathias Becker [EMAIL PROTECTED] > -----Urspr�ngliche Nachricht----- > Von: Mansur Esmann [OM] [mailto:[EMAIL PROTECTED]] > Gesendet: Mittwoch, 26. Juni 2002 09:13 > An: AspGerman Kaffeehaus > Betreff: [aspdecoffeehouse] AW: [aspdecoffeehouse] AW: > [aspdecoffeehouse] andere Vorschl�ge > > > Hallo, > > > > > > > > Verstehe ich das richtig, das das Programm auf dem Client > irgendeine > > properit�re L�sung mit Programmoberfl�che zur DB ist und Du > > zus�tzzlich zu dieser Oberfl�che noch ein Webinterface dransetzen > > willst? > > Ich glaube (!) das heisst "propriet�re" (oder so) :-) > Aber stimmt.... > Das Programm unterst�tzt ne Art "Reservierung" und die > Reservierung soll �ber Webinterface ebenfalls gehen. > > > > > Wenn ja, wie greift das prop. Programm auf die DB zu? Per > ODBC, oder > > direkt? > > Kein ODBC. Nur direkt > Aber das ist ja nicht so relevant f�r die ganze Sache, da ich > keinen einfluss auf die "propriet�re" L�sung habe :-) > > Mansur > > > > > > > Mit freundlichen Gr�ssen > > > > Mathias Becker > > [EMAIL PROTECTED] > > > > > > > > Morgen miteinander, > > > > > > ich m�chte heute nocheinmal ein konzept �berdenken und hoff Ihr > > > k�nnt mir vielleicht nen Vorschlag machen, der mir noch nicht > > > eingefallen ist. > > > > > > Datenbankabgleich zw. einer client Datenbank und einer Server > > > Datenbank. > > > > > > auf einem Clientrechner habe ich eine Datenbank habe ich > eine Access > > > DB mit 3 Relevanten Tabellen, die zusammen ca. 7500 Datens�tze > > > haben. Ich sch�tze mal die Ver�nerung der Datens�tze auf ca. 100 > > > RS's. pro Tag. > > > > > > Ich muss �ber ein Webinterface die Datenbest�nde des > Clients �ndern > > > k�nnen. Nach M�glichkeit sollte dies NICHT vom WWW-Server aus > > > geschehen, sondern vom Client aus (Mir ist klar, da� es > dadurch zu > > > Unregelm��igkeiten kommen kann). > > > > > > Ich dachte mir das ganze so: > > > -User ver�ndert Datensatz auf dem WWW, gleichzeitig wird diese > > > Ver�nderung in ein XML-File geschrieben > > > (FreethreadedDomDocument) -Auf dem Client wird alle nn Minuten > > > kleines Programm aktiv (Task)... > > > ("App1") > > > -App1 ruft per XMLHTTP die XML-Datei des Servers ab > > > -Anhand der gleichen ID's von ServerXML und CLientDB wird die > > > ClientDB ge'updatet -Die ClientDB wird per fso dupliziert > > > > > > > > > einige Minuten sp�ter.... > > > -bevor der oben dargestellte Ablauf stattfindet wird die > Duplizierte > > > DB mit der reg. ClientDB verglichen (Verschachtelte RS) > und daraus > > > ein XML File gebildet, da� die Differenz darstellt. Das > ist n�tig, > > > da� die CLientDB auch auf Clientseite ver�ndert werden > kann und ich > > > keinen EInfluss darauf habe > > > ("BlackboxAPPL.") > > > -Es werden wiederum die WWW-XML Abgleich geholt und danach die > > > Client-XML Abgleich hochgeschickt > > > > > > > > > Hat jemand ne bessere L�sung? > > > Am besten w�re es nat�rlich wenn jeder Client ein kleiner Server > > > w�re und der WWW-Server seine Ver�nderungen sofort hinschickt, da > > > aber der Client auch offline sein kann ist das nicht zu machen. > > > > > > Hat jemand noch einen anderen Vorschlag? > > > > > > Gru� Mansur > > > > > > > > | [aspdecoffeehouse] als [EMAIL PROTECTED] subscribed > | http://www.aspgerman.com/archiv/aspdecoffeehouse/ = > Listenarchiv Sie > | k�nnen sich unter folgender URL an- und abmelden: > | > http://www.aspgerman.com/aspgerman/listen/anme> lden/aspdecoffeehouse.as > | p > | [aspdecoffeehouse] als [email protected] subscribed | http://www.aspgerman.com/archiv/aspdecoffeehouse/ = Listenarchiv | Sie k�nnen sich unter folgender URL an- und abmelden: | http://www.aspgerman.com/aspgerman/listen/anmelden/aspdecoffeehouse.asp
