Hallo,
die Recherche in Internet und Foren lässt mich Schlimmes befürchten, vielleicht interpretiere ich aber auch etwas falsch. Für meinen Vertriebsleiter habe ich eine kleine Access-Datenbank (A2007) erstellt, die für Mitarbeiter im Außendienst verfügbar sein soll. Die Idee war folgende:
- Auf dem Firmenserver wird ein Laufwerk freigegeben, dass bei bestehender VPN-Verbindung vom externen Client-Notebook des Vertrieblers als gemapptes Laufwerk verfügbar ist, also z.B. als Laufwerk V:
- Datenbank ist in Back- und Frontend aufgeteilt, Tabellen im Backend liegen auf dem gemappten Laufwerk V:
- Frontend-Abfragen, Formulare und Berichte liegen entsprechend den Bedürfnissen des jeweiligen Vertrieblers auf dessen lokalem Rechner/Notebook
In meinem lokalen Netzwerk funktionierte das mit der geteilten Datenbank über den lokalen PC und ein gemapptes Netzlaufwerk. Da das zu später mappende Laufwerk derzeit noch nicht zur Verfügung steht, hatte ich für einen weiteren Test ein entferntes Laufwerk auf einem Webserver mittels WebDAV gemappt. Das klappte dann schon nicht mehr. Ist nun zu erwarten, dass das auch mit dem gemappten Laufwerk bei bestehender VPN-Verbindung daneben geht? Was wäre dann eine möglichst unaufwendige Alternative?
Danke für kurze Tipps und Anregungen.
Gruß,
Jo
Hallo,
prinzipiell funktioniert das mit den gemappten LWs schon... Nur ist die Performance so gut, dass man nach jedem Klick erstmal eine Kanne Kaffee kochen kann und die auch noch trinken muss.
Der Grund liegt darin, dass Access ein püassives DB-System ist und bei jeder DS-Operation der gesamte Datenbestand über das Netz ( hier Internet) transportiert werden muss.
Die beste (IMHO) Alternative ist die Verwendung eines Terminal-Servers und serverseitigen User-Accounts, auf die per Remote-Desktop zugegriffen wird.
Damit läuft die Access-Anwendungen direkt auf dem Server und über das Netz muss nur die "Monitoranzeige" übertragen werden.
Zunächst mal vielen Dank für die Antwort. Das Backend wird voraussichtlich 2, vielleicht 3 MB groß werden, ggf. auch kleiner bleiben - ggf. ist das performancetechnisch ja doch noch zu stemmen. Hast Du eine Idee, wieso das mit dem gemappten webDAV-Laufwerk zum Testen nicht funktioniert haben könnte? Über den Explorer konnte ich es normal aufrufen, Zugangsdaten waren also ok.
Ok, gehen wir davon aus, dass das mit dem Mappen funktioniert, ich aber performancetechnisch doch Schiffbruch erleide: Die Terminalserverlösung stünde zwar zur Verfügung, aber eigentlich wollten wir genau davon weg, dass wir uns erst ins Terminal einwählen müssen, um z.B. lediglich eine kleine Änderung an einem Datensatz vornehmen zu müssen.
Letztlich benötigt jeder Außendienstler zunächst auch nur die Daten, die er selbst eingibt. Nur der Vertriebsleiter müsste wegen erweiterter Auswertungen und Übersichten Zugriff auf den gesammten Bestand haben, und das auch nur zu bestimmten Zeitpunkten (vor Meetings, Calls, Monatsende). Wenn nun jeder seine eigene lokale Datenbank führte? Er könnte seine lokale Backend-DB z.B. einmal pro Woche an den Vertriebsleiter mailen, dieser müsste allerdings sinnvollerweise die DBs "zusammenmischen" können. Gab's da bei Access nicht irgendwas zu? Bin kein großer Access-Kenner, aber ich erinnere mich daran, dass ich mal was von Replikation, Synchronisation und GUID-Autowerten gelesen habe. Wäre DAS eine Alternative? :-\
Hallo,
Replikation wäre schon das richtige Stichwort für das "Mischen" von unabhängig voneinander erfassten Daten in einer zentralen DB.
Nur, Replikation wird ab A2007 nicht mehr weiter unterstützt.
Warum das Mappen nicht funktioniert hat, kann ich nicht sagen... Ich hatte eine solche Geschichte mal mit meinem IE-Provider probiert und damit kein Problem... außer die besagte miese Performance bis zum Stillstand...
Hallo
Ich habe mal im Netz gesucht und diesen Beitrag gefunden:
http://www.vb-paradise.de/programmieren/datenbankprogrammierung/64535-datenbanksynchronisierung-bei-programmstart-und-ende/index3.html
Da die Datenbank aufgeilt wurde in BE und FE könnte man drüber Nachdenken das BE in das Format 2003 zu konvertieren und als Replikat laufen zulassen was ein Syncronisieren wieder möglich macht.
ZitatReplikation, Synchronisation und GUID-Autowerten gelesen habe. Wäre DAS eine Alternative?
Nach meinem Dafürhalten nur für sehr einfache Konstrukte.
Problemfall 1: In DB gibt es m:n-Beziehung zwischen Kunde und Ort. Drei unterschiedliche Außendienstler erfassen mit ihrer jeweils eigenen Einzelplatzlösung jeweils einen Neukunden, der der erste ist, der aus Berlin kommt. Ergebnis: Der Ort Berlin erscheint jeweils mit anderer ID, in der zusammengefassten DB dann ein "wunderschöner" Effekt. Wie kriegt man das wieder raus?
Problemfall 2: In der Einzelplatz-DB und in der Zentral-DB wird nach der letzten Synchronisierung der gleiche Feldwert geändert. Das wird erkannt. Wer hat nun beim Überschreiben Recht? Immer der eine, oder immer der andere, oder soll wahlweise entschieden werden?
Letzteres ist für einen Massenabgleich untragbar.
MfGA
ebs
Hi Leute,
danke für die weiteren Posts. Ich hab' mich mal drangemacht und ein wenig getestet:
BE-Datenbank in .mdb konvertiert, dann 2 Replikate erstellt und diese zusammen mit den jeweiligen FE-accdb's in separaten Verzeichnissen gespeichert, um die Clients zu emulieren (über den Tabellenverknüpfungsmanager natürlich die jeweiligen Verknüpfungen aus den FE-Datenbanken hergestellt). In jedem Replikatverzeichnis über das jeweilige FE Änderungen und Ergänzungen vorgenommen, dann Datenbanken geschlossen. Dann die Master-mdb geöffnet und über die Replikationsoptionen synchronisiert und ... voilà ... sieht gut aus ... abgesehen von den nun elendich langen IDs der hinzugefügten Datensätze. Aber dennoch jedenfalls ein richtiger Schritt.
@abs17: Danke für Deine Info, aber:
Punkt 1: Die Ort-Problematik ist weitestgehend irrelevant. Jeder Vertriebler hat fest zugeordnete PLZ-Bereiche und legt nur innerhalb dieser Bereiche evtl. Neukunden an. Aber die Kundendaten selbst sind bei dieser DB ohnehin eher uninteressant, hier geht es um die Erfassung von Leads, die im Laufe der Verhandlung mit einem Kunden von einer Abschlusswahrscheinlichkeit von 25% auf irgendwann 100% steigen. Relevante Daten sind eher Leadstart (also Abgabe eines Angebots), voraussichtliches Leadende (als wann wird ein Auftrag draus), Auftragsdatum (falls es denn wirklich einer geworden ist) und Gewichtung (wie wahrscheinlich ist es, dass es zum Auftrag kommt .. 25, 50, 75% ? ). Der Kunde ist reduziert auf Namen und Ort, also sowas wie "Herder - Bonn". Es ist kein Massengeschäft. Im Sinne der Normalisierung müsste man da sicher aufteilen, aber wie gesagt ... es spielt hier keine Rolle, ich werde über diese DB niemals "alle Kunden aus 30159 Hannover" benötigen.
Punkt 2: In der Zentral-DB wird nur "geguckt" und ausgewertet, keine Änderungen vorgenommen.
Aber ich habe eine Sache entdeckt, die noch stört: im Replikats-Satz sind Tabellen bereits mit Informationen gefüllt (ein Grundstock an Bestandskunden in der Kundentabelle, Produktgruppenbezeichnungen und - in meinem Fall - auch schon einiges an Datensätzen über Leads. Die tauchen natürlich auch in der Replik auf. Bei Datensatzänderungen werden aber nur Änderungen synchronisiert, die in Datensätzen vorgenommen wurden, die nach Anlegen der Replik erstellt wurden. Ändere ich in der Replik einen der bereits zum Zeitpunkt der Replikerstellung vorhandenen Datensätze, synchronisiert sich das nicht zurück. Da bin ich gerade noch etwas verwirrt. Stimmt das?
Danke für weitere Antworten ... und Eure Geduld
Jo
Die Ort-Problematik war nur ein Beispiel für Eigenschaften, die von allen genutzt werden.
Denormalisierung ist da in der Tat hilfreich und entspannend.
ZitatIn der Zentral-DB wird nur "geguckt" und ausgewertet, keine Änderungen vorgenommen.
Da könnte man einen viel einfacheren Weg wählen: In jeder relevanten Tabelle gibt es ein Feld für einen Timestamp. Bei Änderung oder Neuanlage eines Datensatzes wird der Zeitstempel aktualisiert. Für den Abgleich werden die neuen Datensätze seit dem letzten Abgleich (Zeitpunkt gemerkt) in die Ziel-DB geschrieben bzw. in eine Zwischen-DB, die gepackt (und verschlüsselt) an die Zentrale geschickt wird, um dort importiert zu werden. Da reicht dann eine E-Mail.
Für diese unidirektionale Synchronisation braucht man dann keine Replikation, die nebenbei auch die DB-Größe erheblich erweitert, und GUID's (Strings) als ID's sind nun auch langsamer als die üblichen Ganzzahlen.
Man sollte da nur keine Autowerte verwenden (das kollidiert beim Empfänger), sondern normale eigenermittelte laufende Nummern sowie die AD-ID als zusammengesetzten Schlüssel.
MfGA
ebs
Also, wir werden die Datenbank erstmal auf dem Terminalserver einsetzen. Wenn dann mal ein gemapptes Laufwerk verfügbar ist, checke ich mal die Performance der Möglichkeit, lokale FEs einzusetzen.
Thema ist damit erstmal durch, habe interessante Sachen gelernt. Danke an die Runde!
Grüße,
Jo