Hi, > > > 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.
W�re bei einer Modem/Dial-In Verbindung auch recht teuer in den Verbindungskosten. > Aber das Teil unters�tzt die Reservierung per Web von Haus aus? Nein es unterst�tzt keine Webreservierung von haus aus. Die ClientDB wird von mhereren Rechnern angesprochen (Intranet) und die anderen Rechner k�nnen �ber die selbe Anwendung eine lokale Reservierung durchf�hren. Hierzu werden bestimmte Werte in die Tabelle eingetragen. > 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 ;) ). Naja vielleicht kriege ich ja irgendwann doch noch nen Zugang zum Code. Jetzt aber auf jeden Fall nicht. > 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. Es wird irgendein Provider sein ... qh vielleicht. > 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. Das mit dem DB kopieren brauche ich weil ja auch jemand auf dem Client eine Reservierung vornehmen kann und ich irgendwie draufkommen muss was sich da ge�ndert hat (Dumm das access keine Trigger unterst�tzt), um auf der WWW - Datenbank dise Clientreservierungen nachzuziehen. > 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. Was dann wahrscheinlich in der Applikation zu fehlern f�hren wird .... Aber ich probier das mal. > 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. Ja aber einen Timestamp unterst�tzt ja Access nicht... oder? > > 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? Was ist "SCP"???? ***DummFrag*** Du meinst SSL? Das denke ich will ich schon machen .... Kann ich �berhaupt per XMLHTTP auch auf https: zugreifen??? (oje Furcht) > > 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 ;) Ahh ja Du meinst SSL Verschl�sselung. Ja klar wie gesagt ich m�chte die Daten verschl�sselt holen, wenn es XMLHTTP erlaubt. Gru� Mansur > > > 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 > | [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
