- Welcome to Access-o-Mania.
Hilfe zu Microsoft Access und verwandten Produkten
Neueste Beiträge
#1
Formular / Re: gebundenes Formular wird z...
Letzter Beitrag von Beaker s.a. - Heute um 18:30:17Hallo Doming,
Die benötigte Eigenschaft des Formulars heisst: "Zyklus" (Reiter "Andere").
Wobei "Alle Datensätze" zum Sprung auf einen neuen führt, und
"Aktueller Datensatz" eben dieses verhindert.
gruss ekkehard
Die benötigte Eigenschaft des Formulars heisst: "Zyklus" (Reiter "Andere").
Wobei "Alle Datensätze" zum Sprung auf einen neuen führt, und
"Aktueller Datensatz" eben dieses verhindert.
gruss ekkehard
#2
Formular / Re: gebundenes Formular wird z...
Letzter Beitrag von Bitsqueezer - Heute um 15:16:14Hallo,
Du kannst aber auch das Formular so einstellen, daß mit TAB nicht zum nächsten Datensatz gesprungen (und damit automatisch gespeichert) wird. Dann springt der Cursor beim letzten Feld wieder auf das erste.
Denk dran, daß ein Verlassen eines Unterformulares auch Save im Unterformular auslöst. Wenn Deine Buttons in einem Hauptformular liegen, dann ist beim Klick bereits gespeichert worden.
Gruß
Christian
Du kannst aber auch das Formular so einstellen, daß mit TAB nicht zum nächsten Datensatz gesprungen (und damit automatisch gespeichert) wird. Dann springt der Cursor beim letzten Feld wieder auf das erste.
Denk dran, daß ein Verlassen eines Unterformulares auch Save im Unterformular auslöst. Wenn Deine Buttons in einem Hauptformular liegen, dann ist beim Klick bereits gespeichert worden.
Gruß
Christian
#3
Formular / Re: gebundenes Formular wird z...
Letzter Beitrag von Doming - Heute um 13:42:28Hm, tatsächlich...
Da ich TxFANr nachträglich in ein bestehendes Formular eingefügt habe, war es natürlich in der Reihenfolge ganz unten.
Ich habe das jetzt mal weiter nach oben geschoben und jetzt wird das Formular-Ereignis BeforeUpdate nicht mehr angesprochen.
Den Tabulator habe ich nicht betätigt, aber Enter natürlich (und somit das AfterUpdate ausgelöst), klar, dass er danach dann zum "nächsten" Element springen will.
Danke für den Hinweis, nun ist meine Erde wieder rund.
Gruß
Doming
Da ich TxFANr nachträglich in ein bestehendes Formular eingefügt habe, war es natürlich in der Reihenfolge ganz unten.
Ich habe das jetzt mal weiter nach oben geschoben und jetzt wird das Formular-Ereignis BeforeUpdate nicht mehr angesprochen.
Den Tabulator habe ich nicht betätigt, aber Enter natürlich (und somit das AfterUpdate ausgelöst), klar, dass er danach dann zum "nächsten" Element springen will.
Danke für den Hinweis, nun ist meine Erde wieder rund.
Gruß
Doming
#4
Formular / Re: gebundenes Formular wird z...
Letzter Beitrag von PhilS - Heute um 13:19:53Ist TxFANr das letztes Steuerelement in der Aktivierreihenfolge und das AfterUpdate wird ausgelöst, wenn du im Feld Tab drückst und damit zu eine neuen Datensatz wechselst?
Das wäre eine logische Erklärung.
Das wäre eine logische Erklärung.
#5
Formular / Re: gebundenes Formular wird z...
Letzter Beitrag von Doming - Heute um 13:06:26Hm, ich habe jetzt damit beholfen, im Form_BeforeUpdate Cancel grundsätzlich auf true zu setzen, es sei denn, ich drücke auf den Speichern-Button. Trotzdem wurden, während ich Daten eingegeben habe, einige Felder wieder geleert, diesmal aber ohne zu speichern. Ich bleibe verwirrt...
#6
Formular / Re: gebundenes Formular wird z...
Letzter Beitrag von Doming - Heute um 12:22:48Danke für die Antwort Klaus, es ist mir schon klar, dass gebundene Formulare automatisch gespeichert werden, aber wieso wird während des Ausfüllens zu einem neuen Satz gesprungen?
#7
Formular / Re: gebundenes Formular wird z...
Letzter Beitrag von MzKlMu - Heute um 12:13:20Hallo,
Access speichert im Regelfall gebundene Formulare immer automatisch. Wenn man das nicht will, muss das im Ereignis "Vor Aktualisierung (Form_BeforeUpdate)" durch setzen des Parameters "Cancel" auf True verhindert werden. Dort bringt man dann zweckmässigerweise eine Rückfrage (Soll gespeichert werden ?) unter. Und das wäre dann der Button der gedrückt werden muss.
Access speichert im Regelfall gebundene Formulare immer automatisch. Wenn man das nicht will, muss das im Ereignis "Vor Aktualisierung (Form_BeforeUpdate)" durch setzen des Parameters "Cancel" auf True verhindert werden. Dort bringt man dann zweckmässigerweise eine Rückfrage (Soll gespeichert werden ?) unter. Und das wäre dann der Button der gedrückt werden muss.
#8
Formular / gebundenes Formular wird zwisc...
Letzter Beitrag von Doming - Heute um 11:35:15Hallo,
irgendwie stehe ich gerade auf dem Schlauch.
Ich habe ein gebundenes Formular, bei dem ich jetzt noch Einträge aus einer Tabelle einfügen möchte
Ich habe ein gebundenes Feld mit der ID, rufe ich das Formular auf, steht darin die neue ID. Nach der obigen Eingabe springt das ID-Feld auf "New", also wurden die Eingaben offenbar gespeichert und es wurde zu einem neuen Datensatz gesprungen. Aber wieso? Es gibt kein Form_AfterUpdate, kein Me.Requery oder Me.Refresh. Gespeichert werden soll das Formular erst nach Drücken eines Buttons.
Ist bestimmt nur ein Verständnisfehler aber ich komm nicht drauf, hat jemand von Euch nen Tipp?
Gruß
Doming
irgendwie stehe ich gerade auf dem Schlauch.
Ich habe ein gebundenes Formular, bei dem ich jetzt noch Einträge aus einer Tabelle einfügen möchte
Code [Auswählen]
Private Sub TxFANr_AfterUpdate()
Dim rs As DAO.Recordset
Set rs = CurrentDb.OpenRecordset("SELECT Auftrag, Pos, LWNr " _
& "FROM Tabelle1 " _
& "WHERE FA = '" & Me.TxFANr & "'")
If Not (rs.BOF And rs.EOF) Then
Me.Tx1 = rs!Auftrag
Me.Tx2 = Nz(rs!Pos, "")
Me.Tx3 = Nz(rs!LWNr, "")
Me.Tx4 = "FA " & Me.TxFANr
End If
Ende:
On Error Resume Next
rs.Close
Set rs = Nothing
Exit Sub
Fehler:
Fehlerprot Err.Number, Err.Description
Resume Ende
End SubSetze ich eine Haltemarke auf Exit Sub, kann ich sehen, dass alle Einträge vorgenommen wurden. Drücke ich dann F8, verschwinden alle Einträge und die Eingaben wurden gespeichert.Ich habe ein gebundenes Feld mit der ID, rufe ich das Formular auf, steht darin die neue ID. Nach der obigen Eingabe springt das ID-Feld auf "New", also wurden die Eingaben offenbar gespeichert und es wurde zu einem neuen Datensatz gesprungen. Aber wieso? Es gibt kein Form_AfterUpdate, kein Me.Requery oder Me.Refresh. Gespeichert werden soll das Formular erst nach Drücken eines Buttons.
Ist bestimmt nur ein Verständnisfehler aber ich komm nicht drauf, hat jemand von Euch nen Tipp?
Gruß
Doming
#9
Access Programmierung / Re: Netzwerkfehler 3043 - Wie ...
Letzter Beitrag von Bitsqueezer - Heute um 09:19:14Hallo,
also in den neueren Access-Versionen sollte das Schließen der Datenbank bei Netzwerkproblemen nicht mehr nötig sein (außer in besonders kritischen Fällen), da Access die Netzwerkverbindung wieder aufbauen kann, was es früher eben nicht konnte, da gab es nichts außer Anwendung beenden und neu starten, oft auch mit Totalabsturz und nur noch Taskmanager als Lösung.
Ich würde also erst mal schauen, ob Access auf dem neuesten Stand ist. Bei den älteren wird Dir auch kaum ein Code-Trick helfen. Dazu kommt, daß es Dir auch nicht hilft, eine neue Query zu öffnen und so zu testen, ob die "Verbindung noch da ist" - weil Access bei MDB/ACCDB im Gegensatz zum früheren ADP für JEDES geöffnete Objekt (Tabelle/Abfrage) eine eigene Verbindung zum Backend aufbaut. Dann hast Du mit OpenQuery vielleicht wieder eine Verbindung, aber die, die Du brauchst, ist immer noch tot. Oder Du prüfst es vorher und DIESE Verbindung ging - aber danach die eigentliche nicht mehr, weil das Problem dann erst auftritt.
Grundsätzlich würde ich allerdings auf die "Wiederherstellungsfähigkeit" von Access nicht wirklich vertrauen und im Fall lieber die Anwendung neu starten. Nur so ein Bauchgefühl...
Du kannst natürlich mit ADO verbindungslosen Recordsets arbeiten, da hast Du (dieses) Problem nicht (dafür ein paar andere), ist aufwendig und auch fehleranfällig. Ansonsten bleibt Dir nur der Umstieg auf z.B. .NET- oder Webandwendungen, die verbindungslos arbeiten. Aber so eine Access-Anwendung schreibt man halt auch nicht "mal eben" um.
Gruß
Christian
also in den neueren Access-Versionen sollte das Schließen der Datenbank bei Netzwerkproblemen nicht mehr nötig sein (außer in besonders kritischen Fällen), da Access die Netzwerkverbindung wieder aufbauen kann, was es früher eben nicht konnte, da gab es nichts außer Anwendung beenden und neu starten, oft auch mit Totalabsturz und nur noch Taskmanager als Lösung.
Ich würde also erst mal schauen, ob Access auf dem neuesten Stand ist. Bei den älteren wird Dir auch kaum ein Code-Trick helfen. Dazu kommt, daß es Dir auch nicht hilft, eine neue Query zu öffnen und so zu testen, ob die "Verbindung noch da ist" - weil Access bei MDB/ACCDB im Gegensatz zum früheren ADP für JEDES geöffnete Objekt (Tabelle/Abfrage) eine eigene Verbindung zum Backend aufbaut. Dann hast Du mit OpenQuery vielleicht wieder eine Verbindung, aber die, die Du brauchst, ist immer noch tot. Oder Du prüfst es vorher und DIESE Verbindung ging - aber danach die eigentliche nicht mehr, weil das Problem dann erst auftritt.
Grundsätzlich würde ich allerdings auf die "Wiederherstellungsfähigkeit" von Access nicht wirklich vertrauen und im Fall lieber die Anwendung neu starten. Nur so ein Bauchgefühl...
Du kannst natürlich mit ADO verbindungslosen Recordsets arbeiten, da hast Du (dieses) Problem nicht (dafür ein paar andere), ist aufwendig und auch fehleranfällig. Ansonsten bleibt Dir nur der Umstieg auf z.B. .NET- oder Webandwendungen, die verbindungslos arbeiten. Aber so eine Access-Anwendung schreibt man halt auch nicht "mal eben" um.
Gruß
Christian
#10
MS SQL-Server / Re: Dokumentation
Letzter Beitrag von Bitsqueezer - Heute um 09:09:55Hallo Martin,
meistens sind zu detaillierte Dokus etwas, was am Ende niemand benutzt, und was in 2 Wochen schon wieder seine Gültigkeit verloren hat, weil wieder einiges geändert wurde.
Ich würde daher keine starren Dokumente anlegen, außer einer generellen Funktionsbeschreibung vielleicht.
Für einen Nachfolge-Entwickler ist es definitiv zielführender, die Objekte da zu beschreiben, wo man die Doku wirklich braucht. In Access bei jedem Feld einer Tabelle, das nicht offensichtlich ist (wie etwa eine PK-AutoID), eine Beschreibung hinzufügen, wozu das Feld dient, wo man eine Lookup-Tabelle dazu findet (wenn es nicht bereits durch eine Referenz darauf offensichtlich ist, aber viele DB-Designer bauen auch referenzlose Datenbanken...), welche Werte darin was bedeuten (z.B. Statuscodes etc.).
Jede Tabelle sollte außerdem eine Tabellenbeschreibung bekommen.
Beides ist natürlich auch bei SQL Server möglich (und sinnvoll) über die Extended Properties. Es gibt auch Freeware-Tools, um diese zu verwalten und zu editieren, macht auf jeden Fall Sinn, weil SSMS hier etwas umständlich ist.
SPs/Views/UDFs sollten natürlich mit Kopf-Kommentaren ausgerüstet sein, Autor, Datum, kurze Änderungshistorie, Beschreibung der Funktion und (außer bei Views) der Parameter.
Das sind die Dokus, die wirklich zählen und die für gewöhnlich dann auch immer aktuell sind. Und die einem Entwickler wirklich helfen.
Was die SPs, UDFs, Views angeht: Ja, mit Redgate findet man z.B. sehr gute Doku-Tools, aber eben halt teuer.
Ich habe mir selbst eins gebaut, findest Du auf meiner Downloadseite unter "Database Documentation V1.2". Das ist eine kleine Access-Datenbank, benötigt nur ein paar wenige Objekte auf dem SQL Server, deren Code enthalten ist in einer Access-Tabelle.
Wenn Du das installiert hast, kannst Du einen Connectionstring zum SQL Server in einer anderen Tabelle speichern, dann mit dem SQL Server verbinden und dann alle oder nur die gewünschten Objekte laden. Das lädt keine Kommentare oder SQL-Code, nur die Namen und ihr Typ sowie die Abhängigkeiten der Objekte voneinander.
Am Ende kann man damit eine Excel-Datei ausgeben, die man im kostenlosen Editor yEd importieren kann. Der kann daraus ein Diagramm erstellen, bei dem man dann genau sehen kann, welche Objekte von was abhängen. Sehr praktisch: Das Fenster "Structure View": Listet jedes Objekt im Diagramm, wenn man dann draufklickt, zeigt er nur den Diagrammteil an, der zu dem betreffenden Objekt gehört, also alles, was direkt damit verbunden ist. So kann man ruhig alle Objekte in ein Diagramm importieren (und ein riesiges chaotisches Diagramm erhalten), und mit der Structure View genau das herausgreifen, was einen interessiert. So sieht man dann schnell die SP, die eine View verwendet, die eine View verwendet, die eine UDF verwendet und welche Tabellen involviert sind usw.
Perfekt für eine stets aktuelle Doku, weil man bei Bedarf eben einfach nochmal alle aktuellen Objekte importiert.
Für Access und VBA gilt natürlich vor allem bei VBA das übliche: Prozedur- und Codekommentare, wo immer nötig. Hier hilft vor allem MZTools, sowohl schnell Kommentarblöcke in Standardformat einzufügen und vorauszufüllen, als auch aus diesen eine komplette Dokumentation zu generieren. MZTools ist eh unverzichtbar und der Preis ist wohl auch unschlagbar.
Gruß
Christian
meistens sind zu detaillierte Dokus etwas, was am Ende niemand benutzt, und was in 2 Wochen schon wieder seine Gültigkeit verloren hat, weil wieder einiges geändert wurde.
Ich würde daher keine starren Dokumente anlegen, außer einer generellen Funktionsbeschreibung vielleicht.
Für einen Nachfolge-Entwickler ist es definitiv zielführender, die Objekte da zu beschreiben, wo man die Doku wirklich braucht. In Access bei jedem Feld einer Tabelle, das nicht offensichtlich ist (wie etwa eine PK-AutoID), eine Beschreibung hinzufügen, wozu das Feld dient, wo man eine Lookup-Tabelle dazu findet (wenn es nicht bereits durch eine Referenz darauf offensichtlich ist, aber viele DB-Designer bauen auch referenzlose Datenbanken...), welche Werte darin was bedeuten (z.B. Statuscodes etc.).
Jede Tabelle sollte außerdem eine Tabellenbeschreibung bekommen.
Beides ist natürlich auch bei SQL Server möglich (und sinnvoll) über die Extended Properties. Es gibt auch Freeware-Tools, um diese zu verwalten und zu editieren, macht auf jeden Fall Sinn, weil SSMS hier etwas umständlich ist.
SPs/Views/UDFs sollten natürlich mit Kopf-Kommentaren ausgerüstet sein, Autor, Datum, kurze Änderungshistorie, Beschreibung der Funktion und (außer bei Views) der Parameter.
Das sind die Dokus, die wirklich zählen und die für gewöhnlich dann auch immer aktuell sind. Und die einem Entwickler wirklich helfen.
Was die SPs, UDFs, Views angeht: Ja, mit Redgate findet man z.B. sehr gute Doku-Tools, aber eben halt teuer.
Ich habe mir selbst eins gebaut, findest Du auf meiner Downloadseite unter "Database Documentation V1.2". Das ist eine kleine Access-Datenbank, benötigt nur ein paar wenige Objekte auf dem SQL Server, deren Code enthalten ist in einer Access-Tabelle.
Wenn Du das installiert hast, kannst Du einen Connectionstring zum SQL Server in einer anderen Tabelle speichern, dann mit dem SQL Server verbinden und dann alle oder nur die gewünschten Objekte laden. Das lädt keine Kommentare oder SQL-Code, nur die Namen und ihr Typ sowie die Abhängigkeiten der Objekte voneinander.
Am Ende kann man damit eine Excel-Datei ausgeben, die man im kostenlosen Editor yEd importieren kann. Der kann daraus ein Diagramm erstellen, bei dem man dann genau sehen kann, welche Objekte von was abhängen. Sehr praktisch: Das Fenster "Structure View": Listet jedes Objekt im Diagramm, wenn man dann draufklickt, zeigt er nur den Diagrammteil an, der zu dem betreffenden Objekt gehört, also alles, was direkt damit verbunden ist. So kann man ruhig alle Objekte in ein Diagramm importieren (und ein riesiges chaotisches Diagramm erhalten), und mit der Structure View genau das herausgreifen, was einen interessiert. So sieht man dann schnell die SP, die eine View verwendet, die eine View verwendet, die eine UDF verwendet und welche Tabellen involviert sind usw.
Perfekt für eine stets aktuelle Doku, weil man bei Bedarf eben einfach nochmal alle aktuellen Objekte importiert.
Für Access und VBA gilt natürlich vor allem bei VBA das übliche: Prozedur- und Codekommentare, wo immer nötig. Hier hilft vor allem MZTools, sowohl schnell Kommentarblöcke in Standardformat einzufügen und vorauszufüllen, als auch aus diesen eine komplette Dokumentation zu generieren. MZTools ist eh unverzichtbar und der Preis ist wohl auch unschlagbar.
Gruß
Christian