verknüpfte Tabelle reagiert nicht oder nur sehr langsam

[Babsi]

Hallo,

ich habe Maria DB heruntergeladen und möchte nun auf eine Tabelle zugreifen. Die ist über ACCESS 2003 realisisert. Die Tabelle habe ich zuerst mit ACCESS exportiert und jetzt die Tabelle verknüpft. Diese ist ziemlich groß, deswegen auch die Mgration nach MySQL/ Maria. jetzt, wenn ich die Tabelle öffnen reagiert die Tabelle aber extrem langsam, das öffnen dauert ewig und das z.B. scrollen auch.
Ich benutze als ODBC den neusten Treiber ODBC.5.3 ANSI.

Gruß, Babsi

 

[ukulele]

Liegt die Tabelle weiterhin in einer Access Datei und wird sie nur in Maria DB verknüpft oder wurde diese wirklich in Maria DB importiert? Ersteres würde vermutlich die Performance erklären.

 

[Babsi]

Hallo, nein, die liegt schon richtig in der MariaDB., Ich verknüpfe dann nach ACCESS. Sieht man dann ja auch an der Kugel als Symbol für die Tabelle.

 

[ukulele]

Ich kenne mich weder mit Maria DB noch mit Access wirklich aus aber das hört sich für mich nach einem Access Problem an. Womöglich ist Access ab einer gewissen Datenmenge auch einfach nicht mehr die richtige Wahl.

 

[Babsi]

Hallo Ukulele,

danke für deine Statemnets.
Ich denke dass es eher was mit dem ODBC Treiber zu tun hat. Ich kenn eine Menge unternehmen, die mit ACCESS als Frontend arbeiten und riesiges Datenmengen verarbeiten. Und mit dem SQL- Server, den ich zuerst benutzt habe lief ja auch alles super. Nun soll aber doch eine kostenloses Toll her, und mit MySQL klemmt es eben, aber gegen MySql gibt's ja eigentlich nichts einzuwenden, das muss doch mit der Kommunikation der beiden Systeme zusammenhängen und das ist ja nun mal dieser ODBC- Treiber. Mist, irgendwie muss ich da hinkriegen.

 

[akretschmer]

Ich denke dass es eher was mit dem ODBC Treiber zu tun hat. Ich kenn eine Menge unternehmen, die mit ACCESS als Frontend arbeiten und riesiges Datenmengen verarbeiten.

Ich kenne Leute, die hosten auf Windows und nutzen Access. Und das knallt dann schon bei sehr geringen Datenmenge. Das ist halt einfach das falsche Tool in einer Multiuser-Umgebung.

Und mit dem SQL- Server, den ich zuerst benutzt habe lief ja auch alles super. Nun soll aber doch eine kostenloses Toll her, und mit MySQL klemmt es eben, aber gegen MySql gibt's ja eigentlich nichts einzuwenden

Nein, natürlich nicht, ...

, das muss doch mit der Kommunikation der beiden Systeme zusammenhängen und das ist ja nun mal dieser ODBC- Treiber. Mist, irgendwie muss ich da hinkriegen.

ODBC ist in der Tat nicht wirklich für Performance bekannt. Aber vielleicht solltest Du einfach mal ergründen, was die Bremse ist. Dazu könnte explain schon hilfreich sein. Sogar unter MySQL...

 

[ukulele]

Alternativ könnte man MSSQL Express nutzen, da klappts bestimmt mit der ODBC / Access Zusammenarbeit besser.

 

[Babsi]

@akretschmar
Hallo, habe das mit dem Explain ausrobiert, hier das Ergebnis,
EXPLAIN SELECT * FROM ZV;


/* Affected rows: 0 Gefundene Zeilen: 1 Warnungen: 0 Dauer von 1 query: 0,000 sec. */
Aber das mach ich doch auf dem Server, was soll mir das denn bringen?



@ukulele,
hatte ich zuerst drauf aber diese abgespeckte Version klappt doch auch nicht 100%ig mit den verknüpften Tabellen.

 

[ukulele]

Express ist eigentlich nicht abgespeckt, die Einschränkungen sind viel mehr Nutzung von CPU Kernen und RAM sowie größe der Datenbank. ODBC muss hier 100% laufen da alle beteiligten Softwarekomponenten ja von MS kommen sollte das sehr schmerzfrei sein.

 

[Hony%]

jetzt, wenn ich die Tabelle öffnen reagiert die Tabelle aber extrem langsam, das öffnen dauert ewig und das z.B. scrollen auch.

Meinst du scrollen in der Access-Anwendung? Wie viel Prozessorlast wird den erzeugt? Möglicherweise holt Access jeden Datensatz einzeln aus der Datenbank. Damit bekommst du sogar In-Memory Systeme in die Knie.

/* Affected rows: 0 Gefundene Zeilen: 1 Warnungen: 0 Dauer von 1 query: 0,000 sec. */

Ein SELECT auf eine leere Tabelle sollte immer schnell sein. Wenn nicht ist die Installation kaputt. Interessant wäre ein EXPLAIN einer echten und langsamen Abfrage.

da alle beteiligten Softwarekomponenten ja von MS kommen sollte das sehr schmerzfrei sein.

MS hat ja nicht einmal das eigene COM+ 100% im Griff.

 

[Babsi]

Hi Ukulele,
ja, gut wenn ich das den gar nicht anders hinbekomme werde ich den Express installieren.

 

[Babsi]

Meinst du scrollen in der Access-Anwendung? Wie viel Prozessorlast wird den erzeugt? Möglicherweise holt Access jeden Datensatz einzeln aus der Datenbank. Damit bekommst du sogar In-Memory Systeme in die Knie.

Ja, das Scrollen in den Tabelle, keene Ahnung wieviel Prozessorlast damit erzeugt wird, müsste ich mal schauen.

Ein SELECT auf eine leere Tabelle sollte immer schnell sein. Wenn nicht ist die Installation kaputt. Interessant wäre ein EXPLAIN einer echten und langsamen Abfrage.
ja, sorry, mein fehler

MS hat ja nicht einmal das eigene COM+ 100% im Griff.

 

[akretschmer]

@akretschmar
Hallo, habe das mit dem Explain ausrobiert, hier das Ergebnis,
EXPLAIN SELECT * FROM ZV;


/* Affected rows: 0 Gefundene Zeilen: 1 Warnungen: 0 Dauer von 1 query: 0,000 sec. */
Aber das mach ich doch auf dem Server, was soll mir das denn bringen?

Äpfel und Birnen miteinander zu vergleichen hat ja auch keinen Sinn. Wenn ein Select ohne Where 0 Zeilen liefert ist die Tabelle leer. Du sagtest aber, das Blättern in der Tabelle sei langsam. Wie blätterst Du in einer leeren Tabelle?

 

[Babsi]

Hallo akretschmar,

das Ergebnis lautet:




Das sind also ne ganze menge DS drinn.
Sorry für das Result gestern, kann nicht stimmen.
Was kann ich denn jetzt damit anfangen?

 

[akretschmer]

Hallo akretschmar,

das Ergebnis lautet:



Das sind also ne ganze menge DS drinn.
Sorry für das Result gestern, kann nicht stimmen.
Was kann ich denn jetzt damit anfangen?

Ein Select ohne Where zieht IMMER einen Fulltablescan nach sich, da kannst Du nix machen.