Office: (Office 2016) Rückgabe von 蠥A in Abfrage Feld

Hallo Miteinander,

habe ein sehr seltsames Verhalten einer Abfrage die als Grundlage für das Einfügen von Werten in ein Word Dokument dient.

Normalerweise funktioniert die Abfrage und gibt den richtigen Wert zurück. Ab und an aber kommt "蠥A" als Wert anstatt des Kapitels.
Der Wert kommt aus einer Unterabfrage, die Abfrage ist gruppiert und der minumum Wert wird angezeigt.
Wird dann komprimiert geht es danach wieder. Kommt aber wieder.(Leider sehr schnell)
Eine andere Abfrage die sehr ähnlich ist macht dagegen keine Probleme. (Auch alles andere in dem sehr unfangreichen Programm verursacht diese Problem nicht)
Die WErte werden per ADO ausgelesen. Das Backend ist Access. Alles läuft auf O365.
Würde mich freuen wenn jemand ne Idee hätte.
Viele Grüße
treking

:)

 

Eigentlich doch aus einer Tabelle. Man würde sich da schon für Datentypen interessieren, ursprüngliche und erzeugte.
Hoffentlich sind da keine Memofelder im Umfeld. Die haben so ihre Eigenarten.

Sowie: Es ist regelmäßig informativer, SQL-Anweisungen als Code gezeigt zu bekommen statt Geschichten darüber zu hören, zumal von jenen, denen nicht ganz klar ist, was passiert - falls der Fehler von der Verarbeitung herrührt

 

Hallo Eberhard,
schön von Dir zu lesen.
Hatte die Hoffnung, dass jemand das Phänomen gleich kennt und eine Antwort darauf hat und habe deschalb mal darauf verzichtet das SQL Statement zu posten. Wie immer, die Hoffnung stirbt zuletzt.

Der Datentyp des Feldes Rating_Section (Das das Problem beherbergt) ist long Text, Allow Zero length = No
Nicht indiziert, Unicode compression =yes
Text Format= plain text

Es funktioniert immer mit einem lokalen Backend oder dem sog. Testbackend. Nur beim Produktiv Backend kommt es zu dem Fehler. Nach Komprimieren ist er dann verschwunden tritt aber recht zügig wieder auf.
Was ich noch nicht gemacht habe ist das komplette importieren des Produktiv BE in eine neue accdb. Die Größe des Pord BE ist mit ca. 235 MB noch im Rahmen. (Da scheue ich mich ein wenig davor, da ja dann die Verknüpfungen in der Übersicht neu sortiert werden müssen)
Das prod. BE habe ich auch überprüft und es ist vom Aufbau exakt die gleiche Tabelle als im Test und lokalen BE.

Anbei das SQL Statement.
Code:

Würde mich sehr freuen, wenn Dir was dazu einfällt. Falls ich (mal wieder) Deinen Ansprüchen mit der Auskunft nicht genüge, dann lass es mich auch wissen. *Smilie
Vielen Dank schon mal an Dich und alle die sich hier auch beteiligen.

Viele Grüße
trekking

 

long Text (langer Text) ... ist die neumodische Bezeichnung für Memo.
So etwas gruppiert oder aggregiert man besser nicht.
Wieviel Zeichen sind da real und vor allem im Problemfall enthalten?

Noch besser würde man nicht über JOIN's Datensatzinhalte vervielfältigen, um sie dann per Gruppierung + Aggregation wieder zusammenfassen zu müssen. Das würde der Performance und der Funktionalität dienen.
Solche langen Feldlisten im Gruppieren-Teil lassen mich regelmäßig erschauern, aber so sieht es aus, wenn man Zusammenklicken einer Anweisung in der Entwurfsansicht eigenem Design nach eigenen Überlegungen vorzieht.

Das Feld Rating_Section gibt es in Deiner SQL-Anweisung nicht, sprich an der Präzision der Aussagen kann man noch arbeiten.

 

Hallo Eberhard,

danke, wie immer für Deinen Rat.
Du hast recht, das Feld gibt es nicht und Du hast den Rechtschreibefehler gefunden. Es hätte Section_Description heißen müssen. Entschuldige bitte.

Habe nun das Feld in "text" geändert. Das Ergebnis ist das gleiche.
Wenn Du eine Idee hast, woran der Fehler liegt, dann gerne her damit. auch wie man die Abfrage vereinfachen könnte.
Die Vielen Group By kommen davon, dass mir Access es nicht gestattet diese wegzulassen. (In MySQL geht das durchaus, was oft hilft). Es würde mich schon freuen, wenn du hier noch nützliche Infos und Vorschläge hättest.

Viele Grüße
trekking

 

Du steckst die Spalten mit den Aggregierungen in ein Subselect, dann musst du nur die Felder aggregieren wo du es wirklich brauchst.

 

... ist relativ. Einfach für die DB-Maschine (Ausführung) und einfach für den Entwickler (Erstellung) und funktional (richtiges Ergebnis) können verschiedene Wege gehen.

Möglicher und recht oft sehr praktikabler Weg, wie markusxy schon anmerkt:

- Nicht zuerst alle (verfügbaren) Tabellen verknüpfen und danach rechnen. Ein JOIN hat die Wirkung zu filtern wie auch zu vervielfältigen. Vor allem treibt er schon allerhand Aufwand, was man oft nicht spürt, weil die verwendeten Schlüssel meist schon (zwangs)indiziert sind. Aber was man nicht sieht oder wahrnimmt, ist ja trotzdem da. Irgendwann in Summe spürt man es dann doch.

- Sondern erst rechnen, dann verknüpfen.

Einige gedankliche Bezüge kann man sich hieraus ableiten: Grundlagen - SQL ist leicht (11) - Reihenfolge der Abfrageabarbeitung

Für einen konkreten Vorschlag reicht mein Abstraktionsvermögen nicht aus. Da bräuchte ich als Hilfsmittel schon die Kenntnis des Datenmodells. Zusätzlich werden ja durch die Anweisung Daten verarbeitet. Da ist dann recht schnell die Kenntnis der konkreten Datenlage erforderlich, durchaus dann auch die Kenntnis der Tabellendefinitionen.

 

Hallo Eberhard, Hallo Markus

Danke für die Tips. Habe das nun mal komplett umgestellt und leider immer noch das Problem.
Anscheinend ist da noch was anderes im Argen. Die Abfrage selbst scheint nun immer die Richtigen Werte zu liefern (Habe keinen direkten Zugriff auf das Produktiv BE im Moment nur auf das Test System. In dem Läuft es aber ohne Probleme, deshalb die etwas schwammigere Aussage da diese vom User kommt)
Eventuell passiert es ja an der Stelle an der ich der Zelle der Word Tabelle den Wert zuweise. Der Code dafür ist:
Code:

Eventuell gibt es einen besseren Befehl.
Danke für eure Unterstützung.
Viele Grüße
trekking

 

Da würde ich einfach mal im Word Forum fragen.

Der Umbau des SQL führt hoffentlich zur effizienteren Verarbeitung der Abfrage.
Die Group by Orgien kommen in der Regel vom zu wenig Mitdenken.
Wenn ich da meine alten SQL Statements anschaue, wird mir schlecht. *grins

 

Danke Markus,

vor allem für das Statement "zu wenig Mitdenken"

In der Regel benutze ich MySQL als BE. Access ist hier die Ausnahme. Da ist das etwas anders und Du verfällst nicht in GroupBy Orgien.

Leider ist das Ganze hier noch eine m:n Beziehung, und der Kunde will eine spezielle Auswahl was die Sache nicht gerade vereinfacht. *frown.gif*
Es entsehen an der sTelle zwangsweie doppelte Einträge und diese müssen entsrpechend nicht angezegt werden und dann gibt es noch das Feld Prio bei dem die gleiche Recommendatation eine andere Prio hat. da soll eben auch nur die erste angezeigt werden.

Wie schon gesagt, das SQL Statement an sich funktioniert (das alte und das neue) Nur eben nicht im PRoduktivsystem. Warum auch immer.

Im Notfall werde ich den Holzhammer auspacken und die Daten lokal in eine Tabelle schreiben und dann sollte es erledigt sein.

Viele Grüße
trekking

 

Ich kenne das Problem, da ich beruflich auch zu 95% mit dem MSSQL Server arbeite.

Lokale Tabellen bringen da sicher nichts. Erstmal musst du das Problem finden, bevor du es lösen kannst.

 

Geteilter Schmerz ist halber Schmerz Markus *Smilie

Viele Grüße
trekking

 

> Anscheinend ist da noch was anderes im Argen.
> Die Abfrage selbst scheint nun immer die Richtigen Werte zu liefern

Das ist doch absolut spekulativ.

Dass man Memo-Felder nicht gruppieren kann, hast Du verstanden?
Memo-Felder werden zuvor in Text-Felder gewandelt, dabei kann,
bekannterweise, das von Dir beschriebene Problem auftreten.

Gruppierst Du das Memo-Feld immer noch?

 

@CatboyJones,
hast du das gelesen.

Außerdem wie kommst du zu deiner Meinung bezüglich des Problems?
Bei "Langer Text" oder Memo werden doch die ersten 255 Zeichen abgeschnitten und dann gruppiert - oder hast du da eine andere Info?
Wie soll das aber zu dem Problem führen?

Hat da denn jemals ein Zusammenhang bestanden?

 

> Habe keinen direkten Zugriff auf das Produktiv BE
Das habe ich gelesen.

Das Problem könnte daraus resultieren, dass nicht 255 Zeichen verwendet werden,
sondern, dass nur das erste Segment aus der Datei genommen wird.
(Das ist allerdings nur eine Spekulation.)