Access Datenbank langsam

[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"