Neuigkeiten:

Wenn ihr euch für eine gute Antwort bedanken möchtet, im entsprechenden Posting einfach den Knopf "sag Danke" drücken!

Mobiles Hauptmenü

Abwechselnde Backenddatei verwenden

Begonnen von 69bruno, September 13, 2012, 15:06:28

⏪ vorheriges - nächstes ⏩

69bruno

 :)

Hiho Gemeinde.....
Ich habe da so eine Datenbank, die ich in eine Front- und Backenddatei aufgeteilt habe.
An dieser arbeitet die Kollegin sowohl im Haus über LAN, als auch von zu Hause über einen VPN-Tunnel.
Leider ist dieser sehr sehr wackelig und vergißt schon mal, dass er Netzlaufwerke besitzt  >:(
Nun habe ich vorübergehend die Lösung umgesetzt, dass sie auf ihrem Rechner zu Hause eine lokale Version der Forntend hat und sich die Backend morgens runterlädt und nachmittags in das Firmennetzwerk zurücklädt.
Eine Aktualitätskontrolle (modifieddate) führe ich dabei auch aus, damit sie nicht plötzlich in einer alten Version arbeitet, wenn sie das hin- und herladen mal vergisst.
Aber diese Lösung will mir nicht gefallen.

Gibt es da vielleicht einen besseren Ansatz ?
Mal ins unreine gedacht, könnte Sie grundsätzlich in einer lokalen db arbeiten und diese fügt auf Kommando alle neuen Daten der Netzwerk-db hinzu ? oder wäre das auch zu kompliziert ???
If Brain <= requestoutofPost then
  PostonForum "Ich verstehe Dein Problem nicht....."
Else
  PostonForum "Denk erst mal über die Normalisierung nach......"
End If

DF6GL

Hallo,

das mit dem Zurückkopieren ist aber eine untragbare Situation.....   Damit überschreibst Du doch die Daten, die die Kollegen im LAN-Backend währenddessen bearbeitet haben...

Sinnvollster Zustand wäre, mittels Terminalserver/Client über den VPN-Tunnel auf einem User-Account auf dem Server zu arbeiten. Dann liegt das FE in diesem Account für den User "lokal" vor und kann mit dem Original-BE anstandslos zusammenarbeiten.


Statt verschiedene User-Accounts auf einem Server zu betreiben, könnte auch für jeden ext. User ein PC im LAN bereit gestellt werden, auf den der jeweilige User über den VPN-Tunnel mittels der Remotedesktopverbindung zugreift und dort sein lokales FE betreibt.

69bruno

Oh, sorry, zu undeutlich von mir...

es ist immer dieselbe Kollegin. (Und die kann sich zum Glück noch nicht teilen  ;) )

Das mit dem Frontend über Tunnel auf Backend gehen, klappt ja leider nicht, weil die IT keinen stabilen Tunnel liefert. Wenn das Netzlaufwerk am Ende des Tunnels (witzige Formulierung) im laufenden Betrieb plötzlich verschwindet, habe ich Angst, dass die Backend beschädigt wird.
If Brain <= requestoutofPost then
  PostonForum "Ich verstehe Dein Problem nicht....."
Else
  PostonForum "Denk erst mal über die Normalisierung nach......"
End If

DF6GL

HAllo,

Du hast vermutlich falsch verstanden...


1) ob eine oder mehrere Kollegen/innen, ist völlig egal, Du überschreibst (zerstörst)  ganz einfach deren Arbeit...

2) Du greifst nicht mit dem FE über den Tunnel auf das BE zu, sondern die Remotedesktopverbindung (oder halt der Teminalserver-Client, was ja hier dasselbe bedeutet) zeigt Dir lediglich den "Monitor" des im LAN befindlichen User-Accounts , bzw. den Monitor des User-PCs.  (Die anderen Peripheriegeräte -- Tastatur, Drucker, etc-- lass ich hier mal außen vor..)  Wenn der Tunnel zusammenbricht, dann hast Du lediglich keinen Zugriff mehr auf das FE, das aber dadurch nicht abstürzt, sondern normal "weiterläuft", d. h. auf Deine Zugriffe (Eingaben)  wartet, bis die VPN-Verbindung wieder hergestellt ist.


"weil die IT keinen stabilen Tunnel liefert"

na, dann mach der halt mal Dampf unter dem Hintern...  ;)  wenn es deren "Verschulden" sein sollte.  Andere Hindernisse gibt es natürlich, z. B. lahmes oder instabiles DSL an sich..  Da kann man dann weniger machen..



69bruno

Ok,

jetzt habe ich es....... Mein Themenbetreff ist falsch. Es ist natürlich immer eine Backend, die bearbeitet wird. Nur wird der Speicherort zu Beginn des Arbeitstages geändert, indem sie hin- und herkopiert wird. (Schwitz)

Das mit dem Client/Server Modell werde ich mal bei der IT anlangen.

Das Problem mit dem instabilen Tunnel ist echt blöd. Unsere IT kann nichts machen, da der Tunnel von einer anderen Firma "gehostet" wird. Der Weg ist über mein (geprüftes und stabiles DSL mit nahezu 6000er Datengeschwindigkeit) zu der Fremdfirma (über VPN) und dort über den Server in ein Konglomerat von Netzverbindungen zu unseren Servern im Haus. Diese Dreiecksbeziehung ist äußerst kompliziert, da beide Häuser eigene Sicherheitsvorschriften haben und vor kurzer Zeit (nur zum Beispiel) herausgefunden wurde, das von der Fremdfirma ein Protokoll verwendet wird, welches bei uns untersagt ist.......... tolle Kiste

So, jetzt nerve ich unsere IT mit dem Client/Server Modell.....

If Brain <= requestoutofPost then
  PostonForum "Ich verstehe Dein Problem nicht....."
Else
  PostonForum "Denk erst mal über die Normalisierung nach......"
End If

69bruno

Oho  :-\

IT schlägt vor, die Access-Backend-db in eine SQL-Datenbank abzuwandeln, dann wäre die Gefahr des Datenverlustes gering.

Aber meine Frage, ich habe einen Bericht in der db (FE) mit etwa 40 Domänenaggregatfunktionen.......können die Funktionen auch auf der Grundlage der SQL db rechnen ? Oder gibt es da andere Beeinträchtigungen ? Habe ausser einer mysql-Geschichte auf einer Website noch nie eine größere SQL-db gebastelt......
If Brain <= requestoutofPost then
  PostonForum "Ich verstehe Dein Problem nicht....."
Else
  PostonForum "Denk erst mal über die Normalisierung nach......"
End If

DF6GL

Hallo,


"dann wäre die Gefahr des Datenverlustes gering"   

das hat aber weniger mit Deinem VPN-Problem zu tun....


Wenn die DB keine Tricksereien und Unzulänglichkeiten bezgl. der Normalisierung hat , kann man wohl mal versuchen, die Tabellen nach ein paar Anpassungen (--> TimeStamp-Felder) auf den MSSQL-Server zu migrieren und mittels ODBC die Tabellen im FE einzubinden.    Die Vorzüge einer aktiven Datenbank-Engine sind aber ohne Anpassung des FEs nicht zu erreichen.             



"mit etwa 40 Domänenaggregatfunktionen"    erscheint mir aber doch etwas viel...  Würde da an der o. g. Normalisierungs-Voraussetzung zweifeln wollen, ich kenne aber ja die Hintergründe im Detail nicht.

Stapi

Hallo Bruno

Der @Jonny hier im Forum berichtet in einem Beitrag das er sein Frontend als Acces Version 2007  läuft und sein Bachend als Access 2003 Replikat lauft. Das Replikat hat den Vorteil das mann die Daten der einzelnen Dateien Synchronisieren kann ohne eventuellen Datenverlust oder Überschreiben einer Datei.
Grüße aus dem schönen NRW
Stefan

69bruno

Danke für den Tip, werd ich mir mal ansehen
If Brain <= requestoutofPost then
  PostonForum "Ich verstehe Dein Problem nicht....."
Else
  PostonForum "Denk erst mal über die Normalisierung nach......"
End If

69bruno

Wow, ich habe da mal den Beitrag von @Johnny gesucht und bin in einem begeisternden Thread gelandet, der Access bewertet, mal gut, mal schlecht.  :o

Den Bericht über Replikate habe ich leider nicht gefunden. Kannst Du mir den Betreff des Threads nennen ?
If Brain <= requestoutofPost then
  PostonForum "Ich verstehe Dein Problem nicht....."
Else
  PostonForum "Denk erst mal über die Normalisierung nach......"
End If

Wurliwurm

Zitat von: 69bruno am September 13, 2012, 16:45:33
IT schlägt vor, die Access-Backend-db in eine SQL-Datenbank abzuwandeln, dann wäre die Gefahr des Datenverlustes gering.

Das halte ich für eine sehr gute Idee von den IT-Profis, weil dann auch die Netzbelastung gering wird und gute Antwortzeiten auch bei geringer Bandbreite zu erwarten sind. Stabiler und sicherer wird die Sache auch. Ein Datenbanksystem hat eigentlich nur Vorteile gegenüber einem Access-Backend, wenn mehrere Leute gemeinsam an einer DB arbeiten müssen. Die Nachteile liegen darin, daß es aufwendiger und professioneller wird und mehr technischen Sachverstand verlangt, aber Hexerei ist es nicht.

Ich würde ADO als Verbindungstechnik nehmen statt ODBC.

Zitat
Aber meine Frage, ich habe einen Bericht in der db (FE) mit etwa 40 Domänenaggregatfunktionen.......können die Funktionen auch auf der Grundlage der SQL db rechnen ?

Wahrscheinlich nicht. Ein komplexes Problem kriegt man dadurch in den Griff, indem man es in kleinere einfachere Probleme zerlegt. Ich mache das Berichten eigentlich immer so, daß ich von der Datenbank in eine lokale temporäre Tabelle einlese (diese Zwischentabelle im lokalen Access-Client dient nur als Datenquelle für einen oder mehrere Berichte und Normalisierung spielt hier absolut keine Rolle und wäre sogar kontraproduktiv) und als Datenquelle für den/die Reports lokale Abfragen auf die Zwischentabelle mache. Der Zwischenschritt mit dem Einlesen in die Zwischentabelle wird wegen der leistungsfähigen Datenbank und der geringeren Netzbelastung wahrscheinlich viel schneller gehen als Abfragen auf ein Access-Backend im Netz. (Diese ganzen Halb-DAU-Krücken wie Tabellen verknüpfen, "Access-Projekte" o.ä. solltest m. E. Du lieber vergessen und rein mit eigenen SQL-Kommandos auf der ADO-Schnittestelle arbeiten)

Stapi

Grüße aus dem schönen NRW
Stefan

69bruno

@Stapi: Danke für den Link, werde ich mir ansehen.

@wurliwurm: Das bedeutet dann wohl für mich, alle Aggregatfunktionen neu und anders umzusetzen, oder ?

Das wäre schon hart.  :o

Oder ist das so zu verstehen, dass ich die Tabellen, sofern ich sie 1:1 (bis auf Timestamp) in das SQL reinbekomme für den Bericht (der nur einmal im Jahr ausgeführt wird) die Daten wieder in die Backend zurückführe und meinen Bericht dann erzeugen lasse ?

Das wäre weniger hart......  8)
If Brain <= requestoutofPost then
  PostonForum "Ich verstehe Dein Problem nicht....."
Else
  PostonForum "Denk erst mal über die Normalisierung nach......"
End If

Wurliwurm

Zitat von: 69bruno am September 14, 2012, 13:39:19
Oder ist das so zu verstehen, dass ich die Tabellen, sofern ich sie 1:1 (bis auf Timestamp) in das SQL reinbekomme für den Bericht (der nur einmal im Jahr ausgeführt wird) die Daten wieder in die Backend zurückführe und meinen Bericht dann erzeugen lasse ?

Also ich mache das mit Reports immer so (vielleicht gibt es bessere Wege), daß ich die Daten per ADO/VBA/SQL ziehe in lokale Tabelle(n) und dann die Reports so erstelle, als ob die Daten schon immer auf dem lokalen Access gewesen wären. Die Abfragen aus der Datenbank brauchen nur Sekundenbruchteile.

Schreiben in die Datenbank tue ich nur mit ADODB.Commands (INSERT, UPDATE, DELETE)

Auf diesem Weg hat Du das beste aus zwei Welten.

Wie komplex die Aggregatfunktionen sind, weiß ich nicht, aber wenn die auf die lokalen Tabellen passieren, dann müßte das passen.

69bruno

Und so ist ein Versuch geboren.......

werde mich, aber das wird etwas dauern, mit dem Ergebnis melden.........
If Brain <= requestoutofPost then
  PostonForum "Ich verstehe Dein Problem nicht....."
Else
  PostonForum "Denk erst mal über die Normalisierung nach......"
End If