Office: (Office 2003) DB Architektur per Remote Zugriff

Grundsätzlich ist es so, dass User auf der TS Session arbeiten aber da die DB auch etwas in die Richtung der Dokumentenverwaltung gehen soll, müssen eben die Dateien vom User auf den TS kopiert werden. Wie gesagt, das geht auch, da die User Laufwerke auf dem TS eingebunden sind. Nur ist eben das Problem, dass die User diese Dateien auf Ihrem Desktop abspeichern und man eben über die DB (FileDialog, FileCopy) nicht direkt auf den User Desktop zugreifen kann. Man muss den etwas aufwendigen Weg gehen sich im FileDialog durch die Verzeichnisse C:\... durchschlagen bis man auf den Desktop zugreifen kann, um die Datei, welche kopiert werden soll, zu wählen.

Eine Möglichkeit könnte sein, wie du schreibst

Das werde ich mal testen ob es diese Möglichkeit gibt.

Den Vorschlag von les habe ich nicht ganz verstanden.

P.S.
Ich weiß es passt nicht in diesen Beitrag. Aber Sascha, hast du schon Erfahrungen mit deinem OLE Connector und Office2007 gemacht? BTW in Office2003 setze ich den OLE Connector ein und es klappt super. Vielen Dank dafür.

 

Nur um es zu verstehen:
User logged sich am Terminalserver ein um dort eine Datenbank aufzurufen, von der dann wiederum auf den Client des Users zugegriffen werden soll.

Wenn da so ist, dann habe ich folgende Frage:
Wieso läuft die Anwendung (FrontEnd) nicht lokal und lediglich die Daten (BackEnd) liegen "zentral" und auf diese wird zugegriffen?

 

Die Idee hinter Frontend und Backend ist eben dieses Client/Server Prinzip.

Die Frage ist es: Warum verwendet Ihr TS und nicht Client für Euere Aufgaben? Oder besser formuliert, was ist das was man mit dem Client nicht machen kann dafür aber mit dem TS?

Wenn man das klar definiert hat, dann ergibt sich auf das Access Konzept von selbst.

Richti wäre es wie man es hier schon mehrmals gesagt hat, dass der Frontend auf jedem Client separat läuft und dass das Backend irgendwo auf einem Fileserver liegt. Noch bessere Variante ist ein Access Data Projekt wo der MS Access als Frontend verwendet wird und SQL Server als Backend. Das ist die sauberste Lösung!

Falls Ihr aus irgendwelchem Grund doch alles auf einem Server habt und von Clients aus über Terminalserver auf diesen Server zugreiffen wollt, dann würde ich nur ein Frontend für alle TS-User zur Verfügung stellen. Dies nur aus dem Update-Grund, weil wenn man mehrere MDE erstellen und verteilen muss dann passiert es schnell dass man einen User vergisst und dann ist es schon passiert, weil er eben mit alten Version arbeitet!

Genau das Problem mit Updates hat mich dazu bewegt diesen Applikationsmanager Programm zu entwickeln. Auf dem Entwicklungsserver habe ich meine ADPs/MDBs. Die kompiliere ich dann auf einem Fileserver zu ADE/MDE. Die Applikationsmanager Anwendung prüft dann vom Client aus, ob die gestartete ADE/MDE Datenbank auf dem Client älter ist und falls JA, wird sie auf den lokalen Laufwerk vom Fileserver kopiert. Ansonsten wird die bestehende Clientversion gestartet.

Gruss

 

Ja richtig, so ist es geplant. Allerdings sollte der Zugriff vom TS auf den User nur für den Transfer von Dateien in der Dokumentenverwaltung genutzt werden.

Momentan gibt es nur einen TS auf den über das Internet zugegriffen wird. Beim User kann ich, soweit ich weiß nicht den TS einbinden. Anders herum scheint es aber zu gehen. Die Laufwerke des Users werden im TS eingebunden. Ein weiteres Argument ist, dass es perfomanter sein soll, wenn die User direkt auf dem TS arbeiten und die Daten nicht über das Internet transferiert werden müssen.

Wie wäre des denn mit diesem Fileserver? Werden dort die Daten über das Internet übertragen oder ist das ein ähnliches Prinzip wie beim TS?

Das mit dem Fileserver, wie schon vorgeschlagen, scheint mir eine sehr gute und saubere und auch die vermutlich bessere Lösung zu sein. Also im Grund würde man dann anstatt des TS einen Fileserver verwenden, richtig?

Allerdings habe ich in diesem Bereich keinerlei Erfahrung und ich bin mir auch nicht sicher ob sich das lohnt hinsichtlich Kosten/Aufwand wenn man nur von ca. 5 Usern ausgehen kann von denen maximal zwei gleichzeitig zugreifen werden.

Was sind eure Meinungen?

 

Der Fileserver ist nur für das Filemanagement zuständig, aber du kannst auch jeden beliebigen Server dazu verwenden. Ihr habt sicher Shares (Netzwerklaufwerke) auf die jeder Benutzer zugreifen kann, oder? Falls Ja, dann kann man die Datenbank einfach mal dort in einem gemeinsamen Ordner platzieren.

Bei der MDB wo die Daten im Backend liegen ist natürlich Netzwerkbelastung höher wie auch bei einem ODBC Interface. Abhilfe schafft eben Access Data Projekt. Mit dieser (relativ neueren) Technologie kann man die Geschäftsabläufe auf die Datenbank übertragen. Beispiel:
- Wenn du etwa eine planungsliste anhand der Produktionsdaten erstellen musst, dann kannst Du die ganze Logik vollständig auf dem SQL Server abbilden. Wenn du es ohne SQL Server machst, dann musst du die logik in das Frontend implementieren. Das bedeutet dann zum Beipsiel dass alle 100 Arbeitsschritte mit ein paar Tausend Aufträgen zuerst einmal von deiner Backend MS Access Datenbank über Netzwerk transferiert werden sollen damit du anschliessend mit ein paar Schleifen entsprechende Planung automatisch erstellen kannst. Bei der SQL Server Variante läuft das alles auf dem Server (also keine Netzwerküberlastung) und anschliessend wird nur noch das Ergebnis zum Client gesendet (vielleicht ein paar Hundert Datensätze).
- Oder wenn Du z.B. Daten aus anderen Systemen brauchst etwa Active Directory oder Novell Directory, dann kannst du dir natürlich eine DLL besorgen, die dann deinem Frontend beibringt wie die LDAP Abfragen funktionieren, aber das bedeutet dann dass du diese Komponente auf jedem PC installieren musst! Noch schlimmer, wenn was ändert und deine DLL unbrauchbar ist, dann musst Du sie erneut erstellen usw. Wenn Du aber ein SQL Server verwendest, dann kannst Du über Verbindungsserver jede erdenkliche Connection sei es über ODBC oder einen Provider, herstellen. Der Client merkt nichts davon, er kriegt einfach sein Ergebnis, aber woher es kommt, weiss er nicht und es kümmert ihn auch nicht! Es ist also sicher viel einfacher einen SQL Server zu administrieren asl 100te von Clients, oder!

>ich bin mir auch nicht sicher ob sich das lohnt hinsichtlich Kosten/Aufwand

Das siehst du aber falsch. Erstens man weiss nie wie sich die Dinge entwickeln. Ich habe vor Jahren Applikationen erstellt aus den Megagrosse Projekte geworden sind. Da bin ich dann froh wenn schon von Anfang an alles richtig gemacht wurde. Es gibt natürlich noch ältere Applikationen wo das nicht der Fall ist (sei es weil ich unerfahren war oder weil es entsprechende Technologien gar nicht gab) und jetzt ist eine Migration extrem schwierig!

Es kommen noch weitere Aspekte. Du stellst dir aber sicher nicht vor dein ganzes Leben in der Firma zu verbringen, oder es kann aber auch sein, dass sie schliessen müssen. Dann bist du aber froh wenn du entsprechende Erfahrungen hast und gerade Server/Client Geschichte ist etwas was man in jedem Bereich der Informatik anwenden kann. Dazu kommen noch die Microsoft Technologien im Spiel, die einem sehr grossen Vorteil schaffen falls er sie beherscht!

Also nur ran an den Cheff und erklär ihm, dass man es doch etwas besser machen kann. Dann besorge dir ein paar Tutorials oder Bücher und stell die Sache richtig auch wenn "Kosten/Aufwand" nicht gerade toll ist.

Gruss

 

Zwei Richtigstellungen:
- Netzwerkbelastung ist bei ODBC und ADP die gleiche, wenn man unter ODBC-Anbindung nicht lediglich das Verknüpfen von Tabellen versteht, sondern Abfragen auch als Views oder PT anlegt und SPs verwendet.
- "Neu" ist ADP sicherlich nicht (1999) - im Gegenteil, MS rückt selbst davon ab. Unter A2007, welches ElBirn offenbar verwendet oder in Zukunft verwenden will, läuft ADP zwar noch, man muss dafür aber auf diverse Features von ACCDBs verzichten. Darauf würde ich in punkto Zukunftssicherheit also gerade nicht setzen.

Zum TS noch... Einen Vorteil hat der natürlich schon: Die Frontends greifen da normal direkt auf das BE auf der Maschine zu, weshalb die Performance wesentlich besser ist, als bei Multiuser-Betrieb über Netzwerk.

Ciao, Sascha

 

Hallo,
@ ALL scheint ja ein tolles Thema zu sein?

@ dito Sascha


1, ich hoste eine 15 Client Umgebung Lizenz probs gibt es nur bei windows
und nicht bei ACC
2. Mein Hinweis war ja nur das jeder USER sich selber ne Verknüpfung zu seinem Destop vis ts selber anlegen kann um das mögliche Datenschaufeln zu vereinfachen
3. wenn man von Netgear ~S232 benutzt gibt es dort die Möglichkeit Port Forwarding zur Verbindung zu installieren und kann damit richtige Netz Lw Verbindungen erstellen.

DAS Funzt nu wirklich gut.......


Grüße Olaf

 

\@Sascha Trowitzsch
>Netzwerkbelastung ist bei ODBC und ADP die gleiche...
Ich habe geschrieben dass man die Geschäftslogik viel besser auf dem SQL Server implementieren kann als dass man sie auf dem Frontend realisiert und somit unnötig den Netzwerk belastet (lese bitte das Beispiel, das ich angegeben habe).

>"Neu" ist ADP sicherlich nicht (1999)...
Ich hab ja auch geschrieben RELATIV NEUERE TECHNOLOGIE. Das ADP wurde bereits mit Access 2000 eingeführt, wobei es erst mit MS Access XP (also ein paar JAhre später) wirklich aktuell wurde.

1. Kannst Du etwas mehr über ElBirn schreiben, weil es kommt mir unbekannt vor?
2. Auf welche Features von ACCDBs muss man dann in Access 20007 verzichten?

>weshalb die Performance wesentlich besser ist, als bei Multiuser-Betrieb
>über Netzwerk...
Das stimmt so nur wenn die Anzahl TS Users nicht viel grösser ist als Anzahl Access Users, ansonsten belasten deine TS den Netzwerk viel stärker als wenn ein paar Mitarbeiter die Server Access DB vom Client aus verwenden würden.

Gruss.

 

\@les:

Den Satz hab ich nicht verstanden.

Na z.B. auf Sharepoint-Anbindung, weil die bloß mit verknüpften Listen funktioniert - falls man das nicht alles ausprogrammieren möchte. Oder sonstige verknüpfte Tabellen (z.B. Excel).
Oder Anlage-Felder & -Steuerelemente, die man für Bilder und/oder Dokumentspeicherung m FE verwenden könnte.

Es ist halt so, dass nur sehr wenige Profis ADPs verwenden und meist auf ODBC setzen. Das wird wohl einen Grund haben.
Ich habe mich etwa auf MySQL-Backends spezialisiert und da nützen mir ADPs nichts - man ist auf Gedeih und Verderb dem MSSQL-Server ausgeliefert.

Ciao, Sascha

 

\@Sascha Trowitzsch

Du hast geschrieben:

Ich verstehe deinen Satz so als ob es eine neue Technologie Namens ElBirn geben wird/oder bereits gibt. Da ich zu dem Thema im Internet nichts finden konnte und selber noch nie was davon gehört habe, frage ich dich einfach mal ob du uns das etwas genauer erklären könntest. Ein Link zu der entsprechenden Microsoftseite wäre sicher noch vom Vorteil. Danke im Voraus.

Soweit es mir bekannt ist man konnte in einem ADP Projekt nie etwas anderes verknüpfen als die Tabellen von der SQL Datenbank!

Bist du dir das ganz sicher? Die empfehlung von Microsoft ist klar ein ADP zu verwenden und der Lösung einer ODBC Anbindung der Daten vorzuziehen (natürlich vorausgesetzt man braucht eine Server/Client Applikation).
Ein Grund ist auch, dass Access mit ODBC für den Einsatz im WLAN oder in heterogenem Netzwerk wegen statusgebundenen Zugriffstechnologie über das Dateisystem nicht geeignet wäre.
Die sogennante 'Profis', die MS Access weiterhin so brauchen wie vor 15 Jahren (also mit ODBC) machen das sehr wahrscheinlich weil sie mit MS SQL nicht klar kommen.

 

ElBirn ist ein User hier im Forum. Sogar hier im Thread. Sogar als Eröffner desselben. Ich glaube er hätte was dagegen, wenn er ins nächste Access-SP reinkäme

*rotflmao*

*yelrotflmao

 

\@les:

Siehe
http://technet.microsoft.com/en-us/l.../cc178973.aspx
Dort unter "Access 2007 and SQL Server":
"The preferred way to connect to SQL Server is MDB file format or ACCDB file format. This enables you to use the full flexibility of local tables and local queries, while leveraging the full power of SQL Server. In addition, MDB and ACCDB files link to multiple SQL Servers and a wide variety of other data sources. Office Access 2007 contains many new features available in both MDB and ACCDB file formats, but only a subset of those features are available in ADPs."

Der Begriff ist nicht korrekt. In einem ADP werden keine Tabellen "verknüpft".

Ich verstehe nur Bahnhof. Was soll an ODBC eine "statusgebundene Zugriffstechnologie über das Dateisystem" sein??

Mir schwant langsam, dass dir nicht klar ist, was ODBC überhaupt ist. Kann das sein?

Bist du dir das ganz sicher?

JA.

Ciao, Sascha

 

Schade, dass Microsoft in der letzten Jahren bei der Produktentwicklung nur auf Umsatz schaut.
Die Idee beim ADP ist, dass man MS SQL als Middleware verwendet wird. Klar kann man dann aus der ADP/ADE nicht mehr eine ODBC Verbindung zu einer anderen Datenquelle herstellen, aber wenn das möglich wäre, dann würde das dem Middleware Prinzip wiedersprechen! Richtig macht man es eben über MSSQL Verbindungsserver.

Also wenn man richtig programmieren will, dann ist ADP die beste Lösung. Das Problem ist, dass viele Leute gewönt sind Kreuz und Quer Verbindungen zu erstellen. Mal braucht man eine Excel Tabelle, die schnell verlinnkt werden soll, mal eine Textdatei, mal eine ODBC Verbindungsabfrage zu Oracle usw. Man verkompliziert schliesslich eine Datenbank so dass jede Pflege weit viel Zeit in Anspruch nimmt als die ursprüngliche Entwicklung.

Access benötigt eine unterbrechungsfreie Verbindung zum Server (falls von diesem aus gestartet). Bei ADP sind dann Daten nicht mehr auf einem Fileserver sondern in der MS SQL Datenbank. Mehr Infos findest du im Google.

Gruss

 

Bei ODBC sind dann Daten nicht mehr auf einem Fileserver sondern in der MS SQL Datenbank. Mehr Infos findest du im Google oder wikipedia.

Ciao, Sascha

 

.... adp, odbc, ms sql, fileserver, ade, accdb, ts, und sogar ElBirn *dance

Leider sagt mir das meiste gar nichts von dem Ihr gesprochen habt. Ich werde auf jeden Fall mal google und wiki nutzen und mich auf den aktuellen Stand bringen. Hatte bisher immer nur kleine Projekte in der eine .mdb als BE auf einem Server im LAN lag und die Clients eine .mde als FE. Mit den anderen Technologien/Methoden muss ich mich erst mal vertraut machen.

Wäre auch super wenn jemand mit ein paar einfachen Worten das ganze erklären könnte *Smilie