Access-o-Mania

Hi,
ich weiß nicht, ob das jetzt eher hier in Tabelle/Abfrage gehört, oder in Access Programmierung.

Es geht um den Unterschied, ein Abfrage einerseits "zu Fuß" zu öffnen bzw. über DoCmd.OpenQuery "AbfrageX",
oder andererseits sie ausführen zu lassen über Db-Objekt.QueryDefs("AbfrageX").Execute bzw. Db-Objekt.Execute und direkt den SQL-Code.

Das direkte Öffnen der Abfragen (1. Variante) funktioniert nach wie vor, die 2. Variante funktioniert nicht mehr, sondern verursacht den Fehler 3061 mit einem Text wie

Zitat2 Parameter wurden erwartet, aber es wurden zu wenig Parameter übergeben.

Weil ein Ausführen von Abfrage-Objekten bei Fehlern den Usern unbrauchbare Meldungen bringt und man nicht an die Fehler-Informationen kommt, um auf einen Fehler passend zu reagieren, wurde in einer Access-Anwendung alles nach der 2. Variante umgesetzt, so dass man mit dbFailOnError oder (wenn man ein QueryDef-Objekt benutzt) mit RecordsAffected arbeiten kann.

Hat jahrelang funktioniert.

Die Anwendung hat viele Aktionsabfragen mit Filtern oder mit Werten, die "von außen" kommen, darum steckten viele Funktionen darin. Es gab dann mal irgendwelche Ressourcenprobleme von Access und im Netz habe ich die Info gefunden, dass Abfragen deutlich langsamer und ressourcenhungriger laufen, wenn sie Funktionsaufrufe enthalten, und u.a. dafür wären die TempVars erfunden worden, weil auf die könnten Abfragen wie auf Felder zugreifen.
Also wurde mit viel Arbeitsaufwand die gesamte Anwendung umgestellt und benutzt in Abfragen nur noch TempVars.
Auf die Idee, die Umstellung könnte bei Aktionsabfragen Probleme bringen, ist niemand gekommen, und klar testet man lieber mit Auswahlabfragen, die keine Änderungen durchführen... Jetzt sind die Ressourcenprobleme weg, aber die SQL-Anweisungen lassen sich nicht mehr ausführen...

Bei Abfragen, die keine TempVars enthalten, funktioniert es noch, also das scheint der Zusammenhang zu sein.

das hier funktioniert:

ZitatINSERT INTO Benutzer (LaufNr, BenName)
SELECT 2 AS Test1, "Testmeier" AS Test2;

das hier bringt den Fehler 3061 wie oben beschrieben:

ZitatINSERT INTO Benutzer (LaufNr, BenName,)
SELECT [TempVars]![tVarZahl] AS Test1, "Testmeier" AS Test2;

Hat dazu jemand eine Idee?

danke!

Hallo,
ganz generell, Query-defs sind schneller, und man kann mit Parametern arbeiten.
Gruß Andi

Zitat von: Hondo am Juli 07, 2025, 17:48:12Query-defs sind schneller

danke - also meinst Du QDF-Objekt.Execute ist schneller als Db-Objekt.QueryDefs("AbfrageX").Execute und schneller als Db-Objekt.Execute ("SQL-Anweisungen")?

Oder meinst Du das alles drei ist schneller, als ein Abfrage-Objekt ausführen zu lassen (händisch oder per DoCmd.OpenQuery "AbfrageX")?

Hauptthema ist für mich aktuell dieser Fehler 3061...

Zitat von: micmen am Juli 07, 2025, 17:39:07Auf die Idee, die Umstellung könnte bei Aktionsabfragen Probleme bringen, ist niemand gekommen, und klar testet man lieber mit Auswahlabfragen, die keine Änderungen durchführen...

Die Probleme bestehen nicht bei Aktionsabfragen, sondern bei allen Abfragen die aus einem VBA-Context ausgeführt werden; auch reine Auswahlabfragen. - D.h. die leichtsinnigen Tester haben nur mittels Mausklickerrei in der Access Oberfläche getestet (da funktionieren die Aktionsabfragen auch), aber nicht im Kontext von VBA-Code.

Die einfachste Lösung wäre hier wahrscheinlich ein Rollback der Änderungen.

Alternativ könntest du eine VBA Funktion schreiben, die den Wert einer TempVar abruft und zurückgibt. Dann ersetzt du per VBA Code in allen Abfragen die unmittelbaren TempVars-Referenzen durch einen Aufruf dieser Funktion. 

Hallo,

was du machen kannst ist, in der Abfrage die Tempvars zu löschen und durch Parameter zu ersetzen. Diese kann dann per VBA aufgerufen werden:

Beispiel für eine Append-Query:
INSERT INTO tblData ( Vorname, Nachname )
SELECT pVName, pNName;

' gebräuchlicher für das Anfügen eines Datensatzes:
INSERT INTO tblData ( Vorname, Nachname )
VALUES (pVName, pNName);

Diese kann dann ganz einfach mit:
  DoCmd.SetParameter "pVName", "'MyVorname'"
  DoCmd.SetParameter "pNName", "'MyNachname'"
  DoCmd.OpenQuery "qryAppend"

aufgerufen werden.

Die Verwendung des Querydef-Objekts anstelle des DoCmd-Objekts wäre natürlich besser:
  Dim qdf As QueryDef
 
  Set qdf = DBEngine(0)(0).QueryDefs("qryAppend")
  qdf!pVName = "MyVorname"
  qdf!pNName = "MyNachname"
  qdf.Execute dbFailOnError
  Set qdf = Nothing
Dabei kann der String auch durch eine Variable ersetzt werden.

Was jetzt tatsächlich in deiner Umgebung performanter ist, müsstest du dann selber durch eigene Performance-Messungen eruieren. 

Knobbi38

Zitat von: PhilS am Juli 07, 2025, 18:57:51Die Probleme bestehen nicht bei Aktionsabfragen, sondern bei allen Abfragen die aus einem VBA-Context ausgeführt werden; auch reine Auswahlabfragen.

Müsste ich testen, aber die ganze Anwendung hat ja auch nach der Umstellung von Funktionen auf TempVars noch einwandfrei funktioniert.
Die Probleme sind erst aufgefallen, als auch Funktionalitäten getestet wurden, die Änderungen an den Daten durchführen.
komisch

Zitat von: PhilS am Juli 07, 2025, 18:57:51D.h. die leichtsinnigen Tester haben nur mittels Mausklickerrei in der Access Oberfläche getestet (da funktionieren die Aktionsabfragen auch), aber nicht im Kontext von VBA-Code.

Nein, da wurde die ganzen Monate in der Oberfläche der Anwendung getestet und die ruft Abfragen teils über Berichte, Formulare, Kombinationsfelder, etc. auf und sehr viel auch über VBA.
Und "leichtsinnig", so ein Phänomen gab es noch nicht, daß bei einer Umstellung manche Abfragen noch laufen und andere nicht.

Zitat von: PhilS am Juli 07, 2025, 18:57:51Die einfachste Lösung wäre hier wahrscheinlich ein Rollback der Änderungen.

Alternativ könntest du eine VBA Funktion schreiben, die den Wert einer TempVar abruft und zurückgibt. Dann ersetzt du per VBA Code in allen Abfragen die unmittelbaren TempVars-Referenzen durch einen Aufruf dieser Funktion.

also sorry, das alles verstehe ich ja überhaupt nicht...  ;)
Erstens hatte ich die Probleme beschrieben, wegen derer Ratschläge aus dem Netz befolgt und die Abfragen von Funktionsaufrufen auf TempVars umgestellt wurden.
Und zweitens sind die TempVars, wie gleich eingangs beschrieben, ja nur aus dem Grund geschaffen worden, Funktionen überflüssig zu machen. Jetzt Funktionen zu schaffen, die TempVars auslesen, würde ja gar keinen Sinn ergeben, da könnte ich alles gleich wieder so umsetzen, wie es vorher war.

Aber, wie im ersten Post geschrieben:
Von 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.

danke

Zitat von: micmen am Juli 08, 2025, 17:31:45[...] die ganze Anwendung hat ja auch nach der Umstellung von Funktionen auf TempVars noch einwandfrei funktioniert. [...]
[...] da wurde die ganzen Monate in der Oberfläche der Anwendung getestet und die ruft Abfragen teils über Berichte, Formulare, Kombinationsfelder, etc. auf und sehr viel auch über VBA.

Wie genau und mit welcher mentalen Einstellung getestet wurde, kann ich natürlich nur vermuten.
Deine Darstellung, dass die ganze Anwendung getestet wurde und funktioniert hat, ist vor dem Hintergrund der hier beschriebenen Probleme nicht so ganz überzeugend.

Zitat von: micmen am Juli 08, 2025, 17:31:45Und zweitens sind die TempVars, wie gleich eingangs beschrieben, ja nur aus dem Grund geschaffen worden, Funktionen überflüssig zu machen.

Dafür würde ich gerne eine glaubwürdige Quelle sehen, denn die Aussage erscheint mir wenig plausibel.

TempVars wurden nach meinem Kenntnisstand vor allem in Access eingebaut, um ...
1.) Variablen in Makros nutzen zu können, und
2.) Eine speziellen Variablentyp zu haben, der direkt in Abfragen verwendet werden kann. (In diesem Zusammenhang ersetzen sie tatsächlich VBA-Funktionen. Aber ausschließlich nur solche Funktionen, deren einziger Zweck es ist VBA-Variablen in Abfragen zu nutzen.)

Leider 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.

Zitat von: micmen am Juli 08, 2025, 17:31:45da könnte ich alles gleich wieder so umsetzen, wie es vorher war.

Genau, das meinte ich mit einem "Rollback der Änderungen".

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 (https://codekabinett.com/rdumps.php?Lang=1&targetDoc=abfrage-performance-tuning) gibt es mehrere Absätze, die sich mit dem Einsatz von Funktionen beschäftigen und das erläutern.

Wenn Abfragen langsamer laufen, als das wünschenswert wäre, geht das oft mit Ressourcenproblemen einher. Funktionen sind diesbzgl. ein brauchbares Werkzeug, um sich in den eigenen Fuß zu schießen.
Es gibt auch andere Situationen, in denen Access über Ressourcenmangel klagt und die mit Abfragen und/oder Funktionen nicht unmittelbar zu tun haben.

Hi, 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)

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 :o
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:02

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 (https://codekabinett.com/rdumps.php?Lang=1&targetDoc=abfrage-performance-tuning) gibt es mehrere Absätze, die sich mit dem Einsatz von Funktionen beschäftigen und das erläutern.

Ich 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.
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

Zitat 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.

Hallo,

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 (https://www.ccedv.de) 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

Zitat von: markusxy am Juli 10, 2025, 19:16:39

Zitat von: micmen am Juli 10, 2025, 15:12:09hatte Access bei der Anwendung irgendwann Ressourcenprobleme gemeldet

(...)
Da kann dann schon eine Umfangreiche Abfrage genügen, damit so ein Ressourcen-Problem aufkommt.

Wie geschrieben, konnte das Problem auf einen Schlag behoben werden durch Ersetzen von Funktionsaufrufen durch TempVars. Komplexe Abfragen gibt es in der Tat viele, aber keine wurde geändert, und trotzdem hat es nach dieser Ersetzung keine solche Ressourcenprobleme mehr gegeben.

Zitat von: markusxy am Juli 10, 2025, 19:16:39TempVars kann man in VBA-Abfragen genau wie Variablen verwenden, also eine ungünstige Lösung.

Sorry, verstehe ich nicht - ist das nicht ein  Widerspruch in sich? Warum "ungünstig" mit der Begründung, sie wären wie Variablen verwendbar?

Zitat von: markusxy am Juli 10, 2025, 19:16:39Da 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.

Na ja, so krass ist das nun auch nicht, dass keiner "auch nur ein Gefühl für die Materie" hätte...  :D Und genau das hatte ich getan: Mich "extern" schlau gemacht, was solche Ressourenprobleme verursachen kann, und da habe ich ausführliche Informationen dazu gefunden, welche Probleme Funktionsaufrufe in Abfragen haben können, und explizit die Lösung dargestellt gefunden, stattdessen TempVars einzusetzen.

@Bitsqueezer (https://www.access-o-mania.de/forum/index.php?action=profile;u=10697):
Zu dem, was hier mehrmals geschrieben wurde, wir wären in diesem Fall blauäugig gewesen oder riskant vorgegangen:

• Es wurde eine in Fachkreisen öffentlich beschriebene Lösung umgesetzt.
• Die Anwendung WURDE getestet, nur halt mit sämtlichen Funktionen erst nach Abschluß der Arbeiten, und nicht schon vorzeitig 1x nach Einbau einer von vielen Überarbeitungen.
• Es ist uns noch nie untergekommen, dass Abfragen ganz normal funktionieren, aber auf einmal nicht mehr funktionieren, wenn man sie per VBA aufruft. Von so etwas hatte noch keiner auch nur je etwas gehört, geschweige denn, es selbst mal erlebt zu haben. Wenn Menschen es "versäumen", rein prophylaktisch auf ein Problem zu prüfen, von dessen Existenz sie trotz jahrelanger Erfahrung in der Materie nichts geahnt haben, dann werte ich das definitiv nicht als ein "riskantes" oder "blauäugiges" Vorgehen.

In einer perfekten Welt gibt es möglicherweise niemals Fehler, aber solche Dinge wie das jetzt fällt für mich unter die Rubrik, was in unserer Welt oft passiert und wozu es typischerweise die Einschätzung gibt "damit konnte keiner rechnen". Und wie in Punkt 2 gesagt, letztendlich wird immer alles getestet. Lediglich direkt nach dieser einen globalen Änderung wurden Abfragen testweise einfach geöffnet, gingen auf, Haken dran. Stufe ich echt nicht als Harakiri ein...


Den Rest Deines Posts muss ich mir mal reinziehen, wenn ich gut Zeit habe.

Ich kann nicht behaupten, sicher verstanden zu haben, wann eine Funktion auf dieses zeilenweise Ausführen von Abfragen umschaltet.
Oder auch damit, QueryDef-Variablen zu verwenden und deren Parameters-Collection mit Werten zu füllen, muss ich mich mal beschäftigen.

Tools, mit denen wir unseren Code oder auch Berichts-, Formular- oder Abfrage-Entwürfe durchsuchen und auflisten oder darin Dinge direkt gleich ersetzen, haben wir, das wäre kein Problem.

danke!

Hallo,

ZitatIch kann nicht behaupten, sicher verstanden zu haben, wann eine Funktion auf dieses zeilenweise Ausführen von Abfragen umschaltet.

Eigentlich ganz einfach: Wenn Du etwas Variables in eine Funktion hineingibst, das pro Zeile des SQL-Ergebnisses einen unterschiedlichen Wert enthalten kann, dann muß die Funktion auch für jede Zeile erneut aufgerufen werden.
Wenn Du als Parameter einen konstanten Wert übergibst (z.B. ein Literal, eine Zahl) oder wenn der Optimizer erkennen kann, daß der übergebene Wert nur einmal aus den Tabellen gelesen wird, dann wird die Funktion auch nur einmal aufgerufen, weil sich das Ergebnis danach nicht mehr ändert (ändern sollte).

Der Optimizier kann natürlich nicht erkennen, wenn eine Funktion etwa eine Zufallszahl zurückgibt - er überprüft nicht den Code der Funktion. Entsprechend würde auch hier gelten: Wenn Du eine Zufallszahl je Zeile brauchst, mußt Du als Parameter einen Wert (z.B. die ID einer Zeile) übergeben, der den Optimizer veranlaßt, die Funktion für jede Zeile aufzurufen. Wenn Du z.B. nur den Random-Initialwert als feste Zahl übergibst, erhältst Du nur eine Zufallszahl zurück für alle Zeilen.

Es gibt da sicher noch Feinheiten, aber im Groben und Ganzen ist das schon alles.

Gruß

Christian

Hallo,

Zitat von: micmen am Juli 16, 2025, 14:35:26Es ist uns noch nie untergekommen, dass Abfragen ganz normal funktionieren, aber auf einmal nicht mehr funktionieren, wenn man sie per VBA aufruft. Von so etwas hatte noch keiner auch nur je etwas gehört, geschweige denn, es selbst mal erlebt zu haben. Wenn Menschen es "versäumen", rein prophylaktisch auf ein Problem zu prüfen, von dessen Existenz sie trotz jahrelanger Erfahrung in der Materie nichts geahnt haben, dann werte ich das definitiv nicht als ein "riskantes" oder "blauäugiges" Vorgehen.

Doch, so etwas hätte man erahnen können/müssen, schon alleine deshalb, weil der Ausführungskontext ein anderer ist. Ein anderer Kontext bedeutet aber immer auch eine neue Validierung für eine Qualitätsprüfung. Stell dir mal vor, das würde man bei einem Medizinprodukt genauso handhaben.

Man hätte es aber auch herleiten können, wenn bekannt gewesen wäre, daß Abfragen in Access durch den Expression Service ausgewertet werden, VBA hingegen niemals. Hier mal ein kleiner Artikel zu dem Thema:
https://nolongerset.com/expressions-vs-code/ (https://nolongerset.com/expressions-vs-code/)

Das ist übrigens auch der Grund dafür, das Tempvars in Abfragen funktionieren, in VBA-Code aber nicht automatisch evaluiert werden.

Gruß Knobbi38

Zitat von: Bitsqueezer am Juli 16, 2025, 15:08:00Es gibt da sicher noch Feinheiten, aber im Groben und Ganzen ist das schon alles.

danke!
ich werde mich damit auseinandersetzen  8)

Zitat von: Knobbi38 am Juli 16, 2025, 16:29:07Stell dir mal vor, das würde man bei einem Medizinprodukt genauso handhaben.

ich möchte bitte immer wieder darauf hinweisen, dass letztendlich immer die komplette Anwendung getestet wird und eben bei diesen Tests dieses Problem erkannt wurde...
wir hätten die Menschheit nicht ausgelöscht mit unserer Anwendung  :-\

Zitat von: Knobbi38 am Juli 16, 2025, 16:29:07Man hätte es aber auch herleiten können, wenn bekannt gewesen wäre, daß Abfragen in Access durch den Expression Service ausgewertet werden, VBA hingegen niemals. Hier mal ein kleiner Artikel zu dem Thema:
https://nolongerset.com/expressions-vs-code/ (https://nolongerset.com/expressions-vs-code/)

Das ist übrigens auch der Grund dafür, das Tempvars in Abfragen funktionieren, in VBA-Code aber nicht automatisch evaluiert werden.

ja, "wenn bekannt gewesen wäre"... da sprichst Du was wahres aus...  ;D
danke für die Infos!!
wie gesagt, ziehe ich mir alles mal in Ruhe rein, danke

Zitat von: micmen am Juli 16, 2025, 14:35:26Sorry, verstehe ich nicht - ist das nicht ein  Widerspruch in sich? Warum "ungünstig" mit der Begründung, sie wären wie Variablen verwendbar?

Vielleicht solltest du dir mal den Unterschied etwas genauer ansehen.  ;)

Zitat von: micmen am Juli 16, 2025, 14:35:26Na ja, so krass ist das nun auch nicht, dass keiner "auch nur ein Gefühl für die Materie" hätte

Also wenn man Monate invenstiert um dann im Nachhinein festzustellen, dass die Lösung sagen wir mal suboptimal ist, dann ist das wohl ein Schuss ins Knie. Man hätte doch gleich eine sinnvolle Lösung anstreben können, anstatt der Nutzung von TempVars. Da hätte die Konsultation eines Profis Sinn gemacht. Ein Forum befragen, macht nur dann Sinn, wenn man selbst die Grundlagen beherrscht.