- Welcome to Access-o-Mania.
Hilfe zu Microsoft Access und verwandten Produkten
Neueste Beiträge
#41
Access Programmierung / aus Access heraus bestimmte Ac...
Letzter Beitrag von Doming - März 24, 2026, 13:26:55Hallo,
Wie bekomme ich im Nachhinein die aufgerufene DB per VBA wieder geschlossen?
Ich möchte die aufrufende DB nicht beenden, auch keine andere Db, die evtl. noch offen sein könnte.
Kann man die bestimmte Access-Instanz irgendwie identifizieren um sie später explizit wieder zu schließen?
accApp.CloseCurrentDatabase bezieht sich doch dann auf die aufrufende, weil aktive Instanz, oder?
Gruß
Doming
Code [Auswählen]
Public Sub DBOeffnen()
Dim accApp As Object
Set accApp = CreateObject("Access.Application")
accApp.OpenCurrentDatabase "C:\TestDB.accdb"
set accApp as Nothing
End SubWie bekomme ich im Nachhinein die aufgerufene DB per VBA wieder geschlossen?
Ich möchte die aufrufende DB nicht beenden, auch keine andere Db, die evtl. noch offen sein könnte.
Kann man die bestimmte Access-Instanz irgendwie identifizieren um sie später explizit wieder zu schließen?
accApp.CloseCurrentDatabase bezieht sich doch dann auf die aufrufende, weil aktive Instanz, oder?
Gruß
Doming
#42
Access Programmierung / Re: rs.MoveLast springt nicht ...
Letzter Beitrag von Doming - März 24, 2026, 12:49:01hm, danke für die Aufklärung. Ich dachte bisher tatsächlich, dass Movelast bei einem Aufruf ohne Sortierung zum chronologisch letzten Datensatz führt, also autowertbasiert.
Ich glaube ich muss so einige meiner DB-Gerüste nochmal neu bewerten.
Ich glaube ich muss so einige meiner DB-Gerüste nochmal neu bewerten.
#43
Access Programmierung / Re: rs.MoveLast springt nicht ...
Letzter Beitrag von Bitsqueezer - März 24, 2026, 12:16:44Hallo,
die Logik ist, daß eine SELECT-Abfrage Datensätze in beliebiger Reihenfolge ausgibt, solange es kein ORDER BY gibt.
"Last" ist dann der letzte in der Sortierreihenfolge. Ohne ORDER BY kann es irgendein Datensatz sein, es KANN der letzte PK sein, aber das ist keine Garantie.
Es gilt bei SELECT: Performance first, wenn es gerade günstiger ist, eine andere Reihenfolge zurückzugeben, dann wird das eben diese sein.
Gruß
Christian
die Logik ist, daß eine SELECT-Abfrage Datensätze in beliebiger Reihenfolge ausgibt, solange es kein ORDER BY gibt.
"Last" ist dann der letzte in der Sortierreihenfolge. Ohne ORDER BY kann es irgendein Datensatz sein, es KANN der letzte PK sein, aber das ist keine Garantie.
Es gilt bei SELECT: Performance first, wenn es gerade günstiger ist, eine andere Reihenfolge zurückzugeben, dann wird das eben diese sein.
Gruß
Christian
#44
Access Programmierung / rs.MoveLast springt nicht zum ...
Letzter Beitrag von Doming - März 24, 2026, 11:58:24Hallo,
ich bin gerade arg verwirrt
Sie dürfen in diesem Board keine Dateianhänge sehen.
Der erste Datensatz in der Tabelle (gefiltert nach diesem Autor) hat die 164164. der letzte die ID 174534.
Frage ich im Haltemodus in der Zeile DateDiff im obigen Code die Zeit ab, gibt er mir das Datum vom Datensatz 164331 an. Gebe ich dann im Direktfenster rs.MoveFirst ein, springt er zum DS 174488, eine Eingabe von rs.MoveLast ergibt dann wieder ID 164331.
Was ist das für eine Logik?
Gruß
Doming
ich bin gerade arg verwirrt
Sie dürfen in diesem Board keine Dateianhänge sehen.
Code [Auswählen]
Set rs = CurrentDb.OpenRecordset("SELECT * FROM tbl_Wartungsprotokoll " _
& "WHERE Autor = '" & Environ("Username") & "'")
If Not rs.EOF Then
rs.MoveLast
If DateDiff("s", rs!Zeit, Now) > 300 Then
End If
End IfDie Tabelle hat etwa 130.000 DS, der gesuchte Autor hat knapp 240 DS.Der erste Datensatz in der Tabelle (gefiltert nach diesem Autor) hat die 164164. der letzte die ID 174534.
Frage ich im Haltemodus in der Zeile DateDiff im obigen Code die Zeit ab, gibt er mir das Datum vom Datensatz 164331 an. Gebe ich dann im Direktfenster rs.MoveFirst ein, springt er zum DS 174488, eine Eingabe von rs.MoveLast ergibt dann wieder ID 164331.
Was ist das für eine Logik?
Gruß
Doming
#45
Access Programmierung / Re: temporäre Tabellen
Letzter Beitrag von hajott - März 23, 2026, 13:39:26Hallo Christian,
wo, eine schnelle und extrem hilfreiche Antwort (auch wenn es mir "einfacher" natürlich lieber gewesen wäre...)
Ich werde nochmal in den "Schmerz" mit der aktuellen Version hineinhorchen und dann gegebenenfalls einen der drei Wege beschreiten. Vielen Dank nochmals!
Viele Grüße
Hans-Jürgen
wo, eine schnelle und extrem hilfreiche Antwort (auch wenn es mir "einfacher" natürlich lieber gewesen wäre...)
Ich werde nochmal in den "Schmerz" mit der aktuellen Version hineinhorchen und dann gegebenenfalls einen der drei Wege beschreiten. Vielen Dank nochmals!
Viele Grüße
Hans-Jürgen
#46
Access Programmierung / Re: temporäre Tabellen
Letzter Beitrag von Bitsqueezer - März 23, 2026, 13:20:52Hallo Hans-Jürgen,
CREATE TEMPORARY war mir bislang nicht bekannt, aber wie Du schon sagst, die Seite beschreibt es, aber viele solcher Kommandos wirken nicht für Access. Da Access ja auch mit nahezu allen externen Datenbanken arbeiten kann, würde ich vermuten, daß es nur dort funktioniert.
Innerhalb von Access ist es einfacher und erlaubt auch mehr einzustellen, eine TableDef zu verwenden, damit kann man Tabellen auch ohne CREATE TABLE erstellen und die zusätzlichen Properties können eingestellt werden.
Allerdings blähst Du so oder so damit die Datenbank immer auf, da ggf. viele Daten importiert werden und wiedr gelöscht werden, was erst bei einer Komprimierung wieder behoben wird. Darüber hinaus, je nach Größe Deiner Datenbank, ist möglicherweise kein Platz mehr für größere Imports.
1. Du kannst diesen Vorgang einfach in einer zweiten Access-Datei durchführen, die kann auch lokal sein, weil sie ja nur temporär benutzt wird. Die dort erstellte Tabelle verwendest Du dann in einer Abfrage in Deiner Hauptdatenbank, um sie entsprechend einzulesen (oder, wenn unbedingt erforderlich, mit einer VBA-Verarbeitung).
2. Statt TransferText könntest Du die Daten auch gleich mit einem ADO Stream als Ganzes in den Arbeitsspeicher laden und dann entsprechend mit VBA einlesen und verarbeiten. Das würde Dir u.a. auch erlauben, einen Progress-Balken anzuzeigen.
3. der optimalere Weg: Gleich weg von Access als Backend und einen DB-Server wie SQL Server verwenden, hier hat jede Serverinstanz eine Datenbank namens tempdb, die man für sowas nutzen kann und die der Server selbst verwaltet/bereinigt. Zum Einlesen von Textdateien gibt es hier auch viele Möglichkeiten.
Gruß
Christian
CREATE TEMPORARY war mir bislang nicht bekannt, aber wie Du schon sagst, die Seite beschreibt es, aber viele solcher Kommandos wirken nicht für Access. Da Access ja auch mit nahezu allen externen Datenbanken arbeiten kann, würde ich vermuten, daß es nur dort funktioniert.
Innerhalb von Access ist es einfacher und erlaubt auch mehr einzustellen, eine TableDef zu verwenden, damit kann man Tabellen auch ohne CREATE TABLE erstellen und die zusätzlichen Properties können eingestellt werden.
Allerdings blähst Du so oder so damit die Datenbank immer auf, da ggf. viele Daten importiert werden und wiedr gelöscht werden, was erst bei einer Komprimierung wieder behoben wird. Darüber hinaus, je nach Größe Deiner Datenbank, ist möglicherweise kein Platz mehr für größere Imports.
1. Du kannst diesen Vorgang einfach in einer zweiten Access-Datei durchführen, die kann auch lokal sein, weil sie ja nur temporär benutzt wird. Die dort erstellte Tabelle verwendest Du dann in einer Abfrage in Deiner Hauptdatenbank, um sie entsprechend einzulesen (oder, wenn unbedingt erforderlich, mit einer VBA-Verarbeitung).
2. Statt TransferText könntest Du die Daten auch gleich mit einem ADO Stream als Ganzes in den Arbeitsspeicher laden und dann entsprechend mit VBA einlesen und verarbeiten. Das würde Dir u.a. auch erlauben, einen Progress-Balken anzuzeigen.
3. der optimalere Weg: Gleich weg von Access als Backend und einen DB-Server wie SQL Server verwenden, hier hat jede Serverinstanz eine Datenbank namens tempdb, die man für sowas nutzen kann und die der Server selbst verwaltet/bereinigt. Zum Einlesen von Textdateien gibt es hier auch viele Möglichkeiten.
Gruß
Christian
#47
Access Programmierung / temporäre Tabellen
Letzter Beitrag von hajott - März 23, 2026, 12:54:53Hallo Wissende,
in meinem Access-Projekt gibt es sechs grundlegende, optimal nomalisierte Tabellen, mit denen der Anwender arbeitet (Filter, Abfragen etc.)
Die zugrundeliegenden Daten ändern sich wöchentlich. Auf Knopfdruck "Update" läuft ein VBA-Code los und
- lädt aus dem Netz diverse txt-Dateien herunter
- diese werden im Originalzustand mittels Transfertext in Dateien eingelesen, die ich mit tmp kennzeichne
- mittels SQL-Befehlen im VBA werden dann die Daten angepasst und mittels INSERT-INTO in die "Haupttabellen" (die also immer bestehen) eingefügt. (Diese werden natürlich vorher geleert)
- Die temporären Tabellen werden danach geDROPt.
- Die Option "beim Schließen komprimieren" ist aktiv, sodass beim Schließen aufgeräumt wird.
Allerdings erst dann... Trotz des DROP ist die accdb noch riesengroß und wenn der Anwender nach dem Update direkt weiterarbeitet, ist es schwerfällig (mein Eindruck). Natürlich könnte man sagen "nach dem Update schließen, Komprimierung abwarten und wieder öffnen", aber ich suche nach einer charmanteren Lösung.
Ich habe die Option "temporäre Tabellen" gefunden, was gut klingt. Dazu würde ich die temporäre Tabelle vorm Transfertext CREATEn, was eigentlich nicht nötig ist. Problem nur: Der Befehl (laut Syntax)
Obwohl das Temporary in der Syntax ausdrücklich vorgegeben ist, wird er nicht akzeptiert. Was mache ich falsch? Gibt es vielleicht noch eine andere Lösung?
Vielen Dank
Hans-Jürgen
in meinem Access-Projekt gibt es sechs grundlegende, optimal nomalisierte Tabellen, mit denen der Anwender arbeitet (Filter, Abfragen etc.)
Die zugrundeliegenden Daten ändern sich wöchentlich. Auf Knopfdruck "Update" läuft ein VBA-Code los und
- lädt aus dem Netz diverse txt-Dateien herunter
- diese werden im Originalzustand mittels Transfertext in Dateien eingelesen, die ich mit tmp kennzeichne
- mittels SQL-Befehlen im VBA werden dann die Daten angepasst und mittels INSERT-INTO in die "Haupttabellen" (die also immer bestehen) eingefügt. (Diese werden natürlich vorher geleert)
- Die temporären Tabellen werden danach geDROPt.
- Die Option "beim Schließen komprimieren" ist aktiv, sodass beim Schließen aufgeräumt wird.
Allerdings erst dann... Trotz des DROP ist die accdb noch riesengroß und wenn der Anwender nach dem Update direkt weiterarbeitet, ist es schwerfällig (mein Eindruck). Natürlich könnte man sagen "nach dem Update schließen, Komprimierung abwarten und wieder öffnen", aber ich suche nach einer charmanteren Lösung.
Ich habe die Option "temporäre Tabellen" gefunden, was gut klingt. Dazu würde ich die temporäre Tabelle vorm Transfertext CREATEn, was eigentlich nicht nötig ist. Problem nur: Der Befehl (laut Syntax)
Code [Auswählen]
DoCmd.RunSQL "CREATE TEMPORARY TABLE tbltest (testfeld INTEGER)"führt zu einem Syntax-Fehler bei der CREATE TABLE-Anweisung, der normale WegCode [Auswählen]
DoCmd.RunSQL "CREATE TABLE tbltest (testfeld INTEGER)"funktioniert jedoch einwandfrei.Obwohl das Temporary in der Syntax ausdrücklich vorgegeben ist, wird er nicht akzeptiert. Was mache ich falsch? Gibt es vielleicht noch eine andere Lösung?
Vielen Dank
Hans-Jürgen
#48
Access Programmierung / Re: Bilder werden im Bericht n...
Letzter Beitrag von Bitsqueezer - März 21, 2026, 23:04:48Hallo,
ich würde auch den Debugger empfehlen. Und darüber hinaus die konsequente Vermeidung von "!" für den Zugriff auf Objekte, sondern immer mit ".". Dann kann Dir sowohl der Compiler wie auch Intellisense weiterhelfen.
Nicht zu vergessen, daß Controls nicht den gleichen Namen wie Felder haben sollten. Damit man auch sicher sein kann, das richtige Objekt anzusprechen.
Gruß
Christian
ich würde auch den Debugger empfehlen. Und darüber hinaus die konsequente Vermeidung von "!" für den Zugriff auf Objekte, sondern immer mit ".". Dann kann Dir sowohl der Compiler wie auch Intellisense weiterhelfen.
Nicht zu vergessen, daß Controls nicht den gleichen Namen wie Felder haben sollten. Damit man auch sicher sein kann, das richtige Objekt anzusprechen.
Gruß
Christian
#49
Bericht / Re: Bericht im Unterformular
Letzter Beitrag von MzKlMu - März 20, 2026, 19:42:56Hallo,
warum fängst Du das jetzt noch mal an ?
Zumal Du im anderen Thema keine Antwort mehr gegeben hast.
Bitte dort weiter machen.
https://www.access-o-mania.de/forum/index.php?topic=27816.msg165825#msg165825
Das Thema hier habe ich gesperrt.
warum fängst Du das jetzt noch mal an ?
Zumal Du im anderen Thema keine Antwort mehr gegeben hast.
Bitte dort weiter machen.
https://www.access-o-mania.de/forum/index.php?topic=27816.msg165825#msg165825
Das Thema hier habe ich gesperrt.
#50
Bericht / Bericht im Unterformular
Letzter Beitrag von Konni - März 20, 2026, 18:00:10Hallo zusammen
ich komme einfach nicht weiter.
ich möchte in einem Unterformular einen Bericht anzeigen.
das funktioniert auch, aber,
nur im Berichtmodus und nicht in Seitenansicht.
Mir geht es darum das im Detailbereich einige Befehle ausgeführt werden müssen
um den Bericht richtig anzuzeigen.
Frage: Wie kann ich Access dazu bewegen im Detailbereiches die Befehle zu verarbeiten wenn
ich den Report im Unterformular öffne.
Viele Grüße an alle die sich jetzt den Kopf zerbrechen.
ich komme einfach nicht weiter.
ich möchte in einem Unterformular einen Bericht anzeigen.
das funktioniert auch, aber,
nur im Berichtmodus und nicht in Seitenansicht.
Mir geht es darum das im Detailbereich einige Befehle ausgeführt werden müssen
um den Bericht richtig anzuzeigen.
Frage: Wie kann ich Access dazu bewegen im Detailbereiches die Befehle zu verarbeiten wenn
ich den Report im Unterformular öffne.
Viele Grüße an alle die sich jetzt den Kopf zerbrechen.