- Welcome to Access-o-Mania.
Hilfe zu Microsoft Access und verwandten Produkten
Neueste Beiträge
#1
Tabelle/Abfrage / Re: Abfrage um Ergebnisse in e...
Letzter Beitrag von dfens - Juli 11, 2025, 16:35:55Hallo Christian! Da gab es wohl ein kleines Missverständnis. Ich meinte, dass ich die Microsoft Seite nicht sehr hilfreich finde. Dort gibt es zar Beispiele - aber selten wird der Zusammenhang aufgezeigt (Struktur der Tabellen usw..)
Irgendwie hab ich Troubles, mich dort zurechtzufinden. Daher besuche ich bei Fragen DIESES Forum hier. Denn da wurde mir bisher immer perfekt geholfen - auch wenns nicht immer um Access geht ;-) Also nochmals DANKE DANKE DANKE ! Hat mir echt sehr geholfen der Tip! lg
Irgendwie hab ich Troubles, mich dort zurechtzufinden. Daher besuche ich bei Fragen DIESES Forum hier. Denn da wurde mir bisher immer perfekt geholfen - auch wenns nicht immer um Access geht ;-) Also nochmals DANKE DANKE DANKE ! Hat mir echt sehr geholfen der Tip! lg
#2
Tabelle/Abfrage / Re: Abfrage um Ergebnisse in e...
Letzter Beitrag von Bitsqueezer - Juli 11, 2025, 15:50:53Hallo,
ja, auf der Serverseite ist es auch besser aufgehoben.
Und in Access würde es auch funktionieren, weil Access SQL ja dem Backend-SQL "vorgeschaltet" ist, aber definitiv besser, alle Berechnungen auf der Serverseite zu machen und nur das Ergebnis an Access weiterzureichen.
"Nie Hilfe für Access" - dann bist Du ja u.a. hier genau richtig.
Gruß
Christian
ja, auf der Serverseite ist es auch besser aufgehoben.
Und in Access würde es auch funktionieren, weil Access SQL ja dem Backend-SQL "vorgeschaltet" ist, aber definitiv besser, alle Berechnungen auf der Serverseite zu machen und nur das Ergebnis an Access weiterzureichen.
"Nie Hilfe für Access" - dann bist Du ja u.a. hier genau richtig.
Gruß
Christian
#3
Tabelle/Abfrage / Re: Abfrage um Ergebnisse in e...
Letzter Beitrag von dfens - Juli 11, 2025, 15:16:18Nachtrag: Gefunden und funktioniert. In Oracle nennt sich's LISTAGG und es bringt mir genau das was ich brauche. Danke nochmal für den Hinweis !
#4
Tabelle/Abfrage / Re: Abfrage um Ergebnisse in e...
Letzter Beitrag von dfens - Juli 11, 2025, 15:11:07Hallo und Danke erstmmal für die Hinweise und Tipps!
Der VBA Code für Access nützt mir leider nichts. Die Abfrage muss ich in SQL Code machen, da es sich um eine Oracle Datenbank handelt. Die Microsoft Seite ist für mich leider nicht verständlich. Ich kann grad mal die Basics in SQL und dort hab ich noch nie Hilfe gefunden. Aber gut zu wissen, dass ich nach STRING_AGG suchen muss. Das wird mir sicher helfen. Danke Euch !
Der VBA Code für Access nützt mir leider nichts. Die Abfrage muss ich in SQL Code machen, da es sich um eine Oracle Datenbank handelt. Die Microsoft Seite ist für mich leider nicht verständlich. Ich kann grad mal die Basics in SQL und dort hab ich noch nie Hilfe gefunden. Aber gut zu wissen, dass ich nach STRING_AGG suchen muss. Das wird mir sicher helfen. Danke Euch !
#5
Tabelle/Abfrage / Re: Abfrage um Ergebnisse in e...
Letzter Beitrag von Knobbi38 - Juli 11, 2025, 10:36:40Schau mal diesen Thread an, vielleicht ist da etwas für dich dabei:
https://www.access-o-mania.de/forum/index.php?topic=28002.0
https://www.access-o-mania.de/forum/index.php?topic=28002.0
#6
Tabelle/Abfrage / Re: Abfrage um Ergebnisse in e...
Letzter Beitrag von Bitsqueezer - Juli 10, 2025, 23:13:59Hallo,
gefühlte 1,5 Millionen mal gefragt...
"String Aggregat" ist das Zauberwort, hier ist eins von vielen Erklärungsvideos, wie man das macht (reiner Zufall, es geht auch um Autos und Farben...):
https://www.youtube.com/watch?app=desktop&v=ItCS-g1K2zk
Man braucht in Access dazu eine VBA-Funktion.
In SQL Server gibt es dazu eine Funktion:
https://learn.microsoft.com/en-us/sql/t-sql/functions/string-agg-transact-sql?view=sql-server-ver17
Gruß
Christian
gefühlte 1,5 Millionen mal gefragt...
"String Aggregat" ist das Zauberwort, hier ist eins von vielen Erklärungsvideos, wie man das macht (reiner Zufall, es geht auch um Autos und Farben...):
https://www.youtube.com/watch?app=desktop&v=ItCS-g1K2zk
Man braucht in Access dazu eine VBA-Funktion.
In SQL Server gibt es dazu eine Funktion:
https://learn.microsoft.com/en-us/sql/t-sql/functions/string-agg-transact-sql?view=sql-server-ver17
Gruß
Christian
#7
Tabelle/Abfrage / Re: wegen TempVars: 2 Paramete...
Letzter Beitrag von Bitsqueezer - Juli 10, 2025, 23:05:14Hallo,
wenn Deine Anwendung einen entsprechenden Umfang hat, könntest Du auch über TDD nachdenken (Test Driven Development). Dabei werden Funktionen erstellt, die Tests ausführen und zurückliefern, ob das Ergebnis OK ist oder nicht (mal ganz simpel gesagt). Und dann kann man alle Tests nacheinander ausführen in einer Schleife und sieht sofort, ob alles OK ist oder irgendwo Fehler ausgegeben werden. Vorteil: Es entgeht einem eher selten, wenn es ein Problem gibt, Nachteil natürlich, Overhead durch die notwendige Erstellung von Tests, die selbst ja auch fehlerfrei sein müssen.
Aber ehrlich: Nur die Lesefunktionen ausprobieren und dann glauben, daß alles "schon gut" ist, ist schon sehr blauäugig. Minimal erstellt man sich ein paralleles Testsystem und probiert dort insbesondere die datenverändernden Funktionen aus. Die Testdaten am besten regelmäßig aus den Echtdaten in die Testdatenbank kopieren (inkl. auch aller Datenfehler!), weil Gaga-Testdaten das Ergebnis verfälschen können.
Funktionen in Abfragen: Ist eigentlich ganz einfach: Wo immer eine Funktion bei jedem Aufruf den gleichen Wert zurückgibt, wird der Optimizer die Funktion genau einmal ausführen und dann das Ergebnis in der Abfrage wie eine Konstante wiederverwenden, egal wie oft sie verwendet wird. Solche Aufrufe gehen sehr schnell und kosten keine Performance. I.d.R. erkennt der Optimizer das daran, daß die Funktion als Parameter keine Felder aus der Tabelle entgegennimmt. Da sich der Feldwert je Zeile i.d.R. ändert, muß die Funktion dann mit jeder Zeile neu aufgerufen werden, was dann sehr langsam werden kann. Der Optimizer prüft nicht den Inhalt der Funktion (wäre auch zuviel verlangt).
Das ist jetzt eine stark vereinfachte Darstellung, aber so kann man sich das ganz gut merken.
Wenn Du TempVars in der Form "PLZ: [TempVars]![tVarPLZ]" verwendest, dann ist es auch nur eine Konstante. TempVars sind ja keine Funktionen und deren Inhalt kann sich während der Abfrage NIE ändern, daher sind sie genauso schnell wie Funktionen, die nur einen konstanten Wert zurückliefern.
Wenn Du die PLZ z.B. in einem WHERE brauchst, dann wird der Wert nur einmal angerufen, dann brauchst Du ja auch kein Feld der aktuellen Tabelle als Parameter für so eine Funktion und entsprechend wird es keinen großen Unterschied zwischen dem Abruf per TempVars und dem Aufruf einer konstanten Funktion geben.
Wenn es also um z.B. einstellbare Parameter aus einem Formular geht, die in einer Abfrage zur Filterung verwendet werden sollen, dann mache ich das meistens mit einer Hilfsfunktion mit Parameter "Formularname" und "Controlname", die Variant zurückliefert.
Die Funktion kann dann testen, ob ein Formular geladen ist und dann dessen Wert auslesen anhand des Controlnamens und diesen als Rückgabewert an die Abfrage geben. Ist das Formular nicht geladen, kommt bei der Abfrage nichts raus, aber auch keine Fehlermeldung. Funktioniert sehr effizient und da kein Feldname als Parameter verwendet wird, ist es für den Optimizer eine Funktion mit konstanter Rückgabe und wird nur einmal aufgerufen.
Hier holt sich die Abfrage also die Parameter selbst.
Im umgekehrten Fall erstellt man eine "PARAMETERS"-Klausel (kann im Designer auch per Parameter-Editor erstellt werden) und definiert dort alle Parameter und Datentypen. Die Namen der Parameter verwendet man dann in der Abfrage, also etwa "WHERE tbl.PLZ = parPLZ", wenn der Name "parPLZ" war.
Startest Du die Abfrage, wirst Du nach den Parametern gefragt und kannst sie manuell eingeben.
Verwendest Du sie in der Anwendung, erstellst Du stattdessen eine QueryDef-Variable und kannst dann deren "Parameters"-Collection anhand der Namen mit den Werten füllen, was auch SQL Injection sicher ist.
Diese kannst Du dann ausführen und das Ergebnis im Formular anzeigen.
QueryDefs hatte Dir Ulrich oben ja schon vorgeschlagen.
Den TempVars-Quatsch (sorry) würde ich komplett aus der Anwendung entfernen.
Für VBA haben TempVars noch Vorteile, weil sie auch nach einem nicht abgefangenen Fehler ihren jeweiligen Wert beibehalten bis zum Ende der Anwendung (also Access). Das kann man für die sichere Speicherung von anwendungsrelevanten Werten wie etwa den Ribbon-Handler verwenden.
Ansonsten gibt es für TempVars in einer ernsthaften Anwendung eher keinen Nutzen. Sie sind nur erfunden worden, um Makros die Möglichkeit zu geben, Variablen verwenden zu können.
Wenn Du also die Version vor der Einführung der TempVars noch hast, schmeiß die aktuelle Version weg und hake es unter "Lessons Learned" ab. Wenn Du schon die Funktionalität im gleichen Zuge erweitert hast, dann solltest Du ein Compare-Tool verwenden, um die betreffenden Stellen herauszufinden und diese zu übernehmen (auf meiner Downloadseite habe ich so ein Tool, das zwei Datenbanken vergleicht und die Änderungen im Diff-Tool "Meld" anzeigt, unter "CCAccessComparisonV2").
Im gleichen Zug solltest Du, wie beschrieben, auch die Verwendung von Funktionen, wie beschrieben, einschränken bzw. entfernen.
Du kannst ebenso eine Tabelle verwenden, deren Felder Parameter darstellen, diese per UPDATE oder INSERT beschreiben und dann die Feldwerte als Parameter über ein CROSS JOIN abrufen.
Aber bitte keine temporäre Tabelle. Die sollte schon fest definiert sein.
Oder Du erstellst eine Abfrage per Dynamic SQL und schreibst konstante Werte einfach in den SQL-String. Usw.
Gruß
Christian
wenn Deine Anwendung einen entsprechenden Umfang hat, könntest Du auch über TDD nachdenken (Test Driven Development). Dabei werden Funktionen erstellt, die Tests ausführen und zurückliefern, ob das Ergebnis OK ist oder nicht (mal ganz simpel gesagt). Und dann kann man alle Tests nacheinander ausführen in einer Schleife und sieht sofort, ob alles OK ist oder irgendwo Fehler ausgegeben werden. Vorteil: Es entgeht einem eher selten, wenn es ein Problem gibt, Nachteil natürlich, Overhead durch die notwendige Erstellung von Tests, die selbst ja auch fehlerfrei sein müssen.
Aber ehrlich: Nur die Lesefunktionen ausprobieren und dann glauben, daß alles "schon gut" ist, ist schon sehr blauäugig. Minimal erstellt man sich ein paralleles Testsystem und probiert dort insbesondere die datenverändernden Funktionen aus. Die Testdaten am besten regelmäßig aus den Echtdaten in die Testdatenbank kopieren (inkl. auch aller Datenfehler!), weil Gaga-Testdaten das Ergebnis verfälschen können.
Funktionen in Abfragen: Ist eigentlich ganz einfach: Wo immer eine Funktion bei jedem Aufruf den gleichen Wert zurückgibt, wird der Optimizer die Funktion genau einmal ausführen und dann das Ergebnis in der Abfrage wie eine Konstante wiederverwenden, egal wie oft sie verwendet wird. Solche Aufrufe gehen sehr schnell und kosten keine Performance. I.d.R. erkennt der Optimizer das daran, daß die Funktion als Parameter keine Felder aus der Tabelle entgegennimmt. Da sich der Feldwert je Zeile i.d.R. ändert, muß die Funktion dann mit jeder Zeile neu aufgerufen werden, was dann sehr langsam werden kann. Der Optimizer prüft nicht den Inhalt der Funktion (wäre auch zuviel verlangt).
Das ist jetzt eine stark vereinfachte Darstellung, aber so kann man sich das ganz gut merken.
Wenn Du TempVars in der Form "PLZ: [TempVars]![tVarPLZ]" verwendest, dann ist es auch nur eine Konstante. TempVars sind ja keine Funktionen und deren Inhalt kann sich während der Abfrage NIE ändern, daher sind sie genauso schnell wie Funktionen, die nur einen konstanten Wert zurückliefern.
Wenn Du die PLZ z.B. in einem WHERE brauchst, dann wird der Wert nur einmal angerufen, dann brauchst Du ja auch kein Feld der aktuellen Tabelle als Parameter für so eine Funktion und entsprechend wird es keinen großen Unterschied zwischen dem Abruf per TempVars und dem Aufruf einer konstanten Funktion geben.
Wenn es also um z.B. einstellbare Parameter aus einem Formular geht, die in einer Abfrage zur Filterung verwendet werden sollen, dann mache ich das meistens mit einer Hilfsfunktion mit Parameter "Formularname" und "Controlname", die Variant zurückliefert.
Die Funktion kann dann testen, ob ein Formular geladen ist und dann dessen Wert auslesen anhand des Controlnamens und diesen als Rückgabewert an die Abfrage geben. Ist das Formular nicht geladen, kommt bei der Abfrage nichts raus, aber auch keine Fehlermeldung. Funktioniert sehr effizient und da kein Feldname als Parameter verwendet wird, ist es für den Optimizer eine Funktion mit konstanter Rückgabe und wird nur einmal aufgerufen.
Hier holt sich die Abfrage also die Parameter selbst.
Im umgekehrten Fall erstellt man eine "PARAMETERS"-Klausel (kann im Designer auch per Parameter-Editor erstellt werden) und definiert dort alle Parameter und Datentypen. Die Namen der Parameter verwendet man dann in der Abfrage, also etwa "WHERE tbl.PLZ = parPLZ", wenn der Name "parPLZ" war.
Startest Du die Abfrage, wirst Du nach den Parametern gefragt und kannst sie manuell eingeben.
Verwendest Du sie in der Anwendung, erstellst Du stattdessen eine QueryDef-Variable und kannst dann deren "Parameters"-Collection anhand der Namen mit den Werten füllen, was auch SQL Injection sicher ist.
Diese kannst Du dann ausführen und das Ergebnis im Formular anzeigen.
QueryDefs hatte Dir Ulrich oben ja schon vorgeschlagen.
Den TempVars-Quatsch (sorry) würde ich komplett aus der Anwendung entfernen.
Für VBA haben TempVars noch Vorteile, weil sie auch nach einem nicht abgefangenen Fehler ihren jeweiligen Wert beibehalten bis zum Ende der Anwendung (also Access). Das kann man für die sichere Speicherung von anwendungsrelevanten Werten wie etwa den Ribbon-Handler verwenden.
Ansonsten gibt es für TempVars in einer ernsthaften Anwendung eher keinen Nutzen. Sie sind nur erfunden worden, um Makros die Möglichkeit zu geben, Variablen verwenden zu können.
Wenn Du also die Version vor der Einführung der TempVars noch hast, schmeiß die aktuelle Version weg und hake es unter "Lessons Learned" ab. Wenn Du schon die Funktionalität im gleichen Zuge erweitert hast, dann solltest Du ein Compare-Tool verwenden, um die betreffenden Stellen herauszufinden und diese zu übernehmen (auf meiner Downloadseite habe ich so ein Tool, das zwei Datenbanken vergleicht und die Änderungen im Diff-Tool "Meld" anzeigt, unter "CCAccessComparisonV2").
Im gleichen Zug solltest Du, wie beschrieben, auch die Verwendung von Funktionen, wie beschrieben, einschränken bzw. entfernen.
Du kannst ebenso eine Tabelle verwenden, deren Felder Parameter darstellen, diese per UPDATE oder INSERT beschreiben und dann die Feldwerte als Parameter über ein CROSS JOIN abrufen.
Aber bitte keine temporäre Tabelle. Die sollte schon fest definiert sein.
Oder Du erstellst eine Abfrage per Dynamic SQL und schreibst konstante Werte einfach in den SQL-String. Usw.
Gruß
Christian
#8
Tabelle/Abfrage / Re: wegen TempVars: 2 Paramete...
Letzter Beitrag von markusxy - Juli 10, 2025, 19:16:39Zitat von: micmen am Juli 10, 2025, 15:12:09hatte Access bei der Anwendung irgendwann Ressourcenprobleme gemeldet
Das Thema gabs ja schon öfter in diversen Foren.
Access SQL ist ja sehr eingeschränkt und öfter werden denn gerne Domänen-Funktionen eingesetzt um diese Einschränkungen zu umgehen. Da kann dann schon eine Umfangreiche Abfrage genügen, damit so ein Ressourcen-Problem aufkommt. TempVars kann man in VBA-Abfragen genau wie Variablen verwenden, also eine ungünstige Lösung.
Da würde es wen brauchen, der weiß was er tut und alle Möglichkeiten innerhalb von Access kennt.
Warum nicht einen externen Berater/Firma einbinden, da es bei euch scheinbar niemanden gibt, der ein Gefühl für die Materie hat.
#9
Tabelle/Abfrage / Re: wegen TempVars: 2 Paramete...
Letzter Beitrag von micmen - Juli 10, 2025, 15:12:09Hi, eine Quelle habe ich jetzt nicht - meine Recherche ist mehr als ein Jahr her, da müsste ich suchen.
Und wie bereits geschrieben, wurde die Anwendung nach Abschluß dieses Umbaus lediglich darauf getestet, ob ganz allgemein die Abfragen noch/wieder funktionieren. Das geschah damals anscheinend(?) mit Ausnahme von Funktionalitäten, die irgendwelche Änderungen bewirken. Ich bin davon zwar noch immer nicht 100% überzeugt
, meine Einschätzung war, dass das Problem erst deutlich nach diesem Entfernen von Funktionen aus Abfragen plötzlich aufgetreten ist, aber so rückwirkend will ich das nicht beschwören. Auf die Idee, dass nach dem Umbau Abfragen in manchen Fällen funktionieren und in anderen nicht, ist tatsächlich keiner gekommen. So einen Fall gab es noch nie... Kann man jetzt im Nachhinein als Leichtsinn bewerten, aber wie gesagt, etwas dieser Art war vorher noch nie irgendwem untergekommen, dass Access Abfragen beim Aufruf auf die eine Art akzeptiert und bei Aufruf auf andere Art nicht.
Wie geschrieben, hatte Access bei der Anwendung irgendwann Ressourcenprobleme gemeldet. Daraufhin war sie tiefgreifend umgebaut worden, das mit dem Rauswurf von Funktionen aus Abfragen war nur ein Teil.
Diese "Komplett-Tests", bei denen dann "hinter den Kulissen" auch sämtliche Aktionsabfragen ausgeführt werden, wurden erst vor kurzem gemacht, als die komplette Anwendung getestet werden sollte. (bei denen kann man ja nicht einfach schauen, ob ein augenscheinlicher Fehler auftritt, oder nicht, sondern da muss man für jede einzelne zu testende Anwendungs-Funktion einen vorher-nachher-Vergleich fahren, um zu überprüfen, ob alle Änderungen exakt so vorgenommen wurden, wie vorgesenen - und vor dem Umbau hatte das ja alles funktioniert)
Es ist sehr gut möglich, dass in der Anwendung Auswahlabfragen, die TempVars enthalten, nicht per VBA aufgerufen werden.
Ich meine, es wäre darum gegangen, dass Abfragen, wenn sie Funktionen beinhalten, teils für jeden Datensatz neu die Funktion aufrufen, und darum in einem langsameren Modus laufen, als wenn sie rein SQL-Code enthalten. TempVars dagegen würden wie Felder in Datenquellen behandelt, was bei der Syntax ja auch plausibel erschien (dort werden die ja verwendet in der Art "PLZ: [TempVars]![tVarPLZ]", als wäre TempVars der Name einer Tabelle und tVarPLZ der Name eines Feldes darin).
danke
Und wie bereits geschrieben, wurde die Anwendung nach Abschluß dieses Umbaus lediglich darauf getestet, ob ganz allgemein die Abfragen noch/wieder funktionieren. Das geschah damals anscheinend(?) mit Ausnahme von Funktionalitäten, die irgendwelche Änderungen bewirken. Ich bin davon zwar noch immer nicht 100% überzeugt
, meine Einschätzung war, dass das Problem erst deutlich nach diesem Entfernen von Funktionen aus Abfragen plötzlich aufgetreten ist, aber so rückwirkend will ich das nicht beschwören. Auf die Idee, dass nach dem Umbau Abfragen in manchen Fällen funktionieren und in anderen nicht, ist tatsächlich keiner gekommen. So einen Fall gab es noch nie... Kann man jetzt im Nachhinein als Leichtsinn bewerten, aber wie gesagt, etwas dieser Art war vorher noch nie irgendwem untergekommen, dass Access Abfragen beim Aufruf auf die eine Art akzeptiert und bei Aufruf auf andere Art nicht.Wie geschrieben, hatte Access bei der Anwendung irgendwann Ressourcenprobleme gemeldet. Daraufhin war sie tiefgreifend umgebaut worden, das mit dem Rauswurf von Funktionen aus Abfragen war nur ein Teil.
Diese "Komplett-Tests", bei denen dann "hinter den Kulissen" auch sämtliche Aktionsabfragen ausgeführt werden, wurden erst vor kurzem gemacht, als die komplette Anwendung getestet werden sollte. (bei denen kann man ja nicht einfach schauen, ob ein augenscheinlicher Fehler auftritt, oder nicht, sondern da muss man für jede einzelne zu testende Anwendungs-Funktion einen vorher-nachher-Vergleich fahren, um zu überprüfen, ob alle Änderungen exakt so vorgenommen wurden, wie vorgesenen - und vor dem Umbau hatte das ja alles funktioniert)
Zitat von: PhilS am Juli 08, 2025, 18:55:02TempVars wurden nach meinem Kenntnisstand vor allem in Access eingebaut, um (...) Eine speziellen Variablentyp zu haben, der direkt in Abfragen verwendet werden kann.ja, eben - so war die Info
Zitat von: PhilS am Juli 08, 2025, 18:55:02Leider funktionieren TempVars in Abfrage nur, wenn die Abfragen im Kontext des Access-UI mit Makro-Aktionen (DoCmd....) ausgeführt werden, aber nicht im unmittelbaren VBA-Kontext. - Das ist die Misere, die dir hier zu schaffen macht.ah... Ist das gesichert? Weil das erklärt ja alles
Es ist sehr gut möglich, dass in der Anwendung Auswahlabfragen, die TempVars enthalten, nicht per VBA aufgerufen werden.
Zitat von: PhilS am Juli 08, 2025, 18:55:02Ich erinnere mich jetzt nicht mehr an die Einzelheiten, der anschließende Umbau hatte Monate gedauert. Es musste ermittelt werden, wie viele TempVars benötigt werden, um sämtliche Funktionen zu ersetzen, die in Abfragen verwendet werden. Dann mussten die deklariert, ein Teil davon beim Start der Anwendung besetzt, und jede bei jeder Änderung sofort aktualisiert werden, und einige davon beim Schließen der Anwendung in Tabellen geschrieben werden. Und dann, klar, alle betroffenen Abfragen umbauen.Zitat von: micmen am Juli 08, 2025, 17:31:45Von umfangreicher Verwendung von Funktionen in Abfragen wird anscheinand dringend abgeraten, weil Abfragen dann nur noch auf eine langsamere Art ausgeführt werden. Und, wie ebenfalls geschrieben, Access meldete ab einem bestimmten Stand der Anwendung Ressourcenprobleme.Tja, was genau ist eine "umfangreiche Verwendung"?
Ich rate vor allem von einer *falschen* Verwendung von Funktionen in Abfragen ab. In meinem Text Abfrage-Performance-Tuning - Universelle Grundregeln gibt es mehrere Absätze, die sich mit dem Einsatz von Funktionen beschäftigen und das erläutern.
Ich meine, es wäre darum gegangen, dass Abfragen, wenn sie Funktionen beinhalten, teils für jeden Datensatz neu die Funktion aufrufen, und darum in einem langsameren Modus laufen, als wenn sie rein SQL-Code enthalten. TempVars dagegen würden wie Felder in Datenquellen behandelt, was bei der Syntax ja auch plausibel erschien (dort werden die ja verwendet in der Art "PLZ: [TempVars]![tVarPLZ]", als wäre TempVars der Name einer Tabelle und tVarPLZ der Name eines Feldes darin).
danke
#10
Tabelle/Abfrage / Abfrage um Ergebnisse in einem...
Letzter Beitrag von dfens - Juli 10, 2025, 13:27:40Wieder mal ein Problem - (vermutlich klein für Euch aber riesig für mich)
Annahme: DB mit 3 tabellen (AutoMarke Type und Farbe)
z.b. von BMW gibt es 2 Modelle: ein Modell in 2 Farben und ein anderes in 3 Farben
Ich krieg natürlich eine normale Abfrage hin. Spalte 1 Marke, Spalte 2 Type, Spalte 3 Farben. Alle Ergebnisse in einer eigenen Zeile.
Aber wie schaffe ich es, die Abfrage so zu gestalten, dass es nur eine einzige Zeile gibt, in der in einer Spalte nur die Marke steht, und in der zweiten Spalte alle verfügbaren Farben (durch Kommas getrennt) angeführt werden. Also aus den Datensätzen kombiniert in einer "Zelle" zusammengefasst. (Sozusagen "entnormalisiert";-) Geht das überhaupt ?Sie dürfen in diesem Board keine Dateianhänge sehen.
Danke schon mal vorab !!
Annahme: DB mit 3 tabellen (AutoMarke Type und Farbe)
z.b. von BMW gibt es 2 Modelle: ein Modell in 2 Farben und ein anderes in 3 Farben
Ich krieg natürlich eine normale Abfrage hin. Spalte 1 Marke, Spalte 2 Type, Spalte 3 Farben. Alle Ergebnisse in einer eigenen Zeile.
Aber wie schaffe ich es, die Abfrage so zu gestalten, dass es nur eine einzige Zeile gibt, in der in einer Spalte nur die Marke steht, und in der zweiten Spalte alle verfügbaren Farben (durch Kommas getrennt) angeführt werden. Also aus den Datensätzen kombiniert in einer "Zelle" zusammengefasst. (Sozusagen "entnormalisiert";-) Geht das überhaupt ?Sie dürfen in diesem Board keine Dateianhänge sehen.
Danke schon mal vorab !!