none
DFS auf 2008R2 mit MS-Access 2003 RRS feed

 > 

  • Frage

  • Question
    Anmelden
    0
    Anmelden

    Hallo zusammen.

    Ich stehe hier gerade mit einer Softwarefirma im "clinch". Die Frage ist, ist es möglich eine MS-Access basierende Applikation über ein DFS Share zu betreiben? Hintrergrund ist folgender. Nach dem neubau unserer Domäne haben wir sämtliche Shares über DFS veröffentlich. Eine Anfrage beim Softwarelieferanten ergab, "Es gibt keine Einwände.". Nun lief die Anwendung gerade mal drei Tage, da bekam ich die Rückmeldung, dass bereits erfasste Daten weg seien. Ein Blick in das DFS und in das gemapte Laufwerk zeigte folgendes.

    Freigabe 1 (am Server 1) und Freigabe 2 (am Server 2) zeigtenn auf den Datenträgern jeweils die gleiche Version der MDB Datenbank. So wie es sein soll.
    Das gemapte Laufwerk zeigte eine ca. zwei Stunden ältere Version an!  Woher die kommt, keine Ahnung. Dieses ergebniss ergab sich aber an allen beteiligten "Clients", (Es sind nur zwei, da es sich um Terminalserver handelt) war also reproduzierbar. Angabe von der Softwarebude. Das liegt am DFS. Das muss raus.

    Da ich erst einmal kein argument hatte, habe ich nun nur noch den ersten Share vom ersten Server gemapt. Das DFS läuft noch. Hierbei sind aber anscheinend Daten verloren gegangen.

    Nun zu meiner Frage. Ist es überhaupt möglich eine MS-Acess Datenbank im DFS Share zu betreiben? Wenn ja, welche änderungen muss ich am Share vornehmen um die Daten der Clientlaufwerke und im Share konsistent zu halten?

    Ach ja, Mappen tue ich die Laufwerke via VBScript, falls das noch irgendwie eine Rolle spielt.

    Danke für eure Hilfe schon einmal.

    MFG
    Steffen

    Sonntag, 12. Dezember 2010 15:37
    |

Antworten

  • Question
    Anmelden
    0
    Anmelden

    * Der Rosenloecher (Sun, 12 Dec 2010 15:37:20 +0000)

    Ich stehe hier gerade mit einer Softwarefirma im "clinch". Die Frage
    ist, ist es möglich eine MS-Access basierende Applikation über ein DFS
    Share zu betreiben?

    Geht's ein bißchen genauer? DFS Namespaces oder DFS Replication? Im ersten Fall: ja, sicher. Im zweiten Fall:

    "Can DFS Replication replicate [...] Microsoft Office Access database files?

    [...] Access files that are accessed across a network can cause DFS Replication to become unstable or fail. DFS Replication can safely replicate [...] Access files only if they are stored for archival purposes and are not accessed across the network using [...] Microsoft Office Access (copy the files to a local storage device before opening them)."

    Freigabe 1 (am Server 1) und Freigabe 2 (am Server 2) zeigtenn auf den Datenträgern jeweils die gleiche Version der MDB Datenbank. So wie es sein soll.
    Das gemapte Laufwerk zeigte eine ca. zwei Stunden ältere Version an!  Woher die kommt, keine Ahnung. Dieses ergebniss ergab sich aber an allen beteiligten "Clients", (Es sind nur zwei, da es sich um Terminalserver handelt) war also reproduzierbar. Angabe von der Softwarebude. Das liegt am DFS. Das muss raus.

    Da ich erst einmal kein argument hatte, habe ich nun nur noch den ersten Share vom ersten Server gemapt.

    Das heißt, die Benutzer haben gleichzeitig auf zwei Freigaben an beiden Datenbanken gearbeitet? Das klingt wie ein klassischer Fall für "When shouldn't I use DFS Replication?"[2]...

    Wenn ja, welche änderungen muss ich am Share vornehmen um die Daten
    der Clientlaufwerke und im Share konsistent zu halten?

    Ich hoffe zumindest du weißt, was ein "Clientlaufwerk" ist und wo der Unterschied zu einem Share sein soll.

    Thorsten
    [1] <http://technet.microsoft.com/en-us/library/cc773238
    (WS.10).aspx#BKMK_050>
    [2] <http://technet.microsoft.com/en-us/library/cc773238
    (WS.10).aspx#BKMK_051>

    Sonntag, 12. Dezember 2010 16:46
    |

Alle Antworten

  • Question
    Anmelden
    0
    Anmelden

    * Der Rosenloecher (Sun, 12 Dec 2010 15:37:20 +0000)

    Ich stehe hier gerade mit einer Softwarefirma im "clinch". Die Frage
    ist, ist es möglich eine MS-Access basierende Applikation über ein DFS
    Share zu betreiben?

    Geht's ein bißchen genauer? DFS Namespaces oder DFS Replication? Im ersten Fall: ja, sicher. Im zweiten Fall:

    "Can DFS Replication replicate [...] Microsoft Office Access database files?

    [...] Access files that are accessed across a network can cause DFS Replication to become unstable or fail. DFS Replication can safely replicate [...] Access files only if they are stored for archival purposes and are not accessed across the network using [...] Microsoft Office Access (copy the files to a local storage device before opening them)."

    Freigabe 1 (am Server 1) und Freigabe 2 (am Server 2) zeigtenn auf den Datenträgern jeweils die gleiche Version der MDB Datenbank. So wie es sein soll.
    Das gemapte Laufwerk zeigte eine ca. zwei Stunden ältere Version an!  Woher die kommt, keine Ahnung. Dieses ergebniss ergab sich aber an allen beteiligten "Clients", (Es sind nur zwei, da es sich um Terminalserver handelt) war also reproduzierbar. Angabe von der Softwarebude. Das liegt am DFS. Das muss raus.

    Da ich erst einmal kein argument hatte, habe ich nun nur noch den ersten Share vom ersten Server gemapt.

    Das heißt, die Benutzer haben gleichzeitig auf zwei Freigaben an beiden Datenbanken gearbeitet? Das klingt wie ein klassischer Fall für "When shouldn't I use DFS Replication?"[2]...

    Wenn ja, welche änderungen muss ich am Share vornehmen um die Daten
    der Clientlaufwerke und im Share konsistent zu halten?

    Ich hoffe zumindest du weißt, was ein "Clientlaufwerk" ist und wo der Unterschied zu einem Share sein soll.

    Thorsten
    [1] <http://technet.microsoft.com/en-us/library/cc773238
    (WS.10).aspx#BKMK_050>
    [2] <http://technet.microsoft.com/en-us/library/cc773238
    (WS.10).aspx#BKMK_051>

    Sonntag, 12. Dezember 2010 16:46
    |
  • Question
    Anmelden
    0
    Anmelden

    Hallo Thorsten.

    Danke erst einmal für die Antwort. Ich fasse das mal zusammen.

    zu 1.: Wenn du Fragst, was ich meine (Namespace oder Replication), dann kann ich dazu nur sagen, das das für mich alles eine Einheit ist. Was nützt mir ein DFS innerhelb eines Standortes, wenn die Replikation nicht vorhanden ist?

    zu 2.: So habe ich das DFS bisher immer eingesetzt. Zwei Server die Ihre Freigabe einem DFS zur Verfügung stellen. Diese DFS Freigabe (Namespace) via Script als lokales Laufwerk für den Nutzer gemappt (wshNetwork.MapNetworkDrive). Das hatt ja für mich den Vorteil (mit anderen Office Dateien zumindestens ohne Probleme), das ich einen Server auch mal zu Wartungszwecken Rebooten kann (oder dergleichen). In der Umgebung sollen ja alle auf einer (Hilfs-)Datenbank arbeiten. Die Anwendung ist momentan so geschrieben. Nen SQL Server wäre mir auch lieber.

    zu 3.: Ja ich habe schon einen Plan von dem was ich da mache! Nur wenn ich einem Lieferanten eine Frage stelle, weil es ja seine Applikation ist, und dieser mir eine Antwort gibt, die sich nachher als fehlerhaft herrausstellt, dann nerft das. Da ich hauptsächlich Datenbanken einsetze, habe ich sicher nicht den Plann von Access. Aber ich möchte hier einen alten Lehrer von mir Zitieren. "Du kanns selbst einem Geschichtslehrer beweisen, das er in Geschichte ein Depp ist. Du must nur das richtige Jarhundert finden!"

    Fazit: Ich kann den Share erst einmal im Hintergrund laufen lassen, muss allerdings das Laufwerksmapping dediziert auf eine Freigabe eines Servers einrichten! Ein Grund mehr, sich nicht weiter mit Access zu beschäftigen.

    MFG
    Steffen

    MFG Steffen
    Montag, 13. Dezember 2010 08:37
    |
  • Question
    Anmelden
    0
    Anmelden

    * Der Rosenloecher (Mon, 13 Dec 2010 08:37:14 +0000)

    zu 1.: Wenn du Fragst, was ich meine (Namespace oder Replication),
    dann kann ich dazu nur sagen, das das für mich alles eine Einheit ist.
    Was nützt mir ein DFS innerhelb eines Standortes, wenn die Replikation
    nicht vorhanden ist?

    Fang mit [1] an. Die Hilfe zu DFS (dfsmgmt.msc) ist auch nicht schlecht. Wenn du das gelesen hast, weißt du zumindest grob, was DFS ist, macht und wozu es gut ist und wo der Unterschied zu DFSR oder FRS ist.

    zu 2.: So habe ich das DFS bisher immer eingesetzt. Zwei Server die Ihre Freigabe einem DFS zur Verfügung stellen. Diese DFS Freigabe (Namespace) via Script als lokales Laufwerk für den Nutzer gemappt (wshNetwork.MapNetworkDrive). Das hatt ja für mich den Vorteil (mit anderen Office Dateien zumindestens ohne Probleme), das ich einen Server auch mal zu Wartungszwecken Rebooten kann (oder dergleichen).
    zu 3.: Ja ich habe schon einen Plan von dem was ich da mache!

    Das glaube ich dir. In deinem Falle willst du wohl Redundanz erreichen. Dafür gibt es andere (vielleicht bessere) Wege - Cluster zum Beispiel.

    Das eigentliche Problem ist, daß du sicherstellen mußt, daß Daten nicht an zwei Stellen gleichzeitig geändert werden (DFSR an sich scheint dies nicht sicher zu stellen). Wenn dies eintritt wird die Datei nach DfsrPrivate\ConflictandDeleted verschoben und das ist meiner Meinung nach geschehen.

    Nur wenn ich einem Lieferanten eine Frage stelle, weil es ja seine
    Applikation ist, und dieser mir eine Antwort gibt, die sich nachher
    als fehlerhaft herrausstellt, dann nerft das.

    Du meinst die Antwort, daß DFS(R) das Problem sei? Genau das ist es doch.

    Da ich hauptsächlich Datenbanken einsetze, habe ich sicher nicht den
    Plann von Access.

    Access ist eine Datenbank. Nur nicht Client/Server. Und das ist das Problem.

    Fazit: Ich kann den Share erst einmal im Hintergrund laufen lassen, muss allerdings das Laufwerksmapping dediziert auf eine Freigabe eines Servers einrichten! Ein Grund mehr, sich nicht weiter mit Access zu beschäftigen.

    Es sollte eher ein Grund sein, sich mit DFS(R) zu beschäftigen. Das Thema ist kompliziert. Und du wirst auch mit anderen Daten Probleme haben (Profile zum Beispiel).

    Thorsten

    Montag, 13. Dezember 2010 11:07
    |
  • Question
    Anmelden
    0
    Anmelden

    * Thorsten Kampe (Mon, 13 Dec 2010 11:07:34 +0000)

    Fang mit [1] an.

    [1] http://en.wikipedia.org/wiki/Distributed_File_System_(Microsoft)

    Thorsten

    Montag, 13. Dezember 2010 11:32
    |