Hallo,
vielleicht könnt ihr mir helfen bei folgendem Problem:
Datev Arbeitsplatz v9.2 ist komplett auf einer anderen Festplatte (Laufwerk "D") installiert als das Betriebssystem. Diese Festplatte sollte ausgetauscht werden. Es wurden folgende Arbeiten durchgeführt:
1. Der Rechner wurde heruntergefahren und die Festplatte mit Datev ausgebaut.
2. Alle Daten wurden auf eine neue Festplatte kopiert und die neue HDD wurde eingebaut.
3. Nach dem Start des Rechners bekam die neue Festplatte den Buchstaben "D" und die gleiche Bezeichnung wie die alte.
Leider kann ich Datev nicht starten, es erscheint lediglich das Start-Logo mit "Datev_Arbeitsplatz wird gestartet..." und bleibt in der Bildschirmmitte stehen. Es musste wieder die alte Festplatte eingebaut werden.
Was mache ich falsch?
Haben Sie mal mittels EODBCONFIG den Datenpfad bzw. die entsprechenden anderen Optionen geprüft?
Servicetool mal laufen lassen?
Im CDBTOOL mal geschaut und die üblichen Verdächtigen geprüft?
Ich hätte auch mit Tools wie Veeam oder Macrium Reflect ein Image der Festplatte D gemacht und das exakt so wieder 1:1 zurückgespielt. Oder wie haben Sie die Daten von Festplatte A nach B gebracht? Mittels 2. PC und Windows Explorer? Das geht schief, weil dann die Berechtigungen nicht stimmen und ggf. auch nicht sichtbare Dateien und Ordner nicht mit kopiert werden. Auch wenn man sich diese einblenden ließe.
Und wieso wurde DATEV auf D installiert? Laut DATEV soll man alles auf C installieren, weil sich DATEV mittlerweile unter Program Files (x86) schreibt und dieser Ordner als Standard auf C liegt. Wenn, dann kann man höchstens die Daten auf D auslagern aber bei einem Einzelplatz macht eigentlich alles nur auf C Sinn. Backup des PCs mit Veeam oder Macrium - fertig. 1TB SSDs kosten auch nur um die 100€.
Hallo,
vielen Dank für die Tipps.
Ich wurde gebeten das Upgrade von Windows 7 auf Windows 10 zu installieren, was reibungslos funktioniert hat. Die Datev-Installation auf "D:\Datev" ist ca. 5 Jahre alt und wurde wahrscheinlich damals aus einem früheren Rechner übernommen.
Die Daten habe ich mit Total Commander kopiert. Das Tool ist bzgl. versteckter Dateien sehr zuverlässig.
Ich installiere gerade noch das Funktionsupdate 1909 von Windows 10. Morgen werde ich den nächsten Kopierversuch mit Datev durchführen.
Vielen Dank.
@dolar schrieb:.....
2. Alle Daten wurden auf eine neue Festplatte kopiert und die neue HDD wurde eingebaut.
.....
... hört sich nach 'normalem' Kopieren der Ordner und Dateien an.
Ich würde die Festplatte mit einem Backup-Tool "klonen", z.B. mit "Acronis True Image" oder einem anderen bewährten Tool.
Dann kann man anschließend sofort weiterarbeiten.
Neue Festplatte größer als alte? -> direkt dd anwenden.
Neue Festplatte kleiner (z.B. SSD)? -> Partition mit GParted schrumpfen, dann mit dd auf die neue schieben.
Selbst getestet mit Datev-Installationen, funktioniert.
@cwes: So eine Fummelei und Aufwand und dabei kann viel falsch gehen. Wie so oft: Macrium Reflect ist das Tool der Wahl. Kann alles, optisch ansprechend und schnell. Kann auch Partitionen verkleinern bzw. schreibt dann nur die Daten in die kleinere Partition.
gpartd und dd - ist alles überflüssig geworden.
Ich habe mit Acronis B&R 11.5 die gesamte Datev-Ordnerstruktur gesichert auf auf die neue HDD zurück gespeichert. Datev funktioniert einwandfrei.
Folgende Lehre: Total Commander darf sich zukünftig für solche Zwecke nicht mehr verwenden.
Gruß und vielen Dank für die Tipps.
Bitte Unfälle beim Clonen und den Freigaben vermeiden...
Problem: DAP startet nicht, da der SQL- Manager "seine" Daten nicht findet.
Nach dem PC- Neustart also den SQL- Manager Admin starten und
- alle Datenbanken trennen
- alle Datenbanken neu verbinden.
fertig...
Hinweis: Das ist absolut wichtig, wenn der Datenbestand aus einer Sicherung außerhalb des Servers zu mounten ist, um z.B. den gestrigen Stand einer ReWe- FiBu zu extrahieren.
Hallo Herr Kolberg,
... klingt gefährlich.
Ich habe schon sehr oft per Boot-CD geklont (z.B. beim Austausch von Festplatten) und hatte bisher nach dem Klonen noch nie Probleme mit den Datev-SQL-Daten.
In welchen Fällen halten Sie das Trennen und Neuverbinden aller SQL-Datenbanken für erforderlich ?
Sucht der SQL-Server noch nach spezifischen Daten der Festplatten-Hardware ?
Ansonsten ist ein Klonen ja eine 1:1-Kopie des Inhalts.
Wenn sich die Windows- Volumen- ID ändert, müssen die Datenbanken ab- und neu angehängt werden.
Das passiert immer dann, wenn die Daten "zu Fuß" in ein anderes System einkopiert werden. Sogar dann, wenn zwei unterschiedliche Windows- und DATEV- Installationen auf dem identischen Blech (Dualboot) mit ein - und demselben Datenbestand arbeiten sollen.
Hallo Herr Kolberg,
ja, stimmt, diesen Effekt kenne ich z.B. beim Erstellen von Backups (Images) direkt auf externe Wechsel-Festplatten. Dann meckert die Backupsoftware beim Festplattenwechsel.
Ich erstelle daher solche Backups und Images immer auf eine interne Festplatte und kopiere dann auf die externe Platte.
Ich will aber mal ausprobieren, ob man mit einem Tool (z.B. aus Sysinternals) die Volume-ID bei externen Festplatten angleichen kann, um die Festplatten wechseln zu können.
@martinkolberg schrieb:Bitte Unfälle beim Clonen und den Freigaben vermeiden...
Problem: DAP startet nicht, da der SQL- Manager "seine" Daten nicht findet.
Nach dem PC- Neustart also den SQL- Manager Admin starten und
- alle Datenbanken trennen
- alle Datenbanken neu verbinden.
fertig...
Hinweis: Das ist absolut wichtig, wenn der Datenbestand aus einer Sicherung außerhalb des Servers zu mounten ist, um z.B. den gestrigen Stand einer ReWe- FiBu zu extrahieren.
... nur zum Verständnis:
Sie sprechen jetzt aber nicht vom 'normalen' Sichern oder Klonen zum Zweck der 'normalen' Rücksicherung oder des Festplattentauschs, oder ? ....
... sondern 'nur' von dem Fall, dass man den Datev-Datenzugriff mal temporär 'umhängen' will, also die Datev-Datenbanken von einem anderen Volume bzw. einer anderen Festplatte verwenden will.
Für diesen Fall ist das Trennen und Neu Verbinden sicher notwendig, beim 'normalen' Sichern oder Klonen (aus meiner Sicht) nicht.
Übrigens, die VolumeID eines Laufwerks (z.B. einer externen Festplatte) kann man ändern.
Man kann also z.B. mehrere externe Festplatten (Wechselfestplatten) mit einer einheitlichen, selbstgewählten VolumeID versehen (z.B "1111-1111").
... habe noch nicht getestet, ob diese Vereinheitlichung der VolumeID auch für das Umhängen der SQL-Datenquellen zu gebrauchen wäre. Am 'offenen Herzen' will ich nicht 'operieren', höchstens an einer 'medizinischen Übungspuppe' 😀
Ich spreche von einem komplett einkopierten Datenbestand zur regelmäßigen Überprüfung der Integrität der Datensicherung.
In diesem Zusammenhang läßt sich dann ein ReWe Datensatz raus sichern.