Access Datenbank langsam

[HCB]

Hallo, ich habe mal eine Frage an die Datenbank-Spezialisten.

Ich habe ein Delphi-Programm das auf einem NAS-Laufwerk liegt. Die dazugehörige Access Datei liegt ebenfalls auf dem NAS.
Nun ist es so, beim ersten Programmstart vom PC aus läuft die Anwendung super schnell, bis ein anderer PC auch über die selbe App auf die Access Datei zugreift.
In diesem Fall wird die Anwendung bei PC1 spürbar langsamer, nach eine kurzen Weile auch am PC2. (Aufruf eine SQL Abfrage 1 sek. zu 6-7 sek., manchmal 1 Minute).
Wenn die Apps langsamer arbeiten, werden diese auch nicht wieder schneller wenn kein weiterer Zugriff auf die Datenbank erfolgt. Steckt man den PC dann ab und wieder an, läufts nach einem Neustart der App wieder flink wie es sein soll. Da die PC's eigentlich direkt auf das NAS zugreifen, dürfte sich doch keine unterschiedliche Zugriffszeit ergeben.

Die Konfiguration: PC's -> Switch -> NAS

Mir erschließt es sich nicht, warum das Programm für die SQL Abfragen mal schnell und mal langsam ist.
Kann es sein, dass man bei der Datenbankverbindung etwas "besonderes" einstellen muss?


Bin ratlos, zumal ich schon einen anderen Switch probiert habe.
Hat jemand vielleicht eine Idee die mir bei dem Problem weiterhefen könnte?

LG Harry

[Sherlock]

Access ist bestenfalls eine kostenpflichtige Krücke, mit der man als Single-User etwas DB üben bzw. spielen kann. Sobald man das eingesehen hat, geht es zu freien Produkten wie PostgreSQL oder MariaDB, oder wenn es unbedingt Geld kosten muss, dann eben SQL Server.

[dummzeuch]

Vermutlich liegt es am File-Locking. Solange es nur einen User gibt, kann der einfach auf die Datei zugreifen ohne dass irgendwelches Locking stattfinden muss. Sobald ein zweiter User hinzukommt, wird es für den Fileserver komplizierter und damit der Zugriff langsamer.

Evtl. kannst Du in den Einstellungen des NAS (das vermutlich SAMBA benutzt) was einstellen, aber ich weiß leider nicht genau, was. Irgendwas mit "OpLock" sieht verdächtig aus.

[HCB]

Ich kann nicht auf eine andere DB umsteigen, Access ist nun mal vorgegeben. Es müssen SQL-Abfragen generiert werden damit mein Chef schneller und übersichtlicher an die Infos kommt, die das alte vorhandene Warenwirtschaftprogramm nicht hergibt. Gibt es für Firedac Verbindung eine performance optimierte Einstellung? Vielleicht kann man irgendwie die SQL Queries cachen? Was sollte ich noch probieren, die performance insgesamt zu verbessern? Es greifen nur 5 Arbeitsplätze auf die Access mdb zu.

LG Harry

[dummzeuch]

Zitat:

Zitat von HCB (Beitrag 1530592)

Es greifen nur 5 Arbeitsplätze auf die Access mdb zu.

Was MS Access angeht ist der zweite schon einer zuviel.

Solange es nur um lesenden Zugriff geht wäre es vielleicht möglich, die Access-db vor dem Zugriff auf ein lokales Laufwerk zu kopieren. Ich weiß, keine schöne Lösung. Kommt halt auf den Use-Case an, ob das möglich ist.

[Delphi.Narium]

Accessdatenbanken wachsen im Laufe der Zeit. Das kostet dann auch Geschwindigkeit.

In der ODBC-Verwaltung gibt es bei der Konfiguration für den Accesstreiber auch einen Button "Komprimieren". Wenn man diesen auswählt, wird eine Reorganisatzion der ausgewählten Datenbankdatei durchgeführt. Dabei "schrumpft" sie ggfls. beträchtlich und der Zugriff könnte anschließend wieder deutlich schneller sein.

Eventuell wäre es ja mal 'nen Versuch wert.

Automatisiert: Access Datenbank komprimieren und reparieren

Das zwei einer zuviel ist, glaub' ich jetzt nicht wirklich, zumindest lief eine von mir geschriebene Delphisoftware, mit 'ner Accessdatenbank auf 'nem Netzlaufwerk, über etliche Jahre mit 'nem halben Dutzend Anwenderinnen problemlos. (Ok, ist sowas um die 20 Jahre her.) Über die Perfomance hab' ich nie Klagen gehört.

Ist eine Accessdatenbank vorgegeben oder die Accessbenutzeroberfläche? Die kann es auch mit anderen Datenbanken, z. B. MS-SQL-Server oder alles das, was sonst so über ODBC möglich ist.

Literatur: Access als Frontend für MYSQL?

[hoika]

Hallo,
habt ihr mal probiert, einen "richtigen" Rechner anstatt das NAS zu benutzen?
Vielleicht hängt es ja an irgendeiner NAS-Einstellung.

[HCB]

Die .mdb lag vorher auf einem Win10 Rechner, da war das gleiche Problem (mal langsam mal schnell). Deshalb wurde vermutet das Windows im Hintergrund Updates läd, was das ganze verlangsamt und deshalb wurde ein NAS angeschafft, damit das ganze als reines Netzlaufwerk funktioniert. Ruft man die gleiche SQL Abfrage mit meinem Delphi-Programm immer wieder hintereinander ab, so dauert das erste Resultat 8-9 sek., die zweite Abfrage ca. 4 sek, jede weitere dauert immer unterschiedlich lang. Am der SQL Query kanns nicht liegen, da mit einem anderen Programm zum Testen immer die gleiche Ausführungsgeschwindigkeit besteht.
Wo wird eigentlich die Query ausgeführt, auf dem Nas wo ich das Programm aufrufe oder an dem Client PC?
Ich vermute, dass es vielleicht an der FDConnection liegt, die - wenn das eigentliche WW-Programm auch auf die .mdb zugreift - Verbindung irgendwie stört.

LG Harry

[dummzeuch]

Zitat:

Zitat von HCB (Beitrag 1530605)

Wo wird eigentlich die Query ausgeführt, auf dem Nas wo ich das Programm aufrufe oder an dem Client PC?

Auf dem Client-PC. MS-Access-Datenbanken haben keinen Server. Die Abfrage wird üblicherweise von der "Microsoft Access Database Engine" ausgeführt, die zusammen mit MS Access oder als eigener Client installiert wird. Die Zugriffe auf die MDB-Datei selbst sind immer reine Dateizugriffe.

[TigerLilly]

Eine Access Datenbank auf einen MSSQL Server zu verlagern ist nicht die Mörderhexerei. Den MSSQL Express gibt es kostenfrei, den kann man auch im Netz als Server einsetzen. Und wenn keine oder nicht allzuviele Access spezifische SQL Varianten benutzt werden, muss auch am Code nicht viel geändert werden.
Access schneller zu kriegen ist recht aussichtslos, da würde ich den Aufwand lieber in - siehe oben - stecken.

[Kas Ob.]

Zitat:

Zitat von HCB (Beitrag 1530592)

Ich kann nicht auf eine andere DB umsteigen, Access ist nun mal vorgegeben. Es müssen SQL-Abfragen generiert werden damit mein Chef schneller und übersichtlicher an die Infos kommt, die das alte vorhandene Warenwirtschaftprogramm nicht hergibt. Gibt es für Firedac Verbindung eine performance optimierte Einstellung? Vielleicht kann man irgendwie die SQL Queries cachen? Was sollte ich noch probieren, die performance insgesamt zu verbessern? Es greifen nur 5 Arbeitsplätze auf die Access mdb zu.

LG Harry

Hi,

Is by "Access" you mean MS Office Access the application and its interface ?
Because if that is what required then Office Access (also Excel) support ODBC and you can connect them to almost anything else (ant DB server/database provider), you are not limited to mdb providers.

Another idea is see if some sort of synchronization is possible with AccessDB and other providers using ODBC, here the slowness of AccessDB mdb will not kick unless you are doing write from mdb to the other side (you main DB), otherwise it will be simple insert/update/delete in mdb that will not affect you DB server, or at least has the minimum impact.

Well, that if i understood this right ?

Or may be you meant you boss SQL queries needs to be executed fast in robust way (may be they are complex), then do it the other way, first replicate/copy/export/import the mdb to your whatever (MySQL, MariaDB, MS SqlServer...) and find how fast enough these queries will perform again running them on mdb, evaluate the speed of such marshaling.
Also you still can utilize the ODBC mentioned above in finding faster and responsive way.


hope that helps.

[jobo]

Mit Access kann man viel machen, vieles leider suboptimal.

Ein Ansatz wäre, die eine Access mdb in Logik und Datenhaltung zu trennen.
Datenhaltung dann remote auf dem NAS.
Logik mdb lolal auf dem eigenen Rechner.

Dort werden alle Tabellen als Verknüpfung zur Daten mdb angelegt.

Falls die Daten sowieso nicht aus Access selbst stammen (originär dort gehalten werden), sondern selbst bloß eine Verknüpfung zu einem anderen System (z.B. Warenwirtschaft) sind (ODBC, ..), kann man vermutlich auch gleich dorthin verknüpfen.
Bei den Abfragen in solch einer Konstellation muss man beachten, ob man nativ (nativ zum Zielsystem) arbeitet (Pass Through) oder mit Access Bordmitteln. Die erste Variante ist optimal, die zweite kann zu beliebigen Problemen führen. Kann Access eine Remote Abfrage nicht richtig "interpretieren", macht es eine lokale Datenkopie der Servertabelle und arbeitet dann auf den lokalen Daten. Das kann bei großen Tabellen beliebig viel Zeit kosten. Aus diesem Grund würde man eher Pass Through Abfragen verwenden, als verknüpfte Tabellen.
Bei verknüpften Abfragen kann allerdings wieder ein Update problematisch sein.

[HCB]

Hallo und danke für die vielen Tipps,

nochmals zur Klarstellung: Es wird kein Microsoft Access Programm benutzt, weder von der Warenwirtschaft noch von meinem Delphi Programm.
Lediglich die Daten sind in einer AccessDB (xxx.mdb) gespeichert. Es gibt innerhalb dieser Datei auch keine Formulare, Abfragen etc.

Es greifen max. 5 User darauf zu, selten mehr wie zwei!
Wie soll das mit einem "Eine Access Datenbank auf einen MSSQL Server zu verlagern ist nicht die Mörderhexerei" funktionieren?
Die Warenwirtschaft sucht die mdb um darin zu speichern, der MSSql Server hat doch ein anderes Datenformat, oder?
Vielleicht gibt es irgendwo eine genaue Anleitung im Netz, hat jemand vielleicht einen Link?

LG Harry

[Delphi.Narium]

D. h.: Ihr habt eigentlich kein Access, außer einem Warenwirtschaftssystem, das eben 'ne Access-DB nutzt, um Infos zur Verfügung zu stellen. Ihr habt also letztlich keinen Einfluss auf die Art des Exportes, sondern müsst damit Leben und das Beste draus machen.

Bisher hatte ich das so verstanden, dass Ihr selbst einen "Datenextrakt" erstellt, um damit weiterzuarbeiten. Wenn Ihr aber letztlich keinen EInfluß darauf habt, wie euch die Daten zur Verfügung gestellt werden, sind alle Überlegungen in Richtung "Andere Datenbank verwenden", hinfällig.

Werden denn die Daten in der Access-DB von eurem Programm verändert oder ist es ein Nur-Lese-Zugriff für Auswertungen?

Wenn keine Änderungen an den Daten erfolgen, dann baut euch eine Job, Batch, wie auch immer, um die Datenbank auf die Clients zu kopiert. Z. B.: Beim Progammstart prüfen, ob die DB auf dem NAS neuer ist, als die auf dem Client und in dem Fall die Datebankdatei auf den Client kopieren.

Wenn die Datenbankdatei regelmäßg auf dem NAS erneuert, verändert wird, dann müsste man in entsprechenden Intervallen die Datei kopieren. Dazu müsste man aber etwas genauer die spezifischen Bedürfnisse in eurem Umfeld kennen.

[HCB]

Das WW-System sowie mein Delphi Programm kann in die AccessDB schreiben. Es werden in meinem Programm hauptsächlich Suchabfragen getätigt, aber auch gelegentlich Änderungen an Datensätzen durchgeführt. Ist aber trotzdem zu überlegen, die AccessDB Datei auf die Rechner zu kopieren wie vorgeschlagen. Muss ich mal probieren. Nur dann hat halt der jeweilige Client nicht immer die aktuellen Datensätze zur Verfügung.

Was die Ausführungsgeschwindigkeit der SQL Abfragen betrifft, ist mir immer noch nicht klar dass es mal so wie es jetzt ist, schnell geht und danach wieder langsam.
Es scheint wenn das WW-Programm zugreift, das Delphi Programm ausgebremst wird.

LG Harry

[TigerLilly]

Zitat:

Zitat von HCB (Beitrag 1530614)

Wie soll das mit einem "Eine Access Datenbank auf einen MSSQL Server zu verlagern ist nicht die Mörderhexerei" funktionieren?

MSSQL Server installieren
SQL Management Studio installieren
Neue leere Datenbank anlegen
Datenbank auswählen und via rechet Maustaste Tasks Import Data auswählen - hier kannst du als Quelle eine Access-DB übernehmen

Du hast dann die mdb als SQL Datenbank im Sql Server.
In deinem Programm hast du irgendwo die Verbindungsparameter zur Access-DB hinterlegt, die änderst du auf den zum Sql Server passenden Connection String.

Ich würde mit einem kleinen Testprogramm beginnen, das auf die ACCESS DB zugreift + erst einmal dieses umstellen.

Aber wie gesagt, ACCESS hat ein paar SQL Besonderheiten:
https://support.microsoft.com/de-de/...f-14a5eb7902c8

Schau auch mal hier.

[HCB]

@TigerLilly:
Ich habe deinen Vorschlag mal probiert, komme soweit im Management Studio 'Tasks > ImportData > Access > mdb auswählen > Next > Hier weiß ich nicht was ich als Ziel auswählen soll:
Hier werden einige .Net driver oder Provider angeboten, Flat File Destination, access oder excel, Microsoft OLE DB Driver oder Provider oder SQL Server Native Client.

Und im welchen Verzeichnis kann ich dann normalerweise die neu erstellte SQL-Datenbank finden?

LG Harry

[TigerLilly]

Siehe attached - als Ziel wählst du eine SQL Verbindung (zB Native Client), deinen SQL Server und aus dem die Datenbank (oder mit NEW eine neue).

[HCB]

@TigerLilly

Danke für die Hilfe. Die Access Datei wurde nun einwandfrei ohne Fehlermeldung konvertiert. Im SQL Manager kann ich mit select auch die Daten anzeigen lassen. Soweit alles ok.
LEIDER stelle ich jetzt erst fest,
dass a) das WW-Programm die neue Datei nicht öffnet und ohne Fehlermeldung abbricht,
und b) ich von der Delphi CE nicht per Firedac mangels MSSQL Treiber darauf zugreifen kann.

Insofern bleibt das Problem weiterhin bestehen. Die AccessDB lokal auf jeden PC zu kopieren geht auch nicht, da jeder User Änderungen an der Datei vornehmen kann und soll,
aber man weiß dann nicht welche Version nun aktuell ist.

LG Harry

[haentschman]

Zitat:

Und im welchen Verzeichnis kann ich dann normalerweise die neu erstellte SQL-Datenbank finden?

Die Datenbank im MSSQL ist, auch wenn es 2 Dateien sind, KEINE filebasierte Datenbank. Du solltest die Datenbank NIE manuell kopieren...oder so. :wink: Den Ordner legst du beim Setup des MSSQL Servers fest. Dort liegen ALLE Datenbanken nebeneinander.

Zitat:

Es greifen max. 5 User darauf zu, selten mehr wie zwei!

Der Server, ob MSSQL oder andere, muß auf einem Rechner, wo alle Zugriff haben, installiert sein. Die Clients greifen dann auf den Server zu.

:wink:

Nachtrag:
PS: MSSQL und mehrere Benutzer = nicht mehr local -> FireDAC und CE nur lokale Verbindungen = Lizenzverletzung

Vorschlag:
Datenbank Zugriffskomponenten ZEOS (kostenfreifrei mit CE und mehrere User), Kostenpflichtig z.B. UniDAC
Vorschlag2:
Vorteil: Datenbank Firebird. Server leistungsfähig wie MSSQL. Als Embedded (ohne Setup nur DLL) oder Server. Kleines Setup. Eine DLL im Programmverzeichnis. Datenbankdatei (eine Datei) ist kopierbar.
Import: https://www.clevercomponents.com/pro...pump/index.asp "Interbase DataPump is a freeware product: Download Interbase DataPump"

[TigerLilly]

Zitat:

Zitat von HCB (Beitrag 1530725)

dass a) das WW-Programm die neue Datei nicht öffnet und ohne Fehlermeldung abbricht,

Wie gesagt, ich würde zuerst ein Testprogramm machen, das auf die Acess-DB zugreift + das änderst du dann auf den SQL Server. Dann weißt du, dass das mal funktioniert.

Zitat:

und b) ich von der Delphi CE nicht per Firedac mangels MSSQL Treiber darauf zugreifen kann.

Dann muss wohl wer Geld in die Hand nehmen. Besser das, als Aufwand in die Access-DB stecken.

Aber: Ich hab keine CE, das wissen andere wohl besser. Mit dbExpress oder ADO geht da auch nix?

[MEissing]

dbExpress ist deprecated. Mit ADO sollte es gehen.

[HCB]

Also mit einem Testprogramm kann ich mittels ADOConnection auf die SQL Datei schon mal zugreifen. Bis die Verbindung hergestellt ist, dauert aber 8 sek. und das, obwohl der SQL-Server und das Programm lokal läuft! Jedoch verweigert das Warenwirtschaftsprogramm den Pfad und die .mdf Datei. Das Programm schließt automatisch ohne eine Fehlermeldung.
Die Software erwartet wahrscheinlich eine .mdb Datei. Die Endung umbenennen wird wahrscheinlich auch nichts bringen, kann ich aber mal probieren.

Ansonsten habe ich immer noch keine Erklärung warum in meinem Delphi Programm die selbe SQL Abfrage immer unterschiedlich lange dauert.
Vielleicht irgendwelche Ideen?

LG Harry

[MEissing]

File-Locking (die MDB liegt ja auf einem NAS) und die (un)passende SMB Version des NASs. </Spekulation>

[haentschman]

Moin...😎

Zitat:

Jedoch verweigert das Warenwirtschaftsprogramm den Pfad und die .mdf Datei.

...irgendwie habe ich das Warenwirtschaftssystem verpaßt.:roll: Das heißt, daß du ein Warenwirtschaftssystem hast, Hersteller xy? Dieses hat Access als Datenbank. Dein Programm greift auch auf die Access Datenbank zu. Die Datenbank kannst du so nicht einfach wechseln! :warn:

Sorry, aber du weißt nicht viel über Datenbanken. :wink:

Zitat:

Jedoch verweigert das Warenwirtschaftsprogramm den Pfad und die .mdf Datei. Das Programm schließt automatisch ohne eine Fehlermeldung.
Die Software erwartet wahrscheinlich eine .mdb Datei.

...allerdings. Das zeigt mir, daß du das Warenwirtschaftssystem nicht programmiert hast. Das Warenwirtschaftssystem gibt in diesem Falle die Datenbank vor.

Zitat:

Ansonsten habe ich immer noch keine Erklärung warum in meinem Delphi Programm die selbe SQL Abfrage immer unterschiedlich lange dauert.

...gefühlt stehst du wieder am Anfang. :?

PS:

Zitat:

Pfad und die .mdf Datei

Bei MSSQL kennt nur der Datenbankserver die .mdf Datei. Die Programme greifen nur über den Namen der Datenbank und SQL auf die Daten zu.

:wink:

[HCB]

Danke an alle für die Mithilfe. Leider gänzlich ohne Erfolg :x

Ich habe aber eben erfahren, dass voraussichtlich ab 2025 die Rechnungen aus der WW im X-Rechnung oder ZugFerd Format erstellt werden müssen. Dies kann das alte Warenwirtschaftssystem nicht. Deshalb schlage ich meinem Chef vor, eine neue Software anzuschaffen. Damit habe ich hoffentlich das Problem vom Hals.

Da werde ich mich wahrscheinlich nach einer geeigneten Warenwirtschaft umsehen müssen.
Habt Ihr Vorschläge welches System für ein kleines Unternehmen (6 Mitarbeiter) geeignet wäre, bzw. mit welcher Datenbank die Zugriffe besonders schnell von statten gehen?

LG Harry

[haentschman]

Zitat:

kleines Unternehmen (6 Mitarbeiter)

Branche? :wink:

[HCB]

Oh sorry, die Branche ist Handel / Großhandel.

[paule32.jk]

SAP zu teuer ? hihi

Es gibt im Netz aber auch eine "Einsteiger" Version - die ist kostenlos, dient aber eher nur für "nächste" Kunden - also sowas wie: "Ich bring Dir was bei, wenn Du bei mir anfängst.".

Diese Datenbank ist aber nichts für kleine Computer.

Dafür kommt aber dieses "Einsteiger" Paket mit Beispielen und Codeschnippseln, wie man dann diesen SAP Server bedienen kann. Die Programmiersprache dort heißt aber ABAP, und ist speziell von dieser SAP Firma gemacht und angepasst worden.

Jetzt mal schnell so in eine Firma, die SAP verwendet "reinzukommen" ist ein langes unterfangen.
Zumal geht da meist mit keinen Studium für IT oder Kaufmann nichts - oder halt versuchen über: "der kennt denn, vom dem ich kenne ... - wisste wie?

Nun, Firmen, die ab 5 Mann aufwärts auftretten, verwenden kein ACCESS.
Das ist was für indische IT'ler, die mit Support bei Laune gehalten werden sollen, oder für Hobby-Köche, die Ihre Rezepte beim Kaffeeklatsch mit Oma Renate ihre Zeit verbringen.

Wenn's denn dann schärfer gehen soll, so mit Lizenzen für ALLES, dann ist Microsoft keine schlechte Wahl.
Die Programme kennt Jeder, nutzt Jeder, also auch STINO-Software.

[johndoe049]

Zitat:

Zitat von HCB (Beitrag 1530783)

Oh sorry, die Branche ist Handel / Großhandel.

Was wird bisher eingesetzt. Dann kann man was besseres Empfehlen.

Für 5 Personen würde ich
Amicron
Prosaldo
Lexware (aber nur mit guter Backupstategie)
Orgamax
Sage
Weclapp
Buhl

empfehlen. XRechnung haben einige schon implementiert.

Wenn ganz günstig/kostenlos sein soll
JTL Wawi
Vario (eingeschränkt)

Ob die allerdings XRechnung bis 2025 haben muss man sehen.



Kommt darauf an, was an Auswertungen gemacht werden bzw. schon incl. sein soll.


Thema Access:
Wenn der Hersteller in den SQL Statements für Update bzw. Select nicht aufpasst, kann es lt. Kollegen schnell zu gelocketen Tabellen und nicht nur Records kommen. Dann wird das ganze langsam.
Kann aber auch ein schlechtes Freigabeverhalten auf der NAS sein.

[TuPas]

Hallo,

ich hatte mal eine ELO Office von einem Windows PC auf ein Synology-NAS umgezogen.
ELO Office verwendet auch eine Access-Datenbank.
Das war dann merklich langsamer trotz oplocks-Optimierung in den SAMBA-Einstellungen.

Wichtig ist auf jeden Fall, da es rein filebasierend ist, dass man den Pfad und ggf. die Dateiendungen vom Virenscanner ausschließt. Das kann schon mal etwas bringen.

Aber Access und Multi-User ist - wie auch schon alle geschrieben haben - alles andere als optimal.

TuPas