verknüpfte Tabelle reagiert nicht oder nur sehr langsam

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

Um darauf noch mal einzugehen: gibt es einen triftigen Grund für diese Kombination? Wäre ich Du, würde ich alles in einer DB machen, und zwar weder in Access noch in MySQL. Und auch nicht in MariaDB.
 
Werbung:
Hallo akretschmar,

Zitat:"Ein Select ohne Where zieht IMMER einen Fulltablescan nach sich"
Ja, ich wusste nun nur nicht genau was ich mit Explain anfangen sollte. O.K. mein Problem, befasse ich mich mit..

Habe nun MS SQL und MySQL getestet. Sobald ich mit WHERE einschränke und in dem Abfrageergebnis herumscrolle ist es jetzt so, dass sich Maria besser verhält als MS SQLExpress. Ich probiere das jetzt einfach noch ein bisschen aus.

Danke an Alle für eure Unterstützung, Gruß Babsi
 
Das mit dem Scrollen sollte eigentlich kein DB Problem sein (egal welche), die liefert ja normalerweise alles an den Client aus und der ist für die Anzeige da.
 
PostgreSQL. Freier als MySQL, deutlich mehr Features als MySQL, deutlich SQL-konformer als MySQL.
Moin akretschmar,

O.k. war ne weile raus aus dem ganzen Thema Datenbanken, sorry wegen meines Unwissens. PostgreSQL habe ich natürlich von gehört mich aber noch nie damit beschäftigt. werde ich mir auf jeden Fall ansehen. Und danke für den Tipp.
 
Moin Ukulele, auch Dir schönen Dank für den Hinweis. :) Kann gut sein dass das an der Netzwerkkonfiguration liegt.

Das muß nicht am Netzwerk liegen, Wenn die Tabelle groß ist und der Client die z.B. nicht paginiert anzeigt und das ganze auch noch graphisch, dann muß der eine sehr große graphische Darstellung erzeugen, die anzuzeigen enorm speicherfressend bzw. auch rechenintensiv ist. Das ist kein DB-Problem und auch keines des Netzwerkes.
 
Hallo akretschmar,

ich habe jetzt PostgreSQL installiert und Problem mit den Treibern Windows 64 bit System habe ich hier. Ich kann den Treiber von ACCESS Seite aus sehen, vom Rechner aus aber nicht(Verwaltung->ODBC Datenquelle usw.) hast Du da noch mal einen Rat?
 
Das muß nicht am Netzwerk liegen, Wenn die Tabelle groß ist und der Client die z.B. nicht paginiert anzeigt und das ganze auch noch graphisch, dann muß der eine sehr große graphische Darstellung erzeugen, die anzuzeigen enorm speicherfressend bzw. auch rechenintensiv ist. Das ist kein DB-Problem und auch keines des Netzwerkes.
Tja, das ist keine große graphische Darstellung nur ne Abfrage, entweder durch WHERE Klausel eingeschränkt oder ein Join zu einer anderen Tabelle. Alles eben total lahm.

Und ich kann das auch nicht mal eben so ändern, dazu ist das ganze zu Umfangreich und die Leute müssen hier damit arbeiten. Es geht jetzt erst mal darum eine Tabelle auf den Server zu legen weil die zu schnell zu groß wird, das ist eigentlich alles.
 
Hallo akretschmar,

ich habe jetzt PostgreSQL installiert und Problem mit den Treibern Windows 64 bit System habe ich hier. Ich kann den Treiber von ACCESS Seite aus sehen, vom Rechner aus aber nicht(Verwaltung->ODBC Datenquelle usw.) hast Du da noch mal einen Rat?

Nicht wirklich. Access kenne ich nur vom Hörensagen, ODBC nicht viel anders. Ich bin fast nur auf *NIX unterwegs.
 
Und ich kann das auch nicht mal eben so ändern, dazu ist das ganze zu Umfangreich und die Leute müssen hier damit arbeiten. Es geht jetzt erst mal darum eine Tabelle auf den Server zu legen weil die zu schnell zu groß wird, das ist eigentlich alles.
Einerseits kenne ich diese Situation und bin völlig für verhältnismäßige Lösungsansätze. Andererseits ist das Problem klassisch. Ihr habt euch für Access als Front-End und Back-End entschieden und die Lösung skaliert nicht ausreichend / wird den Anforderungen nicht mehr gerecht.

Du versuchst jetzt, das Back-End durch eine SQL DB zu ersetzen, ein völlig logischer und auch erstrebenswerter Schritt. Nun ist aber das Problem mit dem Scrollen und der lahmen Performance mit drei doch recht unterschiedlichen DBs ähnlich gelagert. Wir müssen also davon ausgehen das ODBC als Verbindung oder eben Access als Front-End hier schwächeln. Ich tippe mal auf Access, zumindest was das Ruckeln angeht.

Ich könnte mir vorstellen, das es eine Lösung gibt. Erlich gesagt glaube ich aber nicht das wir sie finden. Da in das Problem zumindest ODBC und Access involviert sind und ich nicht weiß, in wie weit ihr bereit seid, in die Ergründung des Problems zu investieren (MS Support beauftragen etc., wer will das schon bezahlen), muss man andere Optionen auf den Tisch bringen.

Langfristig wäre sicher ein Austausch von Access erstrebenswert aber da wären wir dann weit weg von einer simplen Lösung. Du wirst möglicherweise wieder mit einer Access DB als Back-End arbeiten und versuchen müssen, die Menge der Daten zu reduzieren. Vieleicht kannst du alte Datensätze in SQL auslagern? Oder, zur Not, Daten zwischen einer Client-Access-DB und einem SQL Server synchronisieren?

Ich wünsche dir zumindest Erfolg, vieleicht klappts ja doch noch mit ODBC. Ne Idee hab ich aber nicht mehr, dazu fehlt mir die Erfahrung.
 
Ich wünsche dir zumindest Erfolg, vieleicht klappts ja doch noch mit ODBC. Ne Idee hab ich aber nicht mehr, dazu fehlt mir die Erfahrung.

Ich denk mal, das Hauptproblem ist die Arbeitsweise. Ich interpretiere die bisherigen Aussagen so, daß man immer auf dem Bildschirm die ganze Tabelle sa und dann da drin rumoperierte. Das geht so auch wunderschein mit Desktop-Datenbanken und Datenbanken, die in der Größe eine solche Arbeitsweise noch zulassen.

Bei 'richtigen' Datenbanken, also echten Client-Server - Systemen, wird in den seltesten Fällen der ganze Kram vom Server zum Client geschoben, sondern der Client holt sich exakt das, was er benötigt - also 1 Datensatz oder das Resultat einer Aggregation oder sendet den Wunsch, mal einen Datensatz zu ändern, an den Server. Dann ist es auch egal, ob zwischen Server und Client nun ein armdickes Glasfaserkabel ist oder ein dünner Klingeldraht.

Inserfern hat @ukulele vollkommen Recht: es gibt keine einfache, schnelle Lösung, wenn man nicht bereit ist, die komplette Arbeitsweise zu hinterfragen.
 
Werbung:
Einerseits kenne ich diese Situation und bin völlig für verhältnismäßige Lösungsansätze. Andererseits ist das Problem klassisch. Ihr habt euch für Access als Front-End und Back-End entschieden und die Lösung skaliert nicht ausreichend / wird den Anforderungen nicht mehr gerecht.

Du versuchst jetzt, das Back-End durch eine SQL DB zu ersetzen, ein völlig logischer und auch erstrebenswerter Schritt. Nun ist aber das Problem mit dem Scrollen und der lahmen Performance mit drei doch recht unterschiedlichen DBs ähnlich gelagert. Wir müssen also davon ausgehen das ODBC als Verbindung oder eben Access als Front-End hier schwächeln. Ich tippe mal auf Access, zumindest was das Ruckeln angeht.

Ich könnte mir vorstellen, das es eine Lösung gibt. Erlich gesagt glaube ich aber nicht das wir sie finden. Da in das Problem zumindest ODBC und Access involviert sind und ich nicht weiß, in wie weit ihr bereit seid, in die Ergründung des Problems zu investieren (MS Support beauftragen etc., wer will das schon bezahlen), muss man andere Optionen auf den Tisch bringen.

Langfristig wäre sicher ein Austausch von Access erstrebenswert aber da wären wir dann weit weg von einer simplen Lösung. Du wirst möglicherweise wieder mit einer Access DB als Back-End arbeiten und versuchen müssen, die Menge der Daten zu reduzieren. Vieleicht kannst du alte Datensätze in SQL auslagern? Oder, zur Not, Daten zwischen einer Client-Access-DB und einem SQL Server synchronisieren?

Ich wünsche dir zumindest Erfolg, vieleicht klappts ja doch noch mit ODBC. Ne Idee hab ich aber nicht mehr, dazu fehlt mir die Erfahrung.
Morgen Ukulele,
Danke für die guten Wünsche, wird schon.
Dieses System läuft hier seit fast 18 Jahren und ist eben immer erweitert worden, genauso entstanden wie es nicht gemacht werden soll, aber eben oft gemacht wird. Ich bin erst seit kurzem hier und habe mich da gerade eingearbeitet. Insgesamt sind das 18 DB' s alles ACCESS wobei eines nur das FE ist. Auf diese ganzen Backend-DB' s wird über das Netzt zugegriffen. Diese eine Tabelle, um die es da geht ist eben sehr groß und wie schon erwähnt soll nur diese eine auf den Server gelegt werden. Alles andere wird neu gemacht, ja aber eben nicht in 2 Monaten das dauert bestimmt ein Jahr. Solange muss das hier laufen.
Wir werden als FE übrigens ACCESS behalten. Wenn das vernünftig programmiert ist das doch O.K.. Wie schon erwähnt, da arbeiten ganz andere Firmen mit.
In der Regel, mit MS SQL habe aber auch schon Oracel und MySQL gesehen.
Ich hatte das ja auch schon soweit, dass das mit dem MS SQL gut lief, nur jetzt eben ist das zu langsam. das liegt nicht am ACCESS, werde den Fehler schon finden.
Vielen Dank für die Unterstützung.
Gruß, babsi
 
Zurück
Oben