Office: (Office 2003) mehrere Abfragen verschachteln (SQL)?

zu 1:
gut

zu 2:
kommt immer drauf an, in welcher db das ausgeführt wird.

Bei dbTemp.execute "..." sind die Tabellen von dbtemp die eigenen Tabellen, die daher nicht qualifiziert werden müssen. Tabellenaußerhalb von dbTemp sind dann fremde Tabellen und müssen qualifiziert werden.

Bei Currentdb.execute "..." ist Currentdb die DB, deren Tabellen zur Hand sind; hier wäre dann die TempDB die fremde, deren Tabellen zu qualifizieren wären.

Da du die ganze Zeit dbtemp.Execute machst, musstest du alle Tabellen außerhalb von dbtemp mit dem Dateinamen versehen. Es kann da einfacher sein, "das Bein zu wechseln" und das ganze von Currentdb aus aufzuziehen.

Es ist wie mit einer Tür: wo's zu ziehen gilt, hilft kein drücken *Smilie Wenn du drücken willst, musst du auf die andere Seite der Tür gehen.

zu 3:
Ja so sollte es sein. Dann ist vielleicht irgendwo ein Leerzeichen zu wenig oder sowas. Lass dir den ganzen (!) Text der zusammengesetzten SQL mal ausgeben (= schreib ihn in eine Variable und gib die ins Direktfenster aus) und kopiere diese Gesamt-SQL in eine Abfrage. Da wird dir der Fehler genauer beschrieben.

zu 4:
Was ist denn unklar? Du verkettest. Denk es dir so:
? "Heute ist der " & Date() ergibt im Direktbereich:
Heute ist der 16.10.2009 (Date wurde von VBA ausgeführt)

? "Heute ist der & Date()" ergibt im Direktbereich:
Heute ist der & Date() (Date wurde als fester Text gedeutet und daher nicht ausgeführt)

Dass meinte ich mit innen und außen. Du kannst auch "Form" und "Inhalt" dazu sagen.

 

\@Atrus2711
Ich komme leider am Wochende nicht zum probieren ,von daher.
Neue Woche neues Glück*mrcool


folgendes hatte ich probiert:
Code:

Das führte auch in der Abfrage zum gleichen Fehler.

Ich hab dann noch was rum probiert und dabei ist folgendes raus gekommen.

Code:

Das funktioniert.
Für mich siehts jetzt so aus das ich nur einmal in der "From-Klausel" den Tabellen Ort bekannt machen muß.
Sehe ich das richtig?

Gruß
Moerio

 

Ja, die Datei muss nur in der From-Klausel angegeben werden. So wars doch auch in meinen Beispielen?!

 

*rolleyes.gif* Ja,wer lesen kann ist klar im Vorteil*rolleyes.gif*

Ich hatte es Mißverstanden und vor jede Tabellenangabe den Pfad geschrieben.


Noch mal vielen Dank.*top

 

Und ich habs in deinem Code übersehen... *Smilie

 

So,nun bin ich bei der letzten Tabelle angelangt und will den Bericht darauf zugreifen lassen.

Ich hab dann bei Öfnnen des Berichtes die ganzen temporären Tabellen in der tmpDB erstellen lassen und zum Schluß als Datenqelle
Code:

angegeben.
Aber leider wird die tmpDB zu früh geschlossen.

Wie müßte ich vorgehen das die tmpDB erst "Beim Schließen" des Berichtes gekillt wird.

 

Je nach Aufbau deiner DB kannst du

• die TempDB in einem aufrufenden Formular, das immer geöffnet bleibt, erzeugen (das Form kann ja unsichtbar gemacht werden). Erst beim Schließen des Forms stirbt dann die tempDB mit.
• oder die TempDb dem Bericht übergeben, z.B. in einer PropertyGet/Set-Prozedur. Diese Property hat dann nur (!) den Sinn, "Ballfänger" für die Tempdb zu sein, damit sie nicht vorzeitig stirbt. Die TempDb wird im Bericht nicht weiter genutzt (außer in der Datenquelle).

 

Mhm,und schon haste mich wieder erwischt.*boah

Ich hatte mir folgendes gedacht.
Ich öffne den Bericht.
Beim öffnen wird die temporäre Datenbank erzeugt
Meine Abfragen werden durchlaufen.
Der Bericht wird aufgrundlage der letzten erstellten Tabelle angezeigt.
Ich schließe den Bericht
Die temporäre Datenbank wird gekillt.


Code:

*confused.gif*
Ich bin des Programmierens leider nicht soo mächtig.

 

Denke mal so:

1. Du hast ein Formular (!), das den Bericht aufruft.
2. Diese Formular erzeugt die TempDB und legt sie in einer Formularvariablen ab. Es führt auch die Datenverwurstung durch (14 x db.execute ...)
3. Wenn die Daten verwurstet sind, steht die tempDB immer noch zur Verfügung, weil sie im Formular deklariert ist. Solange das geöffnet bleibt, lebt die TempDb.
4. Der Bericht kann jetzt vom Formular aus auf die TempDb zugreifen, denn das Formular hat die solange am Leben gehalten.
5. Der Bericht wird angezeigt. Stundenlang. Das Formular ist solange unsichtbar (aber noch geöffnet)
6. Beim Schließen des Berichts wird das Formular wieder sichtbar. Noch lebt die TempDB, da das Formular nach wei vor auf sie verweist.
7. Beim Schließen des Formulars (oder bei sonst einem Ereignis, bei dem du sagst, die tempDB hat ausgedient) wird das Formular geschlossen. Dabei wird (besser explizit oder sonst implizit) die TempDB-Objektvariable vernichtet. Das sollte der letzte Verweis auf die Temp gewsen sein, die sich daraufhin selbst entleibt.

Im Bericht ist das alles nicht so günstig aufgehoben, weil der ja auf einer Tabelle basiert, die erst zu seiner Laufzeit entsteht....

Wenn du magst, mach ich dir auch eine Demo.

 

Guten Morgen,

das mit dem Formular klingt erst mal gut.
Das Problem was vieleicht dabei auftaucht ist, das ich ein Menu verwende (Treemenu) in dem die Formulare nicht geschlossen werden,wenn Sie nicht gebraucht werden,sondern nur über Visible= True/False geschaltet werden.
Würde also wahrscheinlich für mich erst mal heisen das die temp Datenbank immer am Leben ist,weil das Formular ja nie wirklich geschlossen wird.

Oder kommt es nur darauf an bei welchem Ereigniss(Beim Öffnen,Beim Laden,Bei Focus erhalt) man den Code ablaufen läst?

Für ein kleine Demo wäre ich Dir natürlich sehr dankbar.
Für mich ist es immer einfacher an einem Beispiel etwas nach zu vollziehen.

Gruß
Moeiro

 

Hi,

das Treemenu hab ich auch *Smilie

Die tempDB muss ja nicht im Treemenu-Formular deklariert sein. Im Gegenteil: die TempDB wirst du ja immer nur temporär brauchen (daher ja der Name), d.h. sie sollte nur in den Formularen deklariert und erzeugt werden, die befristet leben. Außerde könnte es sein, dass die Zugriffe auf die gleiche temp-Datei sich gegenseitig blockieren.

Ich habe mal eine Demo beigelegt. Der Obere Knopf erzeugt die tempDB, kopiert da Daten rein und zeigt einen Bericht, der da hin greift. Beim schließen der Berichts bleibt die TempDb zunächst noch erhalten. Wird er aber erneut aufgerufen, "überschreibt" die neue TempDb den Objektverweis auf die alte, was die alte TempDB killt.

Wenn du die alte TempDb vorher killen willst (warum?), dann brauchst du irgendein Ereignis/Auslöser. Der untere Button demonstriert das. Aber behalte zunächst mal die Lebenszeit der tempDB im AUge, wenn du den Bericht ein paar Mal hintereinander startest.

Spätestens bei Form_Close wird aufgeräumt, da dann alle Objekt verncihtet werden.

 

Hallo Atrus2711,

Danke für das Beispiel.
Ich bekomme beim starten einen Fehler.

Der Code bleibt an der Stelle:

rptDemo.RecordSource = "SELECT * FROM [" & dbTemp.Fullname & "].ArtikelPush;"

mit dem Fehler 2191 hängen.

Gruß
Moerio

 

OK, das liegt an Access 2003, habe hier 2007. Da gibts die Layoutansicht noch nicht, in der das geht.

Gut, dann kommt eine kleine Zwischenschicht ins Spiel: eine ABfrage, auf der der Bericht "immer" fußt, und in der die Datenquelle ausgetauscht wird.

Anbei.

 

*winner Super,jetzt gehts.

Danke,werd mal rein sehen und schauen ob ich das verstehe.