Hallo,

wir haben immer extremer werdene Probleme mit Sfirm beim Senden von Zahlungsdateien bzw. auch beim Abruf der PTK Datei.

Früher haben wir eine Datei in ca 5 Sekunden gesendet bzw. das Protokoll abgerufen und heute dauert es ca 30 Sekunden bis der Ausdruck aus dem Drucker kommt.

STA empfangen wir allerdings in einer ganz ordentlichen Geschwindigkeit.

Woran kann das alles liegen? Die DB haben wir schon mehrfach reorganisiert!

Wir haben ca 130 Auftraggeber und 180 Konten in Sfirm! Ist das vielleicht zu viel für Sfirm auf Grund der Datenbanktechnik oder sollte das trotzdem einwandfrei laufen?

Wir verstehen vorallem nicht, wieso das empfangen von PTK Daten so lange dauert, aber die Verarbeitung von STA Daten sehr zügig geht.

Wir setzen - je nach Bank - EBICS und FTAM ein - bei beiden Varianten ist Sfirm langsam.


Über einen Tipp wären wir sehr dankbar.

MfG

Frage, wie ist Sfirm32 denn installiert? Programme lokal, Daten im Netz oder sowohl Daten als auch Programme im Netz? Welche Version wird eingesetzt.

Wie äußert sich dies genau? Also werden die Daten als Fremddateien versendet, importiert, wo liegt der DTA-Import-Ordner? Wer verschickt die Zahlungen, was passiert hier genau. Wird der FTAM/Ebicstransfer relativ zeitnah gestartet oder nicht?

Der Ebicskernel ist relativ groß. Wenn dieser aus dem Netz geladen werden muss, da Programme als auch Daten im Netz installiert sind, dauert das Laden des Kernels relativ lang. Werden die Umsatzdaten auch über FTAM/Ebics aktualisiert (könnte ja auch HBCI sein)? Ich denke, beim FTAM ist es ähnlich, alles, was Sfirm32 zunächst aus dem Netz laden muss, dauert natürlich auch in Abhängigkeit der Netzgeschwindigkeit. Nähere Angaben wären hilfreich.

Hallo,

danke für die schnelle Reaktion.

Folgender Sachverhalt liegt vor:

1) Es existiert aktuell ein eigener Rechner für Sfirm auf dem Daten und Programm lokal installiert sind.
2) Auf diesen Rechner greift immer eine Person via Remote-Verbindung zu - es werden also keine SFIRM-Daten über das Netz geschleust.
3) Die DTAUS Daten werden über ein gemountetes Netzlaufwerk verschickt/eingelesen. Es handelt sich um Fremddaten.
4) Auch wenn wir die DTAUS vorher lokal auf c:\ kopieren wird der Versand nicht wirklich schneller
5)die Zahlungen senden und die STA abrufen machen wir immer über den User Sfirm. der lokale Windows-Benutzer ist Administrator im Netzwerk.

Die Umsatzdaten werden teilweile per FTAM teilweile per EBICS abgerufen - so wie auch das Senden.
Umsatzdaten per FTAM oder EBICS werden immer schnell abgerufen.
Zahlungsdaten werden per FTAm oder EBICS immer langsam gesendet.
PTK wird immer langsam abgerufen/ausgedruckt per FTAM oder EBICS.

MfG

Klingt nach den DFÜ-Aufträgen. Beim PKT-Abruf muss das Prog sich nämlich durch die ganze DB kämpfen, bis der aktuell bestätigte Auftrag gefunden ist.

Es fehlen noch die Versionsdaten. Je nachdem wird sich folgendes geringfügig anders darstellen ...

Welche Zeiten habt ihr für die Löschung von DFÜ-Aufträgen in den Optionen eingestellt?
Erfolgreiche Aufträge und Abrufe ohne Daten sollten sofort gelöscht werden - Fehlerhafte zeitnah.
Deshalb: >> Extra >> Reorganisation >> DFÜ-Aufträge löschen >> zuerst "alle erfolgreichen" löschen; dann Kontrolle, ob der noch vorhandene Rest bleiben muss (z.B. noch fehlende Unterschriften bei EBICS-Überweisung) ; bearbeiten und dann nochmal DFÜ-Aufträge löschen. Diesmal aber ALLE.
Achtung: Zahlungen, die im Status DFÜ-Auftrag waren, werden durch die Aktion wieder fällig.

Hier noch die Holzhammermethode: Löschen der sfdfu.mdb und folgend externe Reorg. Die Folgen bzgl. wieder fälliger Zahlungen sind gleich.

OK,

wir versuchen das gleich nochmal.

Wie groß ist die SFIRM.mdb eigentlich im Durchschnitt? Unsere ist akut 250MB groß.

Ist das vielleicht auch schon zu groß?

Bingo!

Meine (leere) DB hat 206kb.

Ach so: Eine Datensicherung vor der Aktion kann nicht schaden. Man braucht sie nämlich nur, wenn man sie nciht gemacht hat.

Hallo zusammen,

@Fellini: leere Sfirm.mdb mit 206 kb ? meine hat leer über 3 MB. Du meintest wohl die SFDFU.mdb, das würde passen.

@Flocke:
Senden von DTA-Dateien unter EBICS und FTAM dauert immer etwas länger als der Abruf von STAs, da die Vorarbeiten innerhalb der Datenbanken aufwändiger ist als der Abrufauftrag.

Wenn Ihr PTKs abruft, muss SFirm das Protokoll ja erst auswerten und dabei die versandten DFÜ-Aufträge mit dem Protokoll abgleichen. Der Druck der Listen erfolgt nicht aus dem PTK sondern nach Auswertung des PTK aus den Daten der eingentlichen Datei. Bedeutet, dass hier einfach recht viel Rechenleistung benötigt wird.

Wie sehen denn die DTA-Dateien aus ? Enthält eine DTA-Datei mehrere logische Dateien ? Die würde in meinen Augen die längere Verarbeitungszeit erklären.

Welche SFirm-Version ist installiert ?
Welches Betriebsystem ?
Wie viel RAM steckt im Rechner ?
Wieviel Platz ist auf der C-Platte des Rechners frei und falls SFirm auf einer anderen Platte/Partition liegt, wieviel Platz ist dort frei.
Sind die Systemvoraussetzungen erfüllt ?
http://www.sfirm.de/kunden/sfirm32/voraussetzungen.html

Viele Grüße
bt

*rotwerd*
Hab die sfirm.mdb und die sfdfu.mdb verwechselt.
In der Sache bleib ich aber bei meinem Verdacht