ok... nur um sicher zu gehen, dass ich alles verstanden habe...
es gibt einen hauptserver und mehrere client-server, die clients f�r den
haupserver und server f�r ein intranet sind...
client-server gleichen sich, wenn m�glich, mit dem hauptserver ab.
Claudius
> Hi,
>
> aahh vielleicht kommt ja noch was ...
>
> >
> > Habe ich das richtig verstanden, dass Du auch auf den Clients einen
> > Webserver brauchst f�r die lokale App?
>
> Naja das w�re ne M�glichkeit, die ich aber eher ausschlie�en will.
> Meine Idee war vom Client (Kein Server) ein Request zu starten, der
> WWW-Server liefert die �nderung, und der Client arbeitet es ab und liefert
> �nderungen die auf Clientseite gemacht wurden an den WWW-Server, damit
> dieser seine DB aktuallisiert.
>
> > Abgeglichen wird in beide Richtungen(,falls gerade m�glich...)?
>
> Der Aufruf soll alleine vom Client kommen, da nicht sicher ist ob und wann
> dieser online ist. Abgeglichen sollen aber beide DB's werden (WWW und
> Client)
>
> > Was hast Du eigentlich vor, wenn sowohl auf dem Server als auch auf dem
> > Client der gleiche Datensatz geupdatet wird?
>
> Naja ich habe eine ClientDB auf die mehrere Intranet Benutzer daten �ndern
> k�nnen (Reservieren).
> Ich m�chte nun �ber das Web ebenfalls eine Reservierung realisieren (Ich
> soll).
> Da der WebServer jedoch keine direkte Verbindung zum Client herstellen
> kann,
> muss ich den Abgleich nur von einer Seite, dem Client, bewerkstelligen.
> Es gibt auch mehrere Intranets die jeweils eine DB haben. EInige dieser
> Intranets haben jedoch keine Standleitung (Oder DSL-Flat), sondern nur ein
> Modem/ISDN und Dial-In.
> Ich muss also versuchen vom Client aus einen Abgleich mit dem WWW zu
> machen
> um:
> -WWW-Reservierungen auf den Client zu bekommen
> -Etwaige Clientseitigen Reservierungen auf den Webserver �bertragen, damit
> auf dem Web bekannt ist ob etwas reserviert wurde.
>
> >Timestamp bringt
> > hier �brigens nur
> > bedingt was, da auf beiden Seiten �fter geupdatet werden kann... Reicht
> es
> > Dir, wenn bei gleichzeitigen Updates der letzte
> > "gewinnt"?(wahrscheinlich nicht)
> > Oder stellt das kein Problem dar, weil jeder Client nur auf seinen Daten
> > arbeitet?
>
> Naja ich nehme einen Konflikt in Kauf, da zwischen zwei updates ein Posten
> auf dem WWW sowie auf den Clients reserviert werden kann. Ich k�nnte das
> nur
> verhindern, wenn eine WWW-Reservierung SOFORT auf den CLient �bertragen
> wird.
> Das geht aber eben nicht. Ich nehme also in Kauf, da� einer der beiden
> gewinnt...
> Es geht hier aber nicht um eine gro�e Sache (Hotelreservierung oder so was
> schlimm w�re), sondern um eine Vorreservierung kleiner "Leihartikel".
>
> Einzige M�glichkeit von der ich aber nicht genau wei� wie das l�uft, ist,
> da� man sich mit den Clients per PCAnywhere verbinden kann.
> Dazu br�uchte ich aber ne Komponente, die einen Telefonanruf an den Client
> sendet (Call-Back DF�), oder RAS???? Damit will ich aber nix anfangen,
> weil
> ich sonst keinen Provider finde, der seinen Server an ne Telefonleitung
> ranh�ngt (Geschweige denn die Komponente, die den ANruf t�tigt.
>
> Bei DSL-Flat w�re es kein Problem, da k�nnte ich einen sofortigen Abgleich
> machen, aber das ist eben nicht gew�hrleistet ...
>
> Gru� MAnsur
>
> >
> > Claudius
> >
> > > 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/anmelden/aspdecoffeehouse.asp
> >
>
> --
> GMX - Die Kommunikationsplattform im Internet.
> http://www.gmx.net
>
>
> | [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
>
--
GMX - Die Kommunikationsplattform im Internet.
http://www.gmx.net
| [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
