Wir verwenden schon seit Jahren SFirm, erst SFirm 1.x und seit ner Weile SFirm32. Was mich immer schon gestört hat ist das SFirm elendig langsam ist. Da wir recht viele Kontobewegungen und Konten haben ist unser SFirm dementsprechend umfangreich.

SFirm setzt ja seit langem auf die Jet-DB-Engine (sprich Access-Datenbanken). Weiß einer von euch, der näher an der BIVG dran ist, ob es vielleicht für zukünftige Versionen geplant ist SFirm auf einen DB-Server aufsetzen zu lassen. Sontan fiele mir da die MSDE bzw. Express-Edition vom MSSQL-Server ein. So hätte man ein wesentlich fixeres Backend, was dem allgemeinen Programmablauf sicherlich nicht abträglich wäre.

Nutzt Du SFirm denn lokal oder im Netzwerk? Könnte es da vielleicht irgendwo Zusammenhänge geben? Meine Kunden nutzen SFirm auch oft mit großen Datenbeständen und langsam ist es dort selten, es sei denn, das Netz ist überlastet oder schlecht administriert...

Generell weiß ich nicht (bin kein DB-Spezi), wie man SQL-DBs gegen den Zugriff von außen schützen kann. Ist es nicht so, daß mindestens der Admin die komplette DB einsehen kann? Finde ich dann nämlich nicht sonderlich geeignet...ist bei einer geschützten Access-DB eben anders.

Das SFirm ist lokal installiert und die Datenbank liegt auf nem Server. War früher mal ein NetWare 4-Server und seit drei Monaten ists ein Windows 2003-Server. Auf beidem Systemen ist es ungefähr gleich langsam.

Früher hatten wir bedingt durch den NetWare-Server mehrere Protokolle im Einsatz, sprich IPX/SPX und TCP/IP. Durch den neuen Server haben wir jetzt ein reines IP-Netz, so das die Protokolle nicht zum Problem beitragen meine ich. Die Arbeitsstationen sind relativ aktuell (Athlon XP 2400, 512 MB RAM, Windows XP Pro, ....) und der Server ist ganz neu (Dual-Xeon, 4 GB RAM, SCSI-Platten etc.). Die Switches sind auch neu.

Ich hab mal die Startzeit auf meiner Maschine gemessen. Vom Doppelklick aus SFirm-Icon bis zum Loginfenster vergehen ca. 45 Sekunden.

Was die Datensicherheit angeht so kann man auch SQL-Datenbanken entsprechend schützen, so das da kein Unbefugter ran kann. Sie sind vom Datenschutz her meiner Meinung nach sogar besser, da man nicht einfach mal so das DB-File wegkopieren kann.

Definitiv zuviel !!
Wie groß ist deine SFirm.mdb? Wieviele Konten sind drin? Seit wann hast du historische Umsätze? Ooops, nicht zu vergessen: Welche Version?
Für mich auf jeden Fall ein Netzwerkproblem.
Ansätze könnten sein: IP-Konflikte (BTW: DHCP?), falsche Subnet-Mask, ein herrenloser WLAN im Netz, falsch konfigurierte NW-Karte an einem Client,..... Die Liste könnte quasi endlos fortgeführt werden.
Ansosnten: Hast du mal mit den Sysinternals probiert herauszufinden, was genau beim SFirm-Start so lange dauert ?
Ich habe eine Installationen mit hunderten Konten und einigen Clients. Funzt alles und das Anmeldefenster ist innerhalb einer Sekunde da.

CU
Frank

Danke für die Tipps.

Die SFirm.mdb ist knapp 85 MB groß, die sfdfu.mdb knapp 26 MB
Konten sind glaube ich 50 drin, könnten auch eins mehr oder weniger sein. Frag nicht warum wir soviele Konten haben oder brauchen.

IP- und DHCP-Probleme schließe ich aus, da wir das Netz neu aufgesetzt haben, und bis auf SFirm alles prima funktioniert.

Mit Filemon konnt ich beobachten das erwährend des Startens abwechselnd immer wieder die SFirm.mdb und die sfdfu.mdb öffnet und scheinbar satzweise auswertet.

Hallo,
die sfirm.mdb ist nicth wirklich groß. Viel zu gruß ist die sfdfu.mdb! Lösch zuerst mal über >>Extra >>Reorganisation >>DFÜ-aufträge löschen alle erfolgreichne Aufträge. Schau dir danach die gescheiterten an. Löschst du einen gescheiterten DFÜ-Auftrag zu einer Zahlung, wird der Auftrag damit wieder fällig.
Grundsätzlich solltest du unter >>Extra >> Optionen in Reiter allgemein die Häkchen bei "DFÜ-Aufträge löschen" alle setzen. Meine Standardeinstellung ist "erfolgreich" nach 0 Tagen (sprich sofort), "gescheiterte" nach 21 Tagen und "ohne Daten" nach 2 Tagen.
Mit der danach deutlich kleineren sfdfu.mdb sollte der Programmstart auch ein wenig schnelller werden ...

CU
Frank

Danke. Das probier ich mal

Hallo,

natürlich solltest Du nach dem Löschen der DFÜ Aufträge auch eine Datenbankreorganisation durchführen, damit die Datenbanken auch kleiner werden.

Gruß
Gregor

Mich würde auch interessieren, ob es geplant ist, dass SFirm ein etwas professionelleres DBMS einsetzt. Wir haben mittlerweile knapp 350 MB in der SFIRM.MDB
Naja, es läuft, aber nicht so wirklich gut... Hat jemand eine Idee, was man verbessern könnte? Das automatische Löschen ist bei uns aktiviert (Ausnahme: Kontoumsätze).

Gruß
Tobias

Hallo,

von meinen Kunden nutzen auch viele SFIRM32 - auch mit großen Datenbeständen (ein Kunde hat mehrere hundert Konten, da er deutschlandweit operiert). Keiner davon hat Probleme.

Ich tippe auch definitiv auf ein Problem im Netz. Dafür kann die BIVG ausnahmsweise nix Ist wie wenn man Diesel statt Benzin tankt und dann den Autohersteller verantwortlich macht *übertreib*.

Gruß,
Sorro

Naja, es kann durchaus gut laufen - das steht ausser Frage.
Allerdings gibt es durchaus optimalere Datenbanken für den Netzwerkbetrieb als Microsofts Jet Engine (aka Access). Diese ist weder besonders schnell noch optimiert für Netzwerkverkehr. Die tollen Chaching Mechnismen der Jet funktionieren nämlich nur, wenn man solo auf der Datenbank arbeitet.

Ich glaube allerdings nicht das sich da zeitnah was dran ändert, auch wenn da vor Ewigkeiten schon mal drüber nachgedacht wurde. -> Meine Meinung.

Die Folge für die BIVG wäre ja auch "mal eben" das ganze Prog neu zu schreiben, weil die DB ja nun mal das Herz des Ganzen ist. Da steckt wohl ein klein wenig Aufwand dahinter...