Office: (Office 2003) DB Architektur per Remote Zugriff

Ein klares Jein *Smilie
Wenn Du vom Terminalserver aus auf den UserPC zugreifen kannst (UNC-Pfad, etc.) und diesen identifizieren kannst, sollte es möglich sein.

 

Notfalls könnte man den Dateitransfer durch einen Webserver (HTTP-Upload) oder per FTP bewerkstelligen, wenn keine UNCs verfügbar sind.

HTH

 

Puuh, ganz schön kompliziert.

Ich werde mir mal einen Zugang zu dem Server verschaffen damit ich das mal testen kann.

Ich melde mich dann noch mal.

Vielen Dank für eure Hilfe!

 

Hallo,
ich habe beste Erfahrungen damit gemacht!

Bei mir ist folgende Situation eingerichtet!
Ein TS- als FileServer mit SQL2005 + 1 TS als Anwender Server + 10 HPClints die Remote auf den Anw TS zugreifen.
Meine Software ist in ACC 2007 in einem Verzeichnis aus dem File Server und greift per ODBC auf die Serverdaten zu.
Ich binde meine Rechnungen und ScanneWare in verschiedenste Verzeichnisse ein und Verlinke inerhalb meines Programmes, damit ich die DB nicht unnötig aufpuste.
Über den File Server kann man dann noch Benutzerrecht vergeben! usw.
Klappt eigentlich bis auf die Monatlichen Updates von MS super gut!

Hoffe es hilft ! und war einigermaßen verständlich!

Olaf

 

Hallo Olaf,

also wenn ich dich richtig verstehe hast du:

- einen TS als FileServer mit SQL2005 auf dem das BE der Daten liegt und die Verzeichnisse für deine Rechnungen etc. (in der DB legst du nur den Pfad ab)
- einen TS als Anwender Server auf dem das FE liegt
- 10 Clients die auf den TS Anwendungsserver, sprich auf das FE zugreifen

richtig?

Wie kommen aber nun die Dokumente von Rechner der Clients auf den File Server? Geht das ohne FTP oder HTTP Upload?

 

Hallo,
BE ist bei mir = SQL Server wegen der Geschwindigkeit.
Aus Sicherheitsgründen haben wir noch von netgear eine remote box dazwischen, aber die klammer mal aus.
Es ist recht einfach unter Remote kannste deine Arbeitfestplatten vom Client mit einbinden und so hast du nach allen Richtungen Zugriff als Anwender.

Grüße Olaf

schau es dir doch mal bei dir an

%systemroot%\system32\mstsc.exe

 

Hallo Olaf,

ich habe immer noch keine Zugriff zum Server des Kunden. Die wissen selbst nicht so genau was sie haben :-)

Ich meld mich sobald ich Zugang bekommen habe!!

Gruß

 

Ruf die Mal an die müssen im IE
www.IP-Adress.com eingeben dann erhalten die zb. 77.178.4.239/ 175.168.1.1 das ist deren interne IP
das in den Remotedesktop eintragen und los geht es, grundvorausetzung Remote ist erlaubt, Benutzer ist angelegt.

olaf

 

Danke für den Tip!

Hab jetzt mal Zugriff zum Server bekommen und ich bin fürs erste angenehm überrascht worden.

Habe zum testen ein 200 MB Backend mit über 100 Tabellen und eine FE mit 30 MB auf den Server gespielt. Die Geschwindigkeit ist echt in Ordnung. Natürlich nicht wie im LAN aber man kann durchaus damit arbeiten. Darüber hinaus werden sogar die lokalen Drucker und Laufwerke in die Session auf dem Server eingebunden und Farben werden auch alle korrekt dargestellt.

Somit kann ich den Dateitransfer auch einfach abbilden, da ich auf dem Server meine Laufwerke eingebunden habe und somit auf meinen Rechner Zugriff habe.

Das einzige was etwas nervig für die User werden könnte ist, dass man nicht direkt auf seinen Desktop zugreifen kann. Das geht nur über den direkten Pfad: also

C:\ ...Dokumente Einstellungen usw.

Gibts dafür einen Lösung? Habt ihr Ideen oder einen Trick?

 

Hy,
wieso ! den desktop im Netz freigeben, dann mit nem Link aufm Remote verknüpfen. Fertig!
oder als Netz LW. einbinden, was ein bischen digge währe!


Grüße Olaf

 

Falls Du Access Vollversion auf dem TS hast, dann wirst Du ein Problem mit Lizenzen haben (entweder hast Du genug Lizenzen, aber dann zahlst umsonst weil man auch Runtime, die kostenlos ist einsetzen könnte, oder du hast nur eine Lizenz aber 20 oder 30 Anwender greifen zu und somit rechnet sich das hoch!

Bei uns in der Firma habe ich das mit Fileserver gelöst, indem das Backend auf einem SQL Server liegt und Frontends werden compiliert (ADE erstellt) und auf einen Fileserver verschoben.
Eine .NET Applikation Namens Applikation-Manager wird dann vom User auf seinem Client gestartet. Diese Applikation-Manager Anwendung hat nur die Aufgabe alle verfügbare Frontends auf dem Fileserver anzuzeigen (natürlich werden die Rechte berücksichtigt, weil es sind über 100 Fronends) und wenn man auf einen Item anklickt, dann:
- Prüft der Applikation-Manager zuerst auf dem Client das Erstellungsdatum des Frontends und ob Frontendapplikation überhaupt auf dem Client vorhanden ist
- Falls sie vorhanden ist, dann wird Erstellungsdatum des Frontends mit dem Erstellungsdatum des Frontends vom Fileserver verglichen und bei Bedarf vom Fileserver heruntergeladen

Wenn das Frontend einmal gestartet ist, dann läuft es lokal auf dem Client. èber TCP/IP stellt er eine Verbindung zum SQL Server. Also keine ODBC geschichte auf den Clients einzig was es braucht ist eine Access Runtimeversion auf dem Client und die ist Kostenlos.

Diese Vorgehensweise ist üblich und funktioniert sehr gut seit Jahren in unserer Firma.
Da man SQL Als Backend verwendet, eröffnen sich noch weitere Möglichkeiten. Man kann über Verbindungsserver eine Connection zu den anderen Datenbanken herstellen (etwa Oracle, MySQL BTrieve usw.). Der Client merkt nichts davon. Man braucht weder spezielle Datenbankprovider noch ODBC auf den Clients, alles läuft wie von selbst *Smilie

Grüsse

 

Danke für euren Input.

@Olaf: verstehe nicht ganz wie du meinst.

@les: Das was du beschreibst klingt sehr gut. Allerdings glaube ich, dass es bei mir nicht nötig sein sollte diese Struktur zu fahren. An Usern die auf die DB zugreifen werden, wird es insgesamt nur 5 geben, davon arbeitet eigentlich nur eine Person daran. Somit werden vielleicht maximal 2 User gleichzeitigen Zugriff haben. Jeder der User hat aber eine eingene Access Lizenz, so dass dies kein Problem sein sollte.

Würdet Ihr in meinem Fall, jedem dieser User ein eingenes FE geben oder reicht eines?

 

Habe den Thread jetzt nicht im Detail verfolgt; aber augenscheinlich sind wir mittlerweile von der ursprünglichen Anforderung/Lösung des Terminalservers weg.

Ich bin ein Verfechter der Einstellung, das jeder User sein eigenes FrontEnd bekommt.
Unabhängig davon, ob er auf einem Terminalserver oder lokal an seinem Client damit arbeitet.

 

Nein, es ist auf jeden Fall ein Terminalserver. Mit Servern kenne ich mich nicht besonders gut aus, aber mir scheint, dass dieser Server einfach super konfiguriert ist, so dass alle lokalen Laufwerke und Drucker eingebunden werden können und man eben nicht die klassischen Nachteile eines TS hat. Zumindest nach meiner Recherche wurde das Laufwerks- und Druckerproblem immer bei einer TS Lösung bemängelt.

 

Ob man gleich die Desktops der User freigeben muss?

Ich kenne das so, dass User die meisten Programme (Word, Excel, OL,...) auf dem TS ausführen und mit dort in ihren Verzeichnissen gespeicherten Dateien arbeiten. Das sind auch oftmals Verzeichnisse, die für mehrere User freigegeben sind.
Sollte die Notwendigkeit bestehen, dass Daten vom lokalen Rechner auch unter den TS-Sessions zugreifbar sein sollen, dann werden diese halt auf ein gemapptes Laufwerk desselben kopiert. Also nicht vom TS auf die Cients zugreifen, sondern von den Clients auf Verzeichnisse des TS. Kommt mir auch logischer vor, da schließlich der Remote-Desktop eh geschlossen oder minimiert werden muss, wenn man mit lokalen Dateien arbeitet.

Ciao, Sascha