- Welcome to Access-o-Mania.
Hilfe zu Microsoft Access und verwandten Produkten
Neueste Beiträge
#11
Access Programmierung / Re: Datenaktualisierung scheit...
Letzter Beitrag von Beaker s.a. - Heute um 13:52:17ZitatIch habe nun folgendes:Dann hast du aber Christians Ausführungen zu "As New" bzw. Early-/Late-
Binding nicht gelesen.
#12
Access Programmierung / Re: True / False bei logischen...
Letzter Beitrag von Bitsqueezer - Heute um 13:48:02Hallo,
das sind allerdings verschiedene Szenarien.
Bei allem, was klar einen Bool-Wert zurückgibt, kann man getrost "True/False"-Vergleiche weglassen. Dein erstes Beispiel mit "Enabled/Visible" zählt dazu. Und es ist einfacher zu lesen, wenn die Bedingung lautet "if x.visible" oder "if y.enabled", weil es dann auch sprachlich paßt.
Bei der Checkbox ist es schon nicht mehr eindeutig, da die Checkbox auch als Tri-State geschaltet werden kann und dann NULL enthalten kann. Bei gebundenen Checkboxen an Ja/Nein-Feldern in einer Access-Tabelle kann das nicht passieren, da Access-Tabellen für Ja/Nein-Felder kein NULL kennen. Ist die Checkbox ungebunden oder an z.B. eine SQL-Server-Tabelle an ein Bit-Feld gebunden, kann sie dagegen auch NULL sein. Hier muß man also ein "Nz" für die Checkbox verwenden, wenn das nicht sicher ist, und einen Booleschen Ersatzwert wählen, wenn es NULL ist. Danach ist das Ergebnis wieder True/False.
Wenn es an ein Bit-Feld gebunden ist, kann es theoretisch auch 0/1 sein, was kein True/False ist. 0=False, aber 1 ist nicht True (in VBA).
Das gleiche gilt für das SELECT-Beispiel. Ist es eine Access-Tabelle, wäre JaNein immer nur True oder False. Aber hier muß man ebenso auf den SQL-Dialekt achten. In T-SQL wäre bei einem Bit-Feld auch hier kein True/False das Ergebnis sondern 0/1. Es gibt auch kein "True/False" hier. Das geht nur in Access-SQL.
Entsprechend muß man aufpassen. In Access-SQL ginge "WHERE JaNeinFeld" in T-SQL nicht. Hier würdest Du einen Fehler erhalten:
An expression of non-boolean type specified in a context where a condition is expected
Da der Vergleich in WHERE fehlt.
Gruß
Christian
das sind allerdings verschiedene Szenarien.
Bei allem, was klar einen Bool-Wert zurückgibt, kann man getrost "True/False"-Vergleiche weglassen. Dein erstes Beispiel mit "Enabled/Visible" zählt dazu. Und es ist einfacher zu lesen, wenn die Bedingung lautet "if x.visible" oder "if y.enabled", weil es dann auch sprachlich paßt.
Bei der Checkbox ist es schon nicht mehr eindeutig, da die Checkbox auch als Tri-State geschaltet werden kann und dann NULL enthalten kann. Bei gebundenen Checkboxen an Ja/Nein-Feldern in einer Access-Tabelle kann das nicht passieren, da Access-Tabellen für Ja/Nein-Felder kein NULL kennen. Ist die Checkbox ungebunden oder an z.B. eine SQL-Server-Tabelle an ein Bit-Feld gebunden, kann sie dagegen auch NULL sein. Hier muß man also ein "Nz" für die Checkbox verwenden, wenn das nicht sicher ist, und einen Booleschen Ersatzwert wählen, wenn es NULL ist. Danach ist das Ergebnis wieder True/False.
Wenn es an ein Bit-Feld gebunden ist, kann es theoretisch auch 0/1 sein, was kein True/False ist. 0=False, aber 1 ist nicht True (in VBA).
Das gleiche gilt für das SELECT-Beispiel. Ist es eine Access-Tabelle, wäre JaNein immer nur True oder False. Aber hier muß man ebenso auf den SQL-Dialekt achten. In T-SQL wäre bei einem Bit-Feld auch hier kein True/False das Ergebnis sondern 0/1. Es gibt auch kein "True/False" hier. Das geht nur in Access-SQL.
Entsprechend muß man aufpassen. In Access-SQL ginge "WHERE JaNeinFeld" in T-SQL nicht. Hier würdest Du einen Fehler erhalten:
An expression of non-boolean type specified in a context where a condition is expected
Da der Vergleich in WHERE fehlt.
Gruß
Christian
#13
Access Programmierung / Re: Datenaktualisierung scheit...
Letzter Beitrag von Mokkie - Heute um 13:36:46Hallo Christian,
ich danke Dir für deine Hinweise.
Ich versuche jetzt erst mal die se ADODBC Verbindung richtig aufzubauebe und den Zugriff darauf.
Habe da bisher nicht mit gearbeitet, daher ist es so chaotisch.
Ich habe nun folgendes:
Vielleicht kannst Du noch mal schauen, ich google mal...
ich danke Dir für deine Hinweise.
Ich versuche jetzt erst mal die se ADODBC Verbindung richtig aufzubauebe und den Zugriff darauf.
Habe da bisher nicht mit gearbeitet, daher ist es so chaotisch.
Ich habe nun folgendes:
Code [Auswählen]
Dim conn As New ADODB.Connection
Dim rs As New ADODB.Recordset
Dim cmd As Object
Dim lActId As Long
Dim strsql As String, sMemo As String
lActId = Forms![Hotline -> Terminallist]!COMPANY_ID
sMemo = IsEmpty(Me!COMPANY_MEMO.Value)
' Verbindung und Recordset wiederherstellen
Set conn = CreateObject("ADODB.Connection")
conn.Open "Provider=MSOLEDBSQL;Server=AFC-MSSQL2016V;Database=FENG;Trusted_Connection=yes;"
Set cmd = CreateObject("ADODB.Command")
cmd.Execute "UPDATE data.COMPANY SET COMPANY_MEMO = '" & sMemo & "' WHERE COMPANY_ID = " & lActId
' Set the command properties
bekomme aber die Fehlermeldung, dass die Vebindung nicht verwednet werden um diesen Vorgang auszuführen, sie ist entweder geschlossen oder oder in diesem zusammenhang unzulässig...Vielleicht kannst Du noch mal schauen, ich google mal...
#14
Tabelle/Abfrage / Re: SQL Abfrage Filtern
Letzter Beitrag von Beaker s.a. - Heute um 12:59:27ungetestet aus der hohlen Hand
gruss ekkehard
Code [Auswählen]
SELECT T.PersID, Max(T.AeDatum) AS LetzteAe
FROM Tabelle As T
WHERE T.AeDatum Is Not NULL
GROUP BY T.PersIDUnd nochmal, - nimm ein richtiges Datumsfeld!gruss ekkehard
#15
Access Programmierung / Re: True / False bei logischen...
Letzter Beitrag von Doming - Heute um 12:26:42Hallo,
das mit den Bool'schen Variablen war nur als Beispiel gedacht.
das mit den Bool'schen Variablen war nur als Beispiel gedacht.
Code [Auswählen]
If Me.TextFeld2.Enabled And Forms!frm_Formular!Textfeld1.Visible And Not Me.Checkbox Thenwäre ebenso ein BeispielCode [Auswählen]
Currentdb.OpenRecordset ("SELECT Feld1, Feld2 FROM tbl_Tabelle WHERE JaNeinFeld AND NOT JaNeinFeld2") #16
Tabelle/Abfrage / Re: SQL Abfrage Filtern
Letzter Beitrag von Bernd Sowa - Heute um 12:25:03Ich dachte, ich hätte es oben verständlich dargestellt.
Aus Tabelle:
[Person];[Aenderungsdatum]
Pers 1 ;
Pers 1 ; 1990
Pers 2 ; 2005
Pers 2 ; 2001
Pers 1 ; 2008
Pers 3 : 2000
Soll in der Abfrage folgendes Ergebnis rauskommen:
Pers 2 ; 2005
Pers 3 ; 2000
Person 1 ist 3 x in der Tabelle. 2x mit Änderungsdatum, 1x ohne Änderungsdatum (Soll deshalb gar nicht angezeigt werden - weil noch aktiv im Unternehmen)
Person 2 ist 2x in der Tabelle, beide DS mit Änderungsdatum. Also bitte nur den DS mit dem Jüngsten Datum anzeigen.
Person 3 ist nur 1x in der Tabelle, mit Änderungsdatum. Anzeigen.
Vielleicht auch in mehreren Schritten.
1. Schritt: aktive rausfiltern
2. Schritt: nur die jüngsten Datensätze anzeigen lassen
Hintergrund ist dass alle Personen die länger als 10 Jahre nicht mehr für das Unternehmen tätig waren, herausgefiltert werden. (zum Löschen)
Datenschutz lässt grüßen.
Aus Tabelle:
[Person];[Aenderungsdatum]
Pers 1 ;
Pers 1 ; 1990
Pers 2 ; 2005
Pers 2 ; 2001
Pers 1 ; 2008
Pers 3 : 2000
Soll in der Abfrage folgendes Ergebnis rauskommen:
Pers 2 ; 2005
Pers 3 ; 2000
Person 1 ist 3 x in der Tabelle. 2x mit Änderungsdatum, 1x ohne Änderungsdatum (Soll deshalb gar nicht angezeigt werden - weil noch aktiv im Unternehmen)
Person 2 ist 2x in der Tabelle, beide DS mit Änderungsdatum. Also bitte nur den DS mit dem Jüngsten Datum anzeigen.
Person 3 ist nur 1x in der Tabelle, mit Änderungsdatum. Anzeigen.
Vielleicht auch in mehreren Schritten.
1. Schritt: aktive rausfiltern
2. Schritt: nur die jüngsten Datensätze anzeigen lassen
Hintergrund ist dass alle Personen die länger als 10 Jahre nicht mehr für das Unternehmen tätig waren, herausgefiltert werden. (zum Löschen)
Datenschutz lässt grüßen.
#17
Access Programmierung / Re: Datenaktualisierung scheit...
Letzter Beitrag von Bitsqueezer - Heute um 12:14:13Hallo Babsi,
ich empfehle, einen Blick in den SQL Server Profiler bzw. die XEvents in SSMS zu wagen, da wirst Du sehen, was da gerade zwischen Access und SQL Server passiert.
ADO zu verwenden, ist OK, aber warum so dermaßen umständlich? Du hast offensichtlich Early Binding, sonst könntest Du nicht "As ... ADODB. ..." verwenden.
1. Auch wenn es möglich ist, sollte man nie "As New" verwenden, da dies ein "Set ... = Nothing" am Ende verhindert. Immer getrennt schreiben als "As ADODB. ..." und dann "Set .. xx = New ADODB. ..." verwenden, am Ende dann mit "Set xx = Nothing" das Objekt entfernen.
2. Wenn Du dann sowieso (hier) schon "New" verwendest (bzw. mit Set ... = New ...), dann hast Du bereits ein passendes Objekt, warum verwendest Du dann noch die Late Binding Variante mit "Create Object"? Das ist überflüssig.
3. Warum ein Recordset mit SELECT erstellen, um es dann umständlich mit dem Recordset mit Update zu schreiben? Wenn Du schon ADO verwendest und damit in T-SQL arbeitest, kannst Du doch auch einfach einen ADODB.Command erstellen und dann mit
Den Update erledigen. Kein Recordset notwendig, nur das Connection Object und das Command Object.
Wenn aber beides nicht funktioniert, gibt es ja offensichtlich ein Problem auf SQL Server Seite, also am besten, wie gesagt, Profiler/XEvents verwenden und schauen, was da genau passiert.
BTW: "[Hotline -> Terminallist]" ist ein sehr schlechter Name für Objekte. In Objektnamen sollte man Leerzeichen, Sonderzeichen und Umlaute grundsätzlich vermeiden. Ein guter Name wäre z.B. "frmHotline_Terminallist".
Das gilt nicht nur für Formularnamen, sondern ALLE Namen. Nicht zu verwechseln mit Beschriftungen in Labeln etc.
Weitere Informationen zum Timeout:
https://learn.microsoft.com/en-us/troubleshoot/sql/database-engine/performance/troubleshoot-query-timeouts
Gruß
Christian
ich empfehle, einen Blick in den SQL Server Profiler bzw. die XEvents in SSMS zu wagen, da wirst Du sehen, was da gerade zwischen Access und SQL Server passiert.
ADO zu verwenden, ist OK, aber warum so dermaßen umständlich? Du hast offensichtlich Early Binding, sonst könntest Du nicht "As ... ADODB. ..." verwenden.
1. Auch wenn es möglich ist, sollte man nie "As New" verwenden, da dies ein "Set ... = Nothing" am Ende verhindert. Immer getrennt schreiben als "As ADODB. ..." und dann "Set .. xx = New ADODB. ..." verwenden, am Ende dann mit "Set xx = Nothing" das Objekt entfernen.
2. Wenn Du dann sowieso (hier) schon "New" verwendest (bzw. mit Set ... = New ...), dann hast Du bereits ein passendes Objekt, warum verwendest Du dann noch die Late Binding Variante mit "Create Object"? Das ist überflüssig.
3. Warum ein Recordset mit SELECT erstellen, um es dann umständlich mit dem Recordset mit Update zu schreiben? Wenn Du schon ADO verwendest und damit in T-SQL arbeitest, kannst Du doch auch einfach einen ADODB.Command erstellen und dann mit
Code [Auswählen]
cmd.Execute "UPDATE data.COMPANY SET COMPANY_MEMO = '" & Me.COMPANY_MEMO & "' WHERE COMPANY_ID = " & Forms![Hotline -> Terminallist]!COMPANY_IDDen Update erledigen. Kein Recordset notwendig, nur das Connection Object und das Command Object.
Wenn aber beides nicht funktioniert, gibt es ja offensichtlich ein Problem auf SQL Server Seite, also am besten, wie gesagt, Profiler/XEvents verwenden und schauen, was da genau passiert.
BTW: "[Hotline -> Terminallist]" ist ein sehr schlechter Name für Objekte. In Objektnamen sollte man Leerzeichen, Sonderzeichen und Umlaute grundsätzlich vermeiden. Ein guter Name wäre z.B. "frmHotline_Terminallist".
Das gilt nicht nur für Formularnamen, sondern ALLE Namen. Nicht zu verwechseln mit Beschriftungen in Labeln etc.
Weitere Informationen zum Timeout:
https://learn.microsoft.com/en-us/troubleshoot/sql/database-engine/performance/troubleshoot-query-timeouts
Gruß
Christian
#18
Tabelle/Abfrage / Re: SQL Abfrage Filtern
Letzter Beitrag von knobbi38 - Heute um 11:56:04Hallo Bernd,
ich habe meine Glaskugel verlegt, deshalb kann ich nicht erkennen, was du da eigentlich treibst.
Gruß Knobbi38
ich habe meine Glaskugel verlegt, deshalb kann ich nicht erkennen, was du da eigentlich treibst.
Gruß Knobbi38
#19
Access Programmierung / Re: True / False bei logischen...
Letzter Beitrag von Bitsqueezer - Heute um 11:55:52Hallo,
man sollte dabei aber auch sicherstellen, daß die drei Variablen wirklich Bool-Variablen sind, also so deklariert wurden. Oft sieht man auch "Dim Bool1" ohne Zusatz oder "Dim Bool1, Bool2, Bool3 As Boolean", wo dann nur der letzte eine Bool-Variable ist und alles andere Variant.
Bei echten Bool-Variablen ist die erste Version von Dir in jedem Fall besser, weil kürzer, lesbarer. Ich wüßte nicht, welchen Vorteil das Ausschreiben mit True/False haben sollte, da bei If ohnehin nur True/False getestet wird.
Gruß
Christian
man sollte dabei aber auch sicherstellen, daß die drei Variablen wirklich Bool-Variablen sind, also so deklariert wurden. Oft sieht man auch "Dim Bool1" ohne Zusatz oder "Dim Bool1, Bool2, Bool3 As Boolean", wo dann nur der letzte eine Bool-Variable ist und alles andere Variant.
Bei echten Bool-Variablen ist die erste Version von Dir in jedem Fall besser, weil kürzer, lesbarer. Ich wüßte nicht, welchen Vorteil das Ausschreiben mit True/False haben sollte, da bei If ohnehin nur True/False getestet wird.
Gruß
Christian
#20
Tabelle/Abfrage / Re: SQL Abfrage Filtern
Letzter Beitrag von Bernd Sowa - Heute um 11:24:25Hallo knobbi,
wenn ich die leeren einfach rausfilter bekomme ich die Datensätze mit der gleichen Person die ein Änderungsdatum haben trotzdem angezeigt. Das soll ja vermieden werden.
Du hast Recht, ich hätte den vorherigen Thread wieder aufmachen sollen.
wenn ich die leeren einfach rausfilter bekomme ich die Datensätze mit der gleichen Person die ein Änderungsdatum haben trotzdem angezeigt. Das soll ja vermieden werden.
Du hast Recht, ich hätte den vorherigen Thread wieder aufmachen sollen.