- Welcome to Access-o-Mania.
Hilfe zu Microsoft Access und verwandten Produkten
Neueste Beiträge
#91
Tabelle/Abfrage / Re: Daten(mengen)-Problem in T...
Letzter Beitrag von Knobbi38 - November 19, 2025, 11:53:22Dem Beitrag von Phil (#19) kann ich voll zustimmen - ich sehe das genauso.
Knobbi38
Knobbi38
#92
Tabelle/Abfrage / Re: Daten(mengen)-Problem in T...
Letzter Beitrag von PhilS - November 19, 2025, 11:31:35Zitat von: Andre.Heisig am November 19, 2025, 11:13:27Frage an @Knobbi38 und @PhilS: Teilt ihr Christian's (wir hatten einen längeren Austausch per PM) Einschätzung, dass die Betriebsstabilität des Access-Backends nicht unmittelbar gefährdet ist?Ja, absolut.
Aus meiner Sicht ist die Fehlersituation sehr spezifisch durch Strukturänderungen an der Tabelle ausgelöst. Im normalen Betrieb könnte es schlimmstenfalls bei der Aktualisierung einer ähnlich großen Datenmenge (alle Datensätze der Tabelle) zu einer ähnlichen Fehlersituation kommen.
Ich schließe mich auch der Meinung an, dass kritische Anwendungen ein echtes DBMS als Backend haben sollten.
#93
Tabelle/Abfrage / Re: Daten(mengen)-Problem in T...
Letzter Beitrag von Andre.Heisig - November 19, 2025, 11:13:27Zuallererst: Danke an alle fürs Brainstormen.
Ich fass mal zusammen:
- Ich hab ein Mengenproblem, und die Empfehlung, auf SQL umzusteigen. Das bereite ich jetzt vor.
- Ich hab einen Workaround, falls ich Änderungen an der Tabelle vornehmen muss. Ist nicht schön, aber möglich.
(Das nächste bitte nicht falsch verstehen @Bitsqueezer
Frage an @Knobbi38 und @PhilS: Teilt ihr Christian's (wir hatten einen längeren Austausch per PM) Einschätzung, dass die Betriebsstabilität des Access-Backends nicht unmittelbar gefährdet ist? Ich werd beim Kunden die Umstellung auf SQL dringend empfehlen, brauche mal ein Gefühl, wieviel Dampf ich auf den Kessel legen sollte.
Andre.
Ich fass mal zusammen:
- Ich hab ein Mengenproblem, und die Empfehlung, auf SQL umzusteigen. Das bereite ich jetzt vor.
- Ich hab einen Workaround, falls ich Änderungen an der Tabelle vornehmen muss. Ist nicht schön, aber möglich.
(Das nächste bitte nicht falsch verstehen @Bitsqueezer
Frage an @Knobbi38 und @PhilS: Teilt ihr Christian's (wir hatten einen längeren Austausch per PM) Einschätzung, dass die Betriebsstabilität des Access-Backends nicht unmittelbar gefährdet ist? Ich werd beim Kunden die Umstellung auf SQL dringend empfehlen, brauche mal ein Gefühl, wieviel Dampf ich auf den Kessel legen sollte.
Andre.
#94
Access Programmierung / Re: Aus Access heraus Exceltab...
Letzter Beitrag von Bitsqueezer - November 19, 2025, 09:43:35Hallo,
vielleicht hilft Dir das weiter:
https://www.statology.org/vba-freeze-panes/
ActiveWindow muß natürlich passen.
Gruß
Christian
vielleicht hilft Dir das weiter:
https://www.statology.org/vba-freeze-panes/
ActiveWindow muß natürlich passen.
Gruß
Christian
#95
Access Programmierung / Re: Aus Access heraus Exceltab...
Letzter Beitrag von mmarschner - November 19, 2025, 09:37:57Hallo Doming,
ich habe das so bei mir gelöst:
Mit .ActiveWindow in With-Schleifen habe ich immer wieder Probleme gehabt.
Vielleicht hilft Dir das ja so weiter.
Gruß
Michael
ich habe das so bei mir gelöst:
Code [Auswählen]
...
winCount = ExcelObj.Parent.Windows.Count()
ExcelObj.Parent.Windows(winCount).Visible = True
...
ExcelObj.Parent.Windows(winCount).FreezePanes = True
...
Mit .ActiveWindow in With-Schleifen habe ich immer wieder Probleme gehabt.
Vielleicht hilft Dir das ja so weiter.
Gruß
Michael
#96
Access Programmierung / Re: Aus Access heraus Exceltab...
Letzter Beitrag von Doming - November 19, 2025, 08:56:22Edit: OK, der Code läuft nicht durch... kommt davon, wenn man die Fehlermeldungen abfängt
Bei FreezePanes kommt der Fehler 438 - Objekt unterstützt diese Eigenschaft oder Methode nicht
egal ob mit oder ohne ActiveWindow
Bei FreezePanes kommt der Fehler 438 - Objekt unterstützt diese Eigenschaft oder Methode nicht
egal ob mit oder ohne ActiveWindow
#97
Access Programmierung / Aus Access heraus Exceltabelle...
Letzter Beitrag von Doming - November 19, 2025, 08:36:47Hallo,
die Suchmaschinen verstehen mich nicht, ich lande immer auf Excelseiten....
Ich exportiere aus Access heraus Daten in eine Exceltabelle:
Dann öffne ich die Tabelle und passe die Spaltenbreiten an.
Der Code läuft zwar durch, die Spaltenbreite wird angepasst, aber das FreezePanes wird nicht ausgeführt.
Übersehe ich was oder ist das von Access aus nicht möglich?
Gruß
Doming
die Suchmaschinen verstehen mich nicht, ich lande immer auf Excelseiten....
Ich exportiere aus Access heraus Daten in eine Exceltabelle:
Code [Auswählen]
DoCmd.TransferSpreadsheet acExport, 10, "tmpQuery", ExcelDatNam, True, "Tabellenname"Dann öffne ich die Tabelle und passe die Spaltenbreiten an.
Code [Auswählen]
On Error Resume Next
Set xlApp = GetObject(, "Excel.Application")
If xlApp Is Nothing Then
Set xlApp = CreateObject("Excel.Application")
End If
On Error GoTo Fehler
xlApp.Visible = True
Set xlBook = xlApp.Workbooks.Open(ExcelDatNam)
Set xlSheet = xlBook.Worksheets(ExcelTabNam)
With xlSheet
.Columns("A:K").AutoFit
.Rows("2:2").Select
.ActiveWindow.FreezePanes = True
End WithDer Code läuft zwar durch, die Spaltenbreite wird angepasst, aber das FreezePanes wird nicht ausgeführt.
Übersehe ich was oder ist das von Access aus nicht möglich?
Gruß
Doming
#98
Formular / Re: Zugriff vom 1 Formular auf...
Letzter Beitrag von Problemkind - November 18, 2025, 12:02:26Danke erstmal an PhilS und Bitsqueezer,
ich werde einmal mein bestes Geben und versuchen eure Lösungsvorschläge umzusetzen.
ich werde einmal mein bestes Geben und versuchen eure Lösungsvorschläge umzusetzen.
#99
Formular / Re: Zugriff vom 1 Formular auf...
Letzter Beitrag von Bitsqueezer - November 18, 2025, 11:55:47Hallo,
genau wie Phil sage ich auch: Du versuchst, Aufzählungswerte als Tabellen zu erstellen - das ist die falsche Denke, wo immer es um Aufzählungen geht. Man sieht auch oft sowas wie "Aufträge_2024", "Aufträge_2025" usw. Aufzählungen eben, gleiches gilt für Aufzählungen in Feldnamen.
Du kannst ohne weiteres ein DB-konformes System verwenden und die Anforderung dennoch erfüllen.
In "tblObjekte" werden die Objekte beschrieben.
ID_Objekt (AutoID)
ObjektName (Kürzel wie "HL", "BB", "UE")
ObjektBeschreibung (Freitext)
ObjektNameLang (Längerer Name für Displayzwecke)
usw.
In "tblAuftraege" werden die Auftragsdaten erfaßt.
ID_Auftrag (AutoID)
ID_Auftragsnr (Long)
Weitere Felder
In "tblAuftragsnummern" werden die Objekte und die Nummern zusammengefaßt:
ID_Auftragsnr (AutoID)
ID_Objekt (Long) beschreibt, für welches Objekt der Auftrag gilt.
Auftragsnr (Long) enthält die aufsteigende Nr. je Objekt.
In einem Formular kannst Du jetzt die tblAuftraege mit ihren Feldern verwalten. Hier kannst Du in einem ungebundenen Feld per Kombobox die Liste der Objekte zur Auswahl anbieten. Warum ungebunden? Kommt jetzt.
Wenn der User die Auftragsdaten erfaßt, ist die Auswahl des Objektes für ihn wie ein Teil des Datensatzes, obwohl er das nicht ist. Er weiß ja nicht, was gebunden ist und was nicht.
Wenn sich der User entscheidet, den Datensatz abzubrechen, wurde noch keine Auftragsnummer vergeben.
Wenn der User nun den Auftrag speichern will, kannst Du "Form_BeforeUpdate" verwenden, dieser Event wird unmittelbar vor dem Speichern des Datensatzes aufgerufen.
Hier kannst Du nun mit einem INSERT-SELECT-Befehl, aus der Tabelle "tblAuftragsnummern" die höchste Auftragsnummer für das im Formular ausgewählte Objekt (ID_Objekt) per MAX heraussuchen, 1 hinzuaddieren und in die Tabelle einfügen, zusammen mit der gewählten ID_Objekt, alles mit einem einzigen INSERT/SELECT. Im Anschluß kannst Du die erstellte ID abrufen und in das Feld "ID_Auftragsnummer" der Auftragstabelle schreiben - fertig.
INSERT/SELECT ist ein atomarer Befehl, das heißt, nichts kann dazwischenkommen, kein anderer User etwa. Da Du die Operation in Form_BeforeUpdate machst, bekommst Du die Auftragsnummer erst, wenn der Datensatz wirklich gespeichert werden soll. Im Anschluß an die Prozedur mußt Du nichts machen, sobald die Prozedur endet, speichert Access den Datensatz mit den zusätzlichen Daten, die Du dem Datensatz so hinzugefügt hast.
Da das Objekt in der Auftragsnummer steckt, kannst Du nun z.B. in einer Abfrage die Auftragsnummern-Tabelle zur Auftragstabelle hinzu-joinen, ebenso die Objekttabelle, und erhältst alle Informationen zum Auftrag. Wenn gewünscht, kannst Du auch das Kürzel des Objektes zur Auftragsnummer hinzukleben, also "HL-100" oder "BB-543". Das macht die Auftragsnummer weiterhin eindeutig nach außen hin, intern wird aber ausschließlich die ID verwendet, die wiederum NICHT durchgängig fortlaufend sein muß, sondern nur der Identifikation eines Datensatzes dient.
Mit so einer Abfrage kannst Du dann auch Aufträge nach Objekt suchen usw.
Gruß
Christian
genau wie Phil sage ich auch: Du versuchst, Aufzählungswerte als Tabellen zu erstellen - das ist die falsche Denke, wo immer es um Aufzählungen geht. Man sieht auch oft sowas wie "Aufträge_2024", "Aufträge_2025" usw. Aufzählungen eben, gleiches gilt für Aufzählungen in Feldnamen.
Du kannst ohne weiteres ein DB-konformes System verwenden und die Anforderung dennoch erfüllen.
- eine Tabelle "tblAuftraege"
- eine Tabelle "tblObjekte"
- eine Tabelle "tblAuftragsnummern
- und natürlich diverse weitere, die man dazu so brauchen könnte.
In "tblObjekte" werden die Objekte beschrieben.
ID_Objekt (AutoID)
ObjektName (Kürzel wie "HL", "BB", "UE")
ObjektBeschreibung (Freitext)
ObjektNameLang (Längerer Name für Displayzwecke)
usw.
In "tblAuftraege" werden die Auftragsdaten erfaßt.
ID_Auftrag (AutoID)
ID_Auftragsnr (Long)
Weitere Felder
In "tblAuftragsnummern" werden die Objekte und die Nummern zusammengefaßt:
ID_Auftragsnr (AutoID)
ID_Objekt (Long) beschreibt, für welches Objekt der Auftrag gilt.
Auftragsnr (Long) enthält die aufsteigende Nr. je Objekt.
In einem Formular kannst Du jetzt die tblAuftraege mit ihren Feldern verwalten. Hier kannst Du in einem ungebundenen Feld per Kombobox die Liste der Objekte zur Auswahl anbieten. Warum ungebunden? Kommt jetzt.
Wenn der User die Auftragsdaten erfaßt, ist die Auswahl des Objektes für ihn wie ein Teil des Datensatzes, obwohl er das nicht ist. Er weiß ja nicht, was gebunden ist und was nicht.
Wenn sich der User entscheidet, den Datensatz abzubrechen, wurde noch keine Auftragsnummer vergeben.
Wenn der User nun den Auftrag speichern will, kannst Du "Form_BeforeUpdate" verwenden, dieser Event wird unmittelbar vor dem Speichern des Datensatzes aufgerufen.
Hier kannst Du nun mit einem INSERT-SELECT-Befehl, aus der Tabelle "tblAuftragsnummern" die höchste Auftragsnummer für das im Formular ausgewählte Objekt (ID_Objekt) per MAX heraussuchen, 1 hinzuaddieren und in die Tabelle einfügen, zusammen mit der gewählten ID_Objekt, alles mit einem einzigen INSERT/SELECT. Im Anschluß kannst Du die erstellte ID abrufen und in das Feld "ID_Auftragsnummer" der Auftragstabelle schreiben - fertig.
INSERT/SELECT ist ein atomarer Befehl, das heißt, nichts kann dazwischenkommen, kein anderer User etwa. Da Du die Operation in Form_BeforeUpdate machst, bekommst Du die Auftragsnummer erst, wenn der Datensatz wirklich gespeichert werden soll. Im Anschluß an die Prozedur mußt Du nichts machen, sobald die Prozedur endet, speichert Access den Datensatz mit den zusätzlichen Daten, die Du dem Datensatz so hinzugefügt hast.
Da das Objekt in der Auftragsnummer steckt, kannst Du nun z.B. in einer Abfrage die Auftragsnummern-Tabelle zur Auftragstabelle hinzu-joinen, ebenso die Objekttabelle, und erhältst alle Informationen zum Auftrag. Wenn gewünscht, kannst Du auch das Kürzel des Objektes zur Auftragsnummer hinzukleben, also "HL-100" oder "BB-543". Das macht die Auftragsnummer weiterhin eindeutig nach außen hin, intern wird aber ausschließlich die ID verwendet, die wiederum NICHT durchgängig fortlaufend sein muß, sondern nur der Identifikation eines Datensatzes dient.
Mit so einer Abfrage kannst Du dann auch Aufträge nach Objekt suchen usw.
Gruß
Christian
#100
Formular / Re: Zugriff vom 1 Formular auf...
Letzter Beitrag von Problemkind - November 18, 2025, 11:48:17Danke erst einmal für die schnelle Antwort,
klingt alles logisch, bei mir hängt es aber an der richtigen Umsetzung.
Brauche ich noch eine eigene Tabelle "Objekte", damit jedes Objekt seine eigene ID bekommt?
Die Tabelle "Auftrag" hätte dann die Felder: "ID" , "Auftragsort" , "Auftrag" , "lfd_Nummer" , "Objekt" .
Wenn ich jetzt ein Formular erstelle, wo bringe ich dann die DMAX-Funktion ein, und wo zählt der Autowert, der mir im Formular angezeigt werden muss.
Das sprengt mein sehr kleines Wissen über Access, war eigentlich schon froh und stolz, dass meine erste Datenbank funktionierte.
klingt alles logisch, bei mir hängt es aber an der richtigen Umsetzung.
Brauche ich noch eine eigene Tabelle "Objekte", damit jedes Objekt seine eigene ID bekommt?
Die Tabelle "Auftrag" hätte dann die Felder: "ID" , "Auftragsort" , "Auftrag" , "lfd_Nummer" , "Objekt" .
Wenn ich jetzt ein Formular erstelle, wo bringe ich dann die DMAX-Funktion ein, und wo zählt der Autowert, der mir im Formular angezeigt werden muss.
Das sprengt mein sehr kleines Wissen über Access, war eigentlich schon froh und stolz, dass meine erste Datenbank funktionierte.