Zu viele Indizes - Access 2007
Hallo zusammen,
beim verknüpfen eine bestimmten Tabelle aus einer MSSQL-DB erscheint die Meldung, dass zu viele Indizes bestehen.
Die Tabelle kann also nicht verknüpft werden.
Bei kleineren Tabellen dieser DB besteht dieses Problem nicht.
Jedoch bräuchten wir alle Inhalte dieser einen Tabelle. Es handelt sich dabei um ca. 100000 Datensätze.
Ist etwas bekannt über eine Beschränkung der angezeigten Datensätze in Access?
Meines Wissens gab es bei Access 97 standardmäßig eine Einschränkung auf 10000 Sätze die man auf ca. 32000 hochsetzen konnte.
Hoffe ihr könnt mir helfen
Danke schon mal
Gruß Daniel
beim verknüpfen eine bestimmten Tabelle aus einer MSSQL-DB erscheint die Meldung, dass zu viele Indizes bestehen.
Die Tabelle kann also nicht verknüpft werden.
Bei kleineren Tabellen dieser DB besteht dieses Problem nicht.
Jedoch bräuchten wir alle Inhalte dieser einen Tabelle. Es handelt sich dabei um ca. 100000 Datensätze.
Ist etwas bekannt über eine Beschränkung der angezeigten Datensätze in Access?
Meines Wissens gab es bei Access 97 standardmäßig eine Einschränkung auf 10000 Sätze die man auf ca. 32000 hochsetzen konnte.
Hoffe ihr könnt mir helfen
Danke schon mal
Gruß Daniel
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 138003
Url: https://administrator.de/contentid/138003
Ausgedruckt am: 05.11.2024 um 02:11 Uhr
5 Kommentare
Neuester Kommentar
Hallo Hugi1987!
Der Fehler bezieht im eigentlichen Sinne nicht auf die maximale Anzahl aller Datensätze , sondern darauf, wenn Du z.B. versuchst in einer Abfrage in einem Feld mehr als einen Datensatz einzulesen. D.h., wenn mehr als ein Treffer möglich ist, z.B. Where Name="Hans" und es gibt mehrere "Hans"..., dann sind das zuviele Indizes. Sowas in der Art.
Gruß Dieter
Der Fehler bezieht im eigentlichen Sinne nicht auf die maximale Anzahl aller Datensätze , sondern darauf, wenn Du z.B. versuchst in einer Abfrage in einem Feld mehr als einen Datensatz einzulesen. D.h., wenn mehr als ein Treffer möglich ist, z.B. Where Name="Hans" und es gibt mehrere "Hans"..., dann sind das zuviele Indizes. Sowas in der Art.
Gruß Dieter
moin Hugi1987,
ich interpretiere die zitierte Fehlermeldung anders als didi1954.
IMHO ist wirklich die Anzahl der Indices auf einer Tabelle gemeint - diese darf bei Access AFAIK nicht den Wert 32 überschreiten.
Kann es sein, dass diese eine Tabelle evtl mehr Indexe (nicht vergessen die Foreign Keys mitzuzählen!) enthält in MSSQL?
Grüße
Biber
ich interpretiere die zitierte Fehlermeldung anders als didi1954.
IMHO ist wirklich die Anzahl der Indices auf einer Tabelle gemeint - diese darf bei Access AFAIK nicht den Wert 32 überschreiten.
Kann es sein, dass diese eine Tabelle evtl mehr Indexe (nicht vergessen die Foreign Keys mitzuzählen!) enthält in MSSQL?
Grüße
Biber
Hallo Daniel,
ich würde mal versuchen das etwas einzuschränken.
Gestalte doch mal über ein View eine Variante derselben Tabelle die weniger als zB 10.000 Datensätze ausgibt. (zB where ID < 10.000)
Wenn er das in Access fehlerlos anzeigt, liegt es an der Anzahl der Datensätze.
Mit welcher Access Version arbeitest du ?
Vielleicht kannst du dir über eine dynamisch erstellte Pass-trough (schreibt man das so ? ;O) ) Abfrage behelfen und so etwas vorfiltern,
ohne dem User generell Datensätze vorzuenthalten.
Es wird sich ja niemand die ganzen 100.000 DS in einem Zuge ansehen wollen...
Oder vielleicht geht es ja generell mit ner pass-trough ?
ich würde mal versuchen das etwas einzuschränken.
Gestalte doch mal über ein View eine Variante derselben Tabelle die weniger als zB 10.000 Datensätze ausgibt. (zB where ID < 10.000)
Wenn er das in Access fehlerlos anzeigt, liegt es an der Anzahl der Datensätze.
Mit welcher Access Version arbeitest du ?
Vielleicht kannst du dir über eine dynamisch erstellte Pass-trough (schreibt man das so ? ;O) ) Abfrage behelfen und so etwas vorfiltern,
ohne dem User generell Datensätze vorzuenthalten.
Es wird sich ja niemand die ganzen 100.000 DS in einem Zuge ansehen wollen...
Oder vielleicht geht es ja generell mit ner pass-trough ?
Moin jknapp,
ist zwar durchaus zielführend gemeint, dein Ansatz des Fehler-Ursachen-Ausschliessens (ohne Ironie), aber...
--> den Schlenker können wir uns sparen.
"Zu viele Indizes" bedeutet "zu viele indizes" und nicht "zu viele Zeilen" oder "zu langer Scrollbalken".
Es geht hier, wenn ich es richtig verstanden habe, um eine "verknüpfte Tabelle", d.h. das doofe Access belässt die Original-Tabellen-Daten dort, wo sie physikalisch liegen, also auf dem MSSQL-Server.
Was allerdings lokal (quasi als zusätzliche Kopie) angelegt wird sind
Und das läppert sich... und außerdem: echte DBMSe können das händeln mit 128 indexen je Tabelle und legen auch nicht blind bereits vorhandene Indexe nochmal an.
Access dagegen hat bei verknüpften Tabellen keine Wahl, es ist halt genau so strohdoof programmiert. oder wie es auf neudeutsch heißt "straight forward.
Wer jetzt wieder meint, ich würde nur die Redmonder PraktikantInnen mit Schmutz bewerfen, kann genau diese Mimik im "Microsoft Jet Database Engine Programmer’s Guide" nachlesen.
@Hugi1987
Wenn du da tatsächlich auf einen Poller läufst, kannst du es nicht (bzw nicht ohne aufwändig programmierten Workaround) abstellen bei einer "verknüpften Tabelle".
Mit "aufwändig" meine ich zwar nur VBA, aber leider Gates unter Nutzung von Aufrufen, die NICHT in der Access-Online-Hilfe stehen.
Aber: Wenn es doch nur ein paar 10000 Sätze sind oder auch 100000... so what?
Importiere das Gelumpe (also diese eine Tabelle) vollständig lokal runter.
Alles, was weniger als 250000 Zeilen hat ist eine auf einem normalen Desktop-PC verarbeitbare Datenmenge.
Selbst so ein Krams wie Excel kann doch neuerdings schon roundabout 130000 Zeilen, und das ist nicht für Massendaten gedacht.
Grüße
Biber
[Edit] @Hugi1987 - mein Kommentar hat sich gerade überschnitten mit deinem Post.
Mit einem neuen View gehts natürlich auch - ein View hat keine FKs oder Relationen...
[/Edit]
ist zwar durchaus zielführend gemeint, dein Ansatz des Fehler-Ursachen-Ausschliessens (ohne Ironie), aber...
--> den Schlenker können wir uns sparen.
"Zu viele Indizes" bedeutet "zu viele indizes" und nicht "zu viele Zeilen" oder "zu langer Scrollbalken".
Es geht hier, wenn ich es richtig verstanden habe, um eine "verknüpfte Tabelle", d.h. das doofe Access belässt die Original-Tabellen-Daten dort, wo sie physikalisch liegen, also auf dem MSSQL-Server.
Was allerdings lokal (quasi als zusätzliche Kopie) angelegt wird sind
- alle explizit angelegten Indices (Also PKs, Alternate keys und "Sortier"-Indizes) der Original-Tabelle --> 1 Access-index pro 1 Original-Index
- zusätzlich ein hidden index für jede beknackte Relation, jeden Foreign key, auch wenn genau dieser Index schon existiert als expliziter Index
Und das läppert sich... und außerdem: echte DBMSe können das händeln mit 128 indexen je Tabelle und legen auch nicht blind bereits vorhandene Indexe nochmal an.
Access dagegen hat bei verknüpften Tabellen keine Wahl, es ist halt genau so strohdoof programmiert. oder wie es auf neudeutsch heißt "straight forward.
Wer jetzt wieder meint, ich würde nur die Redmonder PraktikantInnen mit Schmutz bewerfen, kann genau diese Mimik im "Microsoft Jet Database Engine Programmer’s Guide" nachlesen.
@Hugi1987
Wenn du da tatsächlich auf einen Poller läufst, kannst du es nicht (bzw nicht ohne aufwändig programmierten Workaround) abstellen bei einer "verknüpften Tabelle".
Mit "aufwändig" meine ich zwar nur VBA, aber leider Gates unter Nutzung von Aufrufen, die NICHT in der Access-Online-Hilfe stehen.
Aber: Wenn es doch nur ein paar 10000 Sätze sind oder auch 100000... so what?
Importiere das Gelumpe (also diese eine Tabelle) vollständig lokal runter.
Alles, was weniger als 250000 Zeilen hat ist eine auf einem normalen Desktop-PC verarbeitbare Datenmenge.
Selbst so ein Krams wie Excel kann doch neuerdings schon roundabout 130000 Zeilen, und das ist nicht für Massendaten gedacht.
Grüße
Biber
[Edit] @Hugi1987 - mein Kommentar hat sich gerade überschnitten mit deinem Post.
Mit einem neuen View gehts natürlich auch - ein View hat keine FKs oder Relationen...
[/Edit]