Kurze Frage: Ich hatte neulich das Konstrukt / den Kundenwunsch: SFirm als Netzinstallation gewünscht, also die Variante mit SQL-Datenbank und DATEV Installation auf einem Fileserver.
- Die SFirm Installation lief glatt durch, alles "gut"
- Die DATEV Neuinstallation (Mittelstand mit Rewe) scheiterte am Punk "SQL-Server"
Ich hab SFirm deinstalliert, das SQL-Zeug vom SFirm bereinigt und anschließend DATEV installiert. Das funktionierte. Was geschieht wohl, wenn ich das SFirm jetzt installiere? Jemand erfahrungen?
Danke!
Gelöst! Gehe zu Lösung.
Losgelöst der Frage: In Zeiten von Virtualisierung würde ich mir (/dem Kunden) den potentiellen Stress gar nicht antun. Auch wenn es sich _jetzt_ installieren lässt, was tun wenn es später bei einem Update Probleme gibt.
Ein wenig mit Bezug zur Frage: Was sagt die Sparkasse / der Hersteller von SFirm zur Konstellation?
(Jetzt wo ich schreibe, kommt mir dunkel die Erinnerung, dass man manche Dinge bei SFirm Installationen umgehen konnte, wenn man den SQL Express einfach vorher installiert und im Setup nachher sagt, vorhandenen SQL nutzen. Aber auch hier o.g. Punkte beachten. ;))
Hallo LS4B,
aus meinem Service-Nähkästchen: Beides zusammen auf einem System läuft ohne Probleme.
Es wäre interessant, warum die SQL-Installation der DATEV-Software abgebrochen ist.
Deshalb empfehle ich - wenn noch interessant - den Auslöser zu suchen und damit Abhilfe zu schaffen:
- ExitCode 1603 beim Installieren von DBMSTool für den Microsoft SQL Server (DATEV)
- INI07278 beim Installieren von Microsoft SQL Server (DATEV)
2023 hatten mal einen ganzen Schwung SFIRM-Kunden, bei denen die DATEV-Installation nicht geklappt hat. Da wurden von SFIRM der Microsoft ODBC-Treiber mit einem geänderten Namen (odbc18\msodbcsql_eng_x64.msi) ausgeliefert. Das stand dann nach der erfolgreichen Installation falsch in der Registry der Rechner. Der Original-Microsoft-Mechanismus (im Rahmen der nachfolgenden DATEV-Installation) konnte die Informationen nicht korrekt verarbeiten ...
... und dann gab es Systeme, auf denen der SQL Browser nach der SFIRM-Installation fehlt. Einfach so. Unerhört! 😀
Daraus kann man lernen: Wenn man sich strikt an die Microsoft-Namensgebung hält, die Originaldateien und alle notwendigen Komponenten unverändert ausliefert, dann kann auch die nächste SQL-Instanz problemlos installiert werden.
Kurzfassung: Wer zuerst kommt. mahlt zuerst.
Mit freundlichen Servicegrüßen aus Nürnberg
Christian Tölle
Technische Basis 2
DATEV eG
Ich gebe in dem Punkt "virtuelle Maschinen" schon recht. Aber: Hier handelt es sich um zwei User in dem Büro. Es ist kein Berater, sondern ein Betrieb. Es wird dann auch einfach "teuer" zig VMs aufzumachen. Das Blech muss es hergeben, die MS-Lizenzen auch.
Deshalb die Frage.
INI07278 beim Installieren von Microsoft SQL Server (DATEV)
2023 hatten mal einen ganzen Schwung SFIRM-Kunden, bei denen die DATEV-Installation nicht geklappt hat. Da wurden von SFIRM der Microsoft ODBC-Treiber mit einem geänderten Namen (odbc18\msodbcsql_eng_x64.msi) ausgeliefert. Das stand dann nach der erfolgreichen Installation falsch in der Registry der Rechner. Der Original-Microsoft-Mechanismus (im Rahmen der nachfolgenden DATEV-Installation) konnte die Informationen nicht korrekt verarbeiten ...
Kurz überlegt... Das wird sein. Der FehlerCode bezog sich auf ODBC. Das SFirm ist die neueste Version, die man runter laden kann.
Ich hab jetzt DATEV drauf und installiere (nah Backup 😉 ). SFirm dazu.
Was hat der Fehlversucht an Dienstleistung gekostet?
Was kostet der Weitere Versuch jetzt nach der Datensicherung und was kostet es, wenn der Restore her muss?
Was kostet die 2 MA ein Tag Ausfall bei einem Update, weil irgendwas nicht mehr funktioniert?
Was kostet ggfs. die Rücksicherung und der mögliche Datenverlust, wenn ein Restore nach dem Problem zum Tragen kommt?
Was kostet der Ausfall, wenn man bis Nachmittags versucht zu reparieren, dann DATEV und/oder SFirm anruft und die erst am dritten Tag zurück rufen?
Und das alles VS. ca. 800 €
Nunja.. 🤷
... vor Jahren gab es bei mehreren Selbstbuchern auch regelmäßig (bei jedem Datev-Update) Probleme mit konkurrierenden SQL-Server-Installationen zwischen Datev-Produkten und Produkten anderer Software-Anbieter (z.B. Lexware, Sage KHK u.a.)
... 'geholfen' hat eine bestimmte Reihenfolge der Update-Installation, also anscheinend eine Frage der Aufwärts-/Abwärtskompatibilität, aber der genauen Ursache bin ich nie auf den Grund gegangen, sondern habe dann eben jahrelang die Reihenfolge eingehalten, bis die Probleme von alleine 'herausgewachsen' sind ... Glück gehabt ...
Und das ist auch das "Problem" bei dem Kunden. Dieser besitzt bereits virtuelle Maschinen, genau in dem Konstrukt: DATEV, Sage,... und jetzt neu dazu SFirm. Die vorhandene Maschine hat halt keine Kapazität für eine weitere VM. Deswegen meine Frage.
Und nein, ich kann ich auch erstmal so versuchen für meinen Kunden eine Lösung zu finden, bevor er alles neu bekommt.