zu langer SQL Code im Abfrageentwurf?

[TTB]

Hallo liebe Leute,

ich habe mir eine Abfrage zusammengebastelt und es ist ziemlich viel SQL Code geworden. Jetzt liefert mir Access 2013 folgende Fehlermeldung:

"Der Ausdruck, den Sie eingegeben haben, überschreitet die 1.024-Zeichengrenze des Abfrageentwurfsbereichs"

Ich benutze die Entwurfsansicht so gut wie gar nicht und kann drauf verzichten. Meine Frage ist nur:

Ist jetzt nur die Entwurfsansicht "gesperrt" oder bringt das Ganze auch Funktionsbeeinträchtigungen mit sich?

Für Hilfe wäre ich sehr dankbar!

lG
Chris

[TTB]

Entschuldigt bitte. Probieren geht über studieren.

Es funktioniert noch alles.

Aber weiß jemand, ob es auch beim Code solche Einschränkungen gibt?

[DF6GL]

Hallo,

ob die 1024-Zeichenlänge eines Ausdrucks in einem SQL-String auch beim Zusammenbau mit VBA gilt, kann ich jetzt nicht sagen.

Ich frage mich allerdings, warum Du auf die Nutzung des Abfrageentwurfs verzichtest...   ?


Wie lautet denn dieser Roman des Ausdrucks?

[PhilS]

Aber weiß jemand, ob es auch beim Code solche Einschränkungen gibt?

Es gibt Einschränkungen.
Der SQL-Text in Rowsource/Recordsource darf 2048 Zeichen nicht überschreiten. Für den SQL-Text in der SQL-Ansicht einer Abfrage kenne ich kein hartes Limit, aber wenn dieser SQL-Text länger ist als 4096 Zeichen, kann es  Probleme in Verbindung mit der Abfrage geben. (z.B. wird das SQL bei SaveAsText/LoadFromText abgeschnitten oder gelöscht.)

In der Praxis bin ich mit handgeschriebenem SQL niemals an diese Grenzen gekommen. Nur mit VBA-generiertem SQL, basierend auf User-Input, sind gelegentlich Probleme vorgekommen.

[TTB]

Hallo und herzlichen Dank für die Antworten.

@DF6GL: ich habe mit einem Abfrageentwurf begonnen und auch die Entwurfsansicht genutzt. Ich bin aber schnell an die Grenzen der Machbarkeit gekommen, da ich diese Abfrage mit sehr vielen Kriterien füttere, die über ein "Such"formular eingegeben werden. Doch irgendwann wurde die Abfrage immer langsamer. Die Ursache war, dass Access die SQL-Geschichte selbst umgeschrieben hat und bei "Oder"Verknüfungen der Kriterien teilweise den kompletten WHERE-Teil "verdoppelt hat, wobei sich diese Blöcke nur in den betreffenden Kriterien unterschieden. Somit stand quasi 8 oder 16 mal der nahezu identische Code im SQL Teil. Ich habe das dann händisch verkürzt und auch die Performance kam zurück.

Die Datenbank soll in einem Marktforschungsinstitut eingesetzt werden. Daher ist es wichtig, dass alle Kriterien die in der Datenbank gespeichert sind, auch gefiltert werden können.

Ich kann den Code leider hier nicht posten - aber solltest Du dennoch Interesse haben, kann ich Dir ein paar Auszüge schicken - vielleicht habe ich die Sache ja grundlegend falsch begonnen.

Aber im Prinzip sind es Textfelder, Kontrollkästchen und Kombinationsfelder, die den Inhalt der Abfrage bestimmen.

Es ist meine erste "große" Datenbank und ich habe versucht VBA soweit es geht zu meiden...aber ich verstehe immer mehr, warum es Sinn macht, keinen so großen Bogen drum zu machen.

lG und Danke
Chris

[DF6GL]

Hallo,

ich denke, dass die zu  große angemeckerte Anzahl der Zeichen daher rührt, dass für die Kriterien (Vergleichswerte) die Formular-Steuerelement-Bezüge (Formulare!MeinFormular!MeinSteuerelement, bzw. Forms!MeinFormular!MeinSteuerelement) verwendet werden. 

Wenn die Abfrage (SQL-String) mit VBA zusammengesetzt wird, reduziert sich die Zeichenanzahl der Kriterienwerte auf die Werte-Zeichenlänge  selber.

Unabhängig davon ist sicherlich eine Optimierung des Filter- (Such-) Vorgangs denkbar, wobei auch grundsätzlich  die Notwendigkeit der Normalisierung der DB nicht außer Acht gelassen werden darf.

"ich habe versucht VBA soweit es geht zu meiden"

ohne VBA ist eine "große" Datenbank eher nicht zu erreichen, wenn sich "groß" auf die Funktionalitäten der DB bezieht.

[ebs17]

Unter Access xxxx-Spezifikationen kann man sich die echten Begrenzungen erlesen.

Ansonsten ist der Abfrageentwurf ein Assistent, ein Hilfsmittel, mit dem einerseits einige einfachere Routineaufgaben schneller erledigt werden können und der andererseits Ahnumgslosen und -armen überhaupt zu funktionierenden SQL-Anweisungen verhelfen kann. Man darf da aber keine Wunderdinge erwarten. Gutes (z.B. im ersten Schritt gut lesbares) SQL kann anders aussehen als das von diesem Assistenten erzeugte.

Übersichtliche Maßnahmen:
- Reduzierung der Klammerinflation in den Kriterien
- Verwendung von Aliasen bei Tabellen- und Abfragenamen bzw. man unterlässt die Qualifizierung von Feldern ganz, wenn die Herkunft eindeutig ist, bspw. wenn nur eine Tabelle in nur einzelner Verwendung in der Abfrage vorkommt.

Wie schon angemerkt: Bei vielen Kriterien, die vermutlich nur selten alle gemeinsam mit angegebenen Werten genutzt werden und die da immer eine festinstallierte NULL-Prüfung mitbringen müssen, ist es dann effektiver, per VBA das Kriterium nur aus dem zusammenzustellen, was wirklich nachgefragt ist. Damit wird das Kriterium deutlich kürzer, und auch die Maschine wird beim Abarbeiten nicht mit Unnötigem beschäftigt.

[TTB]

Danke für die verständliche Erklärung. Ich mach das Ding jetzt erstmal fertig und werde dann umsatteln. Leuchtet auch mir ein und wenn die DaBa mal auf einem alten Rechner benutzt werden muss, ist das sicherlich ein deutlich besserer Weg.

[ebs17]

ich habe versucht VBA soweit es geht zu meiden...

Erst per VBA bekommt man Komfort in eine Access-Bedienoberfläche:
- Prüfen und Ausgabe von userfreundlichen Meldungen statt der accesseigenen Meldungen
- Vorschlag von Auswahlwerten entsprechend eigener Anfangseingaben statt fehlerträchtige Selbsteingabe
- programmierte Programmsteuerung und -führung statt dass sich ein User in den Menübändern verliert (und vielleicht zu spielen anfängt)
- Zugriff auf andere Dateien und Programme (Excel, Word, Outlook, TXT, CSV, HTML, Internet ...), Zugriff auf Betriebssystem und Hardware u.a.