kraut147
Goto Top

Wie kann man eine Lexware Financial Office Pro Installation über 2 Subnetze benutzen ?

Die Lexware Financial Office Pro Software kann als Client/Server Installation betrieben werden in dem die Datenbank auf einem Rechner installiert wird und als Service auf diesem Rechner läuft damit die Clients von anderen Rechnern aus darauf zugreifen können. Sinnigerweise müssen laut Lexware Server UND Client im gleichen Subnetz sein damit die kommunikation funktioniert. Ist in unserem Betrieb aus Sicherheitsgründen nicht der Fall und dehmentsprechend stressig ist die Installation bis jetzt gelaufen. Da Subnetze kein revolutionäres Konzept sind und sich die Firma Lexware Marktführer schimpft kann ich kaum glauben das ich der erste ITler mit diesem Problem bin. Wenn irgenjemand eine Lösung oder einen Workaround weiss : sagt bitte bescheid.
e29e4304bbadd2b508ceb200f2d9e317-fehlermeldung

Content-Key: 72821

Url: https://administrator.de/contentid/72821

Ausgedruckt am: 29.03.2024 um 00:03 Uhr

Mitglied: Pjordorf
Pjordorf 06.11.2007 um 12:45:14 Uhr
Goto Top
Hallo,

es scheint, das dein Client den (Lexware) Server nicht finden kann. (Namensauflösung? Freigaben für den (Lexware) Sever richtig gestzt?


Peter
Mitglied: moswald
moswald 06.11.2007 um 12:57:59 Uhr
Goto Top
Blöde Frage: Die Route hast du im Router aber schon eingetragen, oder? Das müsste doch reichen. Habt ihr vielleicht irgendwelche Firewalls dazwischen?

Wir schlagen uns auch seit zwei Jahren mit diesem Tool rum und ich muss sagen, dass professionelle Software anders supported wird. Btw. mit welcher Lösung fahrt ihr statistische Auswertungen? Wie wir jetzt nach (fast) einem Jahr vom Support erfahren haben, wird planung+controlling von der 2007er einfach nicht mehr unterstützt.
Mitglied: kraut147
kraut147 06.11.2007 um 15:30:55 Uhr
Goto Top
Firewalls sind als Problemursache schon eliminiert worden. Die Rechner selber können sich gegenseitig pingen etc , nur Lexware kommt nicht weiter als sein eigenes Subnetz. Über statistische Auswertungen machen wir uns im Moment noch keine Gedanken. Die Software muss erstmal zum laufen gekriegt werden.
Mitglied: moswald
moswald 07.11.2007 um 07:50:00 Uhr
Goto Top
Aus Erfahrung kann ich dir nur sagen: Lexware und "zum Laufen bringen" sind zwei Dinge, die sich wie gleichgepolte Magnetenden abstossen. Problemlos lief das Zeug bei uns erst lange nach der Einführung und ständig tauchen neue Probleme auf.

Lass doch mal Ethereal/Wireshark mitlaufen und guck, welche Pakete da nicht durchkommen. Vielleicht wird dann klarer, wo das Problem liegt. Innerhalb des gleichen Subnetzes hat es funktioniert?

Hast du schon die Datenquelle auf dem Server getauscht? Siehe hier:
http://64.233.183.104/search?q=cache:5sw-_opCxXMJ:www.lexware.de/suppor ...
Mitglied: kraut147
kraut147 07.11.2007 um 10:10:01 Uhr
Goto Top
Ich bedanke mich! Nachdem die Einstellungen die im Artikel http://www.google.com/search?q=cache:5sw-_opCxXMJ:www.lexware.de/suppor ... beschrieben waren vorgenommen wurden ist unser 2-Subnetze Problem gelöst.
Danke Herr Oswald.
Mitglied: x-sector
x-sector 10.04.2008 um 10:13:34 Uhr
Goto Top
Servus,

das thema ist zwar schon älter .. klinke mich trotzdem nochmal ein.

Hat jemand mittlweiler schon eine Lösung für das Problem gefunden ?

Meine Erfahrungen ..

Subnetze mag Lexware gar nicht. besonders dann wenn der Traffic auch noch über kaskadierte Switche rennt.

Konnte zwar die Fehlermeldungen verringern mit diversen Versuchen.
Jedoch beim Arbeiten in der Software nach wie vor Fehler bzgl. DB nicht gefunden.
Da also offensichtlich grundsätzlich eine Verbindung zur DB steht (Client lässt sich öffnen und sogar Artikel usw anlegen), geh ich davon aus das broadcasting läuft einfach fehlerhaft.

Lösung bisher war nur möglich, wenn Client + Server im selben Subnet laufen.
Dann läuft alles fehlerfrei.

Fazit .. sobald die angebliche "Netzwerk Lösung" es mit echten und komplexen Netzen zu tun bekommt .. verweigert die SW einfach ein fehlerfreies arbeiten.

Hat jemand noch ein workaround wie es dennoch möglich ist in verschiedenen Netzen zu arbeiten ?
*der link über mir funktioniert leider nicht mehr face-confused

danke vorab.

vg,
sven

*vorstellung folgt noch face-wink
Mitglied: DocDOS
DocDOS 16.07.2009 um 15:57:18 Uhr
Goto Top
So wie das aussieht, wird das niemals gehen..

die Lexware-Programmierer haben offenbar noch nie was davon gehört, dass eine Client-Software seine Datenbank niemals über einen Broadcast suchen sollte. Da der Router der natürliche Feind eines jeden Broadcasts ist, funktioniert das nie reibungslos.

Wireshark hat das bei uns sogar bestätigt (wir suchen uns in dem Fall schon länger die Füße wund).

Wir haben das jetzt auf eine "relativ elegante" Weise gelöst:

Im Subnetz des Lexware-Datenbank-Servers haben wir einen VMware-Server hingestellt und einzelne VMs aufgesetzt. Mit dem VMware-Server 2 (kostenlos bei www.vmware.com) braucht man auch keine Client-PCs in dem Sinne mehr, sondern arbeitet in einem Browser, bzw. Desktop-Shortcut.

Wir haben das Glück, dass nur 3 Leute die Lexware-Software benutzen müssen, wovon Einer sich schon im "DB-eigenen Subnetz" befindet. Somit war das leicht. Die Nötige Hardware war ein Core2Duo um die 2.5 GHz mit einer schnellen Platte und 3 GB DDR2-RAM (das ganze unter einem optimierten Linux, hier Debian Etch).

Ich hoffe, das bringt euch etwas weiter.

Gruß

Doc
Mitglied: kinken
kinken 18.11.2009 um 11:24:27 Uhr
Goto Top
Was steht in den ODBC Einträgen für Adaptive Server Anywhere auf dem Lexware-Client unter System DSN?

Gruß

Kinken
Mitglied: DocDOS
DocDOS 18.11.2009 um 12:32:52 Uhr
Goto Top
Hallo,

bei uns verweisen die System-DSN-Einträge direkt auf den Server. Wir haben es mit nem FQDN und ner direkten IP-Adresse versucht.. beides erfolglos ... nur die Sache mit der VM war das Einzige, was bei uns funktioniert hatte.

In irgendeinem Thread der Lexware-Hotline wurde das auch noch bestätigt.. kann euch den Thread aber leider nicht mehr nennen... ist zu lange her

Gruß

Doc
Mitglied: dfritz
dfritz 12.01.2010 um 13:29:52 Uhr
Goto Top
Hi,

wir hatten heute selbes Problem.

Einfach in dem leeren Feld neben den TCPIP Harken im ODBC HOST=IP_DES_SERVERS;PORT=2638 einsetzen.

Dann war bei uns Ruhe.

Gruß Daniel
Mitglied: KurtManne
KurtManne 14.11.2011 um 00:53:33 Uhr
Goto Top
Zitat von @dfritz:
Hi,

wir hatten heute selbes Problem.

Einfach in dem leeren Feld neben den TCPIP Harken im ODBC HOST=IP_DES_SERVERS;PORT=2638 einsetzen.

Dann war bei uns Ruhe.

Gruß Daniel

Etwas ungenau formuliert:

Über den ODBC Administrator nach der DSN ->LXSYDSN suchen, dann auf den Netzwerk-Reiter gehen und alle Protokolle außer TCP/IP deaktivieren.
Im Feld neben dem TCP/IP Haken eintragen: "HOST=IP_DES_SERVERS" eintragen, also zum Beispiel "HOST=192.168.178.20"
Die Angabe des Ports ist nicht erforderlich.
Um die Sache zu Beschleunigen, kann noch der Schalter "DoBroadCast=None" mitgegeben werden.