Hallo,

wir nutzen eine Netzwerk-Installation mit insgesamt 3 Servern:
- Programm-Server (Citrix-Server) unter Windows 2000
- Datenserver unter Windows NT 4.0
- WS mit Automaten und ISDN-Karte unter Windows XP

Unser Problem:
seit der Migration auf 2.2. (11/11) verweigert SFIRM urplötzlich die Anmeldung mit dem Hinweis auf unbekanntes Format in der SFDFU.MDB und auch der Automat kann keine Aufträge mehr ausführen.
Nach einem Reorg ist alles wieder gut - aber das nervt - denn der nächste ist nicht fern - und wenn deshalb unsere automatischen Aufträge frühmorgens scheitern und nachgefahren werden müssen, haben wir Ärger mit dem ganzen Hause!!!!
Wer kennt das Problem, wer weiß Abhilfe????

Danke und Gruß
HaJo

Hallo HaJo,

in solchen Fällen ist es zu empfehlen, einen Eintrag bzgl. der Access-Datenbanken auf dem Server zu setzen. Schau hierzu mal in die FAQ auf www.sfirm.de und such nach "registry-eingriff" (oder K04097), dann findest Du den Eintrag. Muss ich auch oft bei meinen Kunden einsetzen und hilft fast immer
Danach die sfdfu.mdb gegen eine neue austauschen (löschen, Rep.inst. oder aus Sicherung, die kann aber auch schon nen Knacks haben).

Gruß
EB

Hallo EB,

vielen Dank für die prompte Hilfestellung (vielleicht wäre der richtige Kommentar für mich: richtig suchen sollte man können....)!
Unser Sysadmin versucht sich heute Abend daran und ich bin gespannt, ob wir morgen endlich mal wieder unserer eigentlichen Tätigkeit nachgehen können....(was war das nochmal??).

Gruß
HaJo

Hallo,

zwischenzeitlich haben wir den oben beschriebenen Lösungsweg beschritten.
Kurzfristig sorgte er für eine gewisse Ruhe, jedoch erhielten wir heute einen neuen Fehler (nicht bekanntes Format der SFIRM.MDB).
Nach erfolgtem Reorg ist eine Anmeldung wieder möglich.

Nachdem der Fehler bisher die SFDFU.MDB betraf und nun die SFIRM.MDB frage ich mich:
alles nochmal von Vorne oder ein anderer Fehler?

Vielen Dank für Eure Beteiligung!
Lieber Gruß
HaJo

Hi HaJo,

klingt so, als hätte die sfirm.mdb auch nen Schaden... Aber so lange die Reorganisation noch hilft.....

Ich würde das auf jeden Fall weiter beobachten und wenn ständig Probleme mit der sfirm.mdb auftreten, die reorganisierte Variante mal Deinem Sparkassenberater zukommen lassen, er kann die beim Hersteller reparieren lassen. Dann hättest Du vielleicht mal eine wirklich saubere Datenbank. Wer weiß, was da alles so drin steckt........

Aber: vielleicht gibts noch ne weitere Ursache für Deine Probs: manche Virenscanner fressen gern Access-Datenbanken. Ich würde die von SFirm mal aus der permanenten Prüfung ausschließen.

Gruß
EB

Hallo Hajo,

wie groß ist denn die SFDFU.mdb bei Euch. Die sollte nicht gravierend größer als 300 K sein. Falls doch habt Ihr vermutlich massenhaft alte abgearbeitete DFÜ-Aufträge drin stehen, das macht die SFDFU.mdb oft instabil.
Lösche mal bitte alle alten DFÜ-Aufträge "Extra - Reorganisation - DFÜ-Aufträge löschen" dann die Auswahl "Alle DFÜ-Aufträge löschen "

Achtung!!!! Vorher sollten alle im Pool bereitgestellten Zahlungsaufträge versendet werden. Falls Ihr zeitgesteuerte, oder wiederkehrende DFÜ-Aufträge eingepflegt habt, wären dies dann auch weg (außer Kontorundruf). In diesem Fall müsstest Du die DFÜ-Aufträge von Hand bereinigen.

In der Baumstruktur links findest Du den Eintrag "DFÜ-Aufträge" mit den Unterordnern "Standard Aufträge", "Fremddateien", "Sonstige Aufträge", "Kontoauszüge", "Kundenprotokolle", "Kontoabfragen". Wenn Du hier den Ordnernamen anklickst siehst Du den Status der Aufträge. Alle die auf "OK" oder auf "Keine Daten" stehen solltest Du löschen. Die gescheiteten kannst Du auch löschen. Bei diesen ist zu beachten, dass die entsprechenden Zahlungsaufträge dann auf fällig zurückgesetzt werden.
Den Ordner "Rundruf" solltest Du in Ruhe lassen.

Der Löschvorgang kann einige Minuten dauern.

Anschließend solltest Du über "Extra - Reorganistation - DFÜ-Aufträge reorganisieren" nochmal eine Reorg drüber laufen lassen. Dann nochmal prüfen, ob noch DFÜ-Aufträge in den Ordnern aufgetaucht sind. Diese dann ebenfalls von Hand löschen.

Nun noch mal über "Extra - Reorganisaton - Datenbanken reorganisieren/komprimieren" alles gelöscht wirklich aus den Datenbanken entsorgen.
Dann sollte die SFDFU.mdb nicht mehr gößer als 300K sein.

Sollte das nicht helfen, SFIRM (gleicher Versionsstand) an einem PC, der mit SFIRM noch nichts zu tun hatte, installieren. Aus dieser Installation die leere SFDFU.mdb in die Produktionsversion kopieren.
Anschließend extern reorganisieren über "Start - Programme - SFIRM32 - Datenbankreorg." Dann SFIRM öffnen und "Extra - Reorganisation - DFÜ-Aufträge reorganisieren".
Achtung !! !! !! Auch hier sind dann alle wiederkehrenden oder zeitgesteuerten DFÜ-Aufträge(außer Kontorundruf) weg.

In den Optionen (Reiter"Allgemein" links unten) kannst Du übrigens einstellen, nach welcher Zeit DFÜ-Aufträge gelöscht werden sollen. Diese Funktion solltest Du einschalten und möglichst kurze Spreicherzeiträume wählen.

Gruß bt

Hallo,

vielen Dank für die schnellen Antworten!

@EB: das mit der Reparatur beim Hersteller habe ich auch schon mal angedacht - danke für die moralische Unterstützung, denn irgenwie kommt man sich ja etwas blöd vor.....
Virenscaner haben wir auf den Maschinen keine laufen.

@bt: die SFDFU.mdb ist derzeit 346 K groß. Wir werfen abgelaufene Aufträge spätestens nach 2 Tagen raus, haben aber wegen einer etwas ausufernden, gewachsenen Bankenlandschaft permanent 60 'sonstige Aufträge', die täglich oder wöchentlich laufen (sollen). Da alle Daten früh morgens im Hause sein sollten, haben wir die meisten Aufträge mit einem 'Sicherheitsauftrag' gedoppelt, für den Fall, dass gerade keine Verbindung oder ähnliches zum Abbruch führte. Würde die Zahl unserer Aufträge nur ungerne verringern...


Ganz liebe Grüße :roll:
HaJo

Hallo HaJo,

das mit der Reparatur bzw. Datenbankprüfung ist kein Problem - kommt ab und zu vor, dass das mal nötig ist, von daher: einfach mal machen (lassen) - kostet Dich nichts.

Die sfdfu.mdb sollte nun, nachdem Du den Eintrag auf dem Server gesetzt hast, eigentlich keine Probleme mehr machen, die sfirm.mdb normalerweise auch nicht (sofern Du nicht einen Defekt mitschleifst) - zumal Du ja auch keinen Scharfschützen in Form eines Virenscanners nutzt.

Ansonsten würde ich mich wundern, wer denn ständig Deine Datenbanken schrottet...dann gehen mir auch so langsam die Ideen aus...

Gruß
EB

:shock: :shock:
Das nenne ich mutig! Kein Scanner im gesamten Netz oder nur kein Scanner auf den SFirm-Plätzen??
Da der Scanner mein Hauptverdächtiger ist:
Wie sieht es auf dem Fileserver aus?
Gibt es da einen Ordner SFirm_Daten, der als Z: gemappt ist (also Datenpfad in SFirm Z: ) oder ist der Ordner Daten auf dem Fileserver für alle freigegeben und als Z: gemappt. Gibt es hier dann den Unterordner SFirm_Daten? (Datenpfad in SFIRM Z:\SFirm_Daten)??

Wenn es der zweite Fall ist, dann kann auch der Scanner auf einer WS im Netz, die mit SFirm nix zu tun hat, die mdbs abschießen.

CU
Frank

Hallo,

das war ja ein ganz schönes Echo auf unsere Probleme - vielen Dank!!!

@Fellini: so ganz schutzlos sind unsere Server nicht, aber genauer erläutern kann ich's nicht, da der SysAdmin gerade im Urlaub weilt, nach seiner Rückkehr schauen wir uns das nochmals genauer an.

Der Hinweis mit der Größe der SFDFU.MDB hat mich nicht ruhen lassen.
Jetzt habe ich die Größe über den Tag verfolgt und gesehen, dass sie sich eigentlich ständig vergrößert, bis zum nächsten Reorg.
Den letzten Hänger hatten wir, als die Datei auf 1074 K angewachsen war, nach dem Reorg war sie dann wieder auf <400 K.
Heute ist sie 'nur' auf 786 K angewachsen - der Hänger blieb aus!
Interessant, aber was hilft's? Muss ich jetzt stündlich die Anwender zum Ausloggen bewegen und einen Reorg fahren? Oder hat noch jemand eine zündende Idee??

Wenn wir uns halbwegs sicher sein können, dass wir uns nicht immer selbst die DB abschießen, werden wir's mit einer Reparatur versuchen.


Liebe Grüße
HaJo

Hallo Hajo,

Den Reorg kannst Du automatisieren.
- Extra - Optionen - Admin (2)
- Den Automaten für einige Minuten täglich (z.B. Mittagspause) zeitgesteuert deaktivieren und in diesem Zeitraum eine automatische Reorg laufen lassen.

Wenn die SFDFU.mdb ständig wächst, könnte es auch sein, dass diese wirklich einen Schuss hat. Würde diese mal gegen eine leere SFDFU.mdb tauschen. Hat natürlich den Nachteil, dass Du die ganzen zeitgesteuerten DFÜ-Aufträge hinterher neu anlegen mussst.

Bezüglich Deiner 60 Aufträge hab ich dann noch ne Frage:
Welches DFÜ-Verfahren nutzt Ihr eigentlich ? HBCI, FTAM, EBICS ?

Gruß bt

Hallo bt,

wir verwenden derzeit noch FTAM, wollen jedoch in absehbarer Zeit auf EBICS wechseln.

Die letzten drei Tage hat sich die SFDFU.MDB von morgens ca. 230 K auf 600, 790 und 850 K aufgebaut.
Bei letzterem Wert hatten wir wieder das altbekannte Problem, einmal zwischendurch jedoch auch ohne nennenswerte Größenänderung.javascript:emoticon(':shock:')

Den Reorg kann ich leider tags nicht einfach laufen lassen, da eigentlich immer einige User auf dem System sind; deshalb ist er auf nachts eingeplant.

Werde wohl noch wenige Tage beobachten und dann ggf. zähneknirschend eine leere Datei reinhängen und alle Aufträge neu aufbauen....javascript:emoticon(':oops:')

Liebe Grüße
HaJo

Hallo,

heute war unsere sfdfu schlappe 85 MB groß.
Alte Aufträge haben wir keine rumliegen.
Das einzige 'Verbrechen' war wohl, dass eine Kollegin versuchte, 342000 Sätze per FTAM an die Bank zu übertragen.
Es ging null und nichts mehr!
Wir haben dann die sfdfu gegn eine alte getauscht, jedoch über den Tag bereits 3 altbekannte Meldungen 'unbekanntes Format in der sfdfu' nur noch mit Reorg in den den Griff bekommen.
Zwischenzeitlich haben wir die EBICS-Daten zumindest unserer Hauptbank im Hause, aber noch nicht eingerichtet.
Macht es Sinn, sich jetzt ganz auf EBICS zu konzentrieren und zu hoffen, dass einen die sfdfu dann in Ruhe läßt, oder habt ihr einen Plan?

Danke und Gruß
HaJo