Office Forum
www.Office-Loesung.de
Access :: Excel :: Outlook :: PowerPoint :: Word :: Office :: Wieder Online ---> provisorisches Office Forum <-
Datumsfeld an 1. Position Wechseln(Punkt vs. Ausrufezeichen)
zurück: Beispieldatenbanken oder Hilfreiche Beiträge gesucht weiter: Verknüpfungen darstellen Unbeantwortete Beiträge anzeigen
Neues Thema eröffnen   Neue Antwort erstellen     Status: Antwort Facebook-Likes Diese Seite Freunden empfehlen
Zu Browser-Favoriten hinzufügen
Autor Nachricht
wotan85
Access und Excel VBA user


Verfasst am:
04. Sep 2009, 10:38
Rufname: Nils

Datumsfeld an 1. Position Wechseln(Punkt vs. Ausrufezeichen) - Datumsfeld an 1. Position Wechseln(Punkt vs. Ausrufezeichen)

Nach oben
       Version: Office 2007

Dieses Thema wurde aus dem Forum Access Tipps & Tricks verschoben!
Im Forum Access Tipps & Tricks sollen bitte keine Themen mit Fragen eroeffnet werden!
Willi Wipp


Hallo,

ich habe folgendes Problem:

Ich habe ein Formular mit mehreren Eingabefeldern.
Einige davon sind Datumsfelder. Klickt man mit der Maus in eines dieser Felder, so gelangt man immer an die Stelle des Datums, an die man geklickt hat.

Ist es möglich das so abzuändern, dass der Cursor immer an die erste Position des Feldes springt?

Gruß

Nils
Bitsqueezer
Office-VBA-Programmierer


Verfasst am:
05. Sep 2009, 10:38
Rufname:


AW: Datumsfeld an 1. Position Wechseln - AW: Datumsfeld an 1. Position Wechseln

Nach oben
       Version: Office 2007

Hallo Nils,

klar, mit VBA. Im Click-Event des Feldes schreibst Du einfach:
Code:
Private Sub Textfeldname_Click()
    Me.Textfeldname.SelStart=0
    Me.Textfeldname.SelLength=0
End Sub

Gruß

Christian
KlausMz
Moderator Access


Verfasst am:
05. Sep 2009, 10:49
Rufname:
Wohnort: Irgendwo in der Pfalz

AW: Datumsfeld an 1. Position Wechseln - AW: Datumsfeld an 1. Position Wechseln

Nach oben
       Version: Office 2007

@Bitsqueezer
Da Du immer etwas genauer bist, Very Happy lieber mit einem Rufzeichen.
Code:
Private Sub Textfeldname_Click()
    Me!Textfeldname.SelStart=0
End Sub
Auf SelLength kann man denke ich verzichten.
_________________
Gruß
Klaus . . . . . Feedback wäre wünschenswert.
Ich möchte bitte keine unaufgeforderten PN. Fragen bitte im Forum.
Bitsqueezer
Office-VBA-Programmierer


Verfasst am:
05. Sep 2009, 22:40
Rufname:

AW: Datumsfeld an 1. Position Wechseln - AW: Datumsfeld an 1. Position Wechseln

Nach oben
       Version: Office 2007

Hallo Klaus,

nicht wirklich, das Ausrufungszeichen steht zwar im angeblichen Ruf, etwas performanter zu sein, kann dafür aber nicht mit Intellisense umgehen und die Schreibweise von Objekten und ihren Eigenschaften und Methoden hat sich allgemein mit der Punkt-Schreibweise durchgesetzt - lediglich in Access verwenden einige Leute lieber das Ausrufungszeichen - was ich nicht verstehen kann, denn es bietet keinerlei erkennbare Vorteile. Die Lesbarkeit des Codes wird dadurch auch schlechter, besonders für VBA-unerfahrene Leute, die sich fragen, warum hier ein Ausrufungszeichen und dort wieder ein Punkt.
Wenn es in den Formularen auch mit Punkt funktionieren würde, würde ich auch von dort die Ausrufungszeichen verbannen.

Und das SelLength ist schon notwendig, da je nachdem, wohin der User klickt, das Feld beim Klicken auch komplett markiert wird, und das kann man damit umgehen.

Gruß

Christian
derArb
getting better


Verfasst am:
05. Sep 2009, 23:33
Rufname: derArb
Wohnort: Berlin


AW: Datumsfeld an 1. Position Wechseln - AW: Datumsfeld an 1. Position Wechseln

Nach oben
       Version: Office 2007

Hallo,
@Bitsqueezer: Meine Erfahrung bei der Adaption einer Acc2002 DB für Acc2007
ergab, dass genau diese Problematik die Acc2007 DB nicht akzeptierte.
Erst als ich die Pünktchen mit einem Rufzeichen ersetzte, wurde ich erlöst.
Damit meine ich nicht die Rufzeichen in Formularnamen.

_________________
MfG
derArb

Scio me nihil scire...Εν οίδα οτι ουδέν οίδα... Ich weiss, dass ich nichts weiss (Sokrates)
Ich bevorzuge Beiträge mit korrekter deutscher Grammatik.
KlausMz
Moderator Access


Verfasst am:
05. Sep 2009, 23:49
Rufname:
Wohnort: Irgendwo in der Pfalz

AW: Datumsfeld an 1. Position Wechseln - AW: Datumsfeld an 1. Position Wechseln

Nach oben
       Version: Office 2007

Hallo,
Zitat:
kann dafür aber nicht mit Intellisense umgehen
das stimmt, daher verwende ich den Punkt und ändere anschließend in das Rufzeichen.
Ich verwende jedenfalls das Rufzeichen, wie es auch von DonKarl FAQ 6.3 Punkt und Rufzeichen empfohlen wird.
Zitat:
hat sich allgemein mit der Punkt-Schreibweise durchgesetzt -
Das bezweifle ich. Und hier sind wir bei Access und da ist das Rufzeichen richtig.

Ich habe alle möglichen Klick Versionen probiert, das geht auch ohne SelLength wie gewünscht. Ich habe keinen Unterschied gefunden ob mit oder ohne.

_________________
Gruß
Klaus . . . . . Feedback wäre wünschenswert.
Ich möchte bitte keine unaufgeforderten PN. Fragen bitte im Forum.
Bitsqueezer
Office-VBA-Programmierer


Verfasst am:
06. Sep 2009, 09:26
Rufname:

AW: Datumsfeld an 1. Position Wechseln - AW: Datumsfeld an 1. Position Wechseln

Nach oben
       Version: Office 2007

Bitsqueezer am 06. Sep 2009 um 09:19 hat folgendes geschrieben:
Hallo Klaus,

wozu? Nur weil es da steht? Nun ja...
Und das Argument, es gäbe "unerklärliche Fehler beim Kompilieren" halte ich für ein Gerücht, ich habe schon SEHR viel mit Access programmiert, in allen Versionen seit Access 2.0, verwende nie das Ausrufezeichen, und hatte noch nie irgendeinen Fehler, den man nicht hätte aufklären können.
Und erst den Punkt verwenden und dann in ein Ausrufezeichen ändern - geht's noch umständlicher?...Smile
Das "Ausrufezeichen ist richtig" formuliere ich mal anders: Es ist alternativ möglich, aber damit nicht automatisch richtig. Ich denke, Microsoft wollte hier lediglich die Objekte, die selbst erstellt wurden und damit in der Intellisense-Auflistung zum Beispiel eines Formulars als selbst benannte Objekte auftreten (wie hier "Textfeldname") optisch unterscheidbar machen von den in Access eingebauten festen Objekten. Das macht aber lediglich Sinn, wenn man programmiertechnisch ganz genau sein möchte und unbedingt eine Trennung dazwischen optisch deklarieren möchte. Eine objektspezifisch korrekte Trennung wäre dann ja ansonsten auch nur "Me.Controls("Textfeldname")". Hier würde Intellisense aber nicht mehr die Eigenschaften und Methoden speziell einer Textbox anzeigen, sondern nur noch diejenigen, die für alle Controls gelten (SelLength z.B. würde dann nicht mehr angezeigt werden, obwohl es natürlich funktioniert).
Wenn es aber die einzig richtige Methode wäre, ein Ausrufezeichen zu verwenden und keinen Punkt - warum hat man dann nicht schon lange mal Intellisense für Ausrufezeichen eingebaut? Sollte wohl programmiertechnisch keine große Hürde sein. Warum hat man die selbst benannten Controls in die Intellisense-Auflistung dann überhaupt aufgenommen? Mit dem Ausrufezeichen könnte man doch prima die eigenen Objektnamen von den Standardobjekten trennen und dann nur noch die eigenen anzeigen, wenn das Ausrufezeichen eingetippt wird. DAS wäre dann tatsächlich eine Erleichterung!
Warum soll ich mir das Leben als Programmierer ständig komplizierter machen - nur weil's bei DonKarl steht....?
Was machst Du, wenn Du eine andere Eigenschaft auswählen willst und Intellisense verwenden willst, das Ausrufezeichen erst wieder entfernen, den Punkt für die Auswahl verwenden und dann wieder in ein Ausrufezeichen ändern? Wie gesagt, man kann sich das Leben auch selbst schwer machen.

Wie bereits anderweitig gesagt, es sei Dir und jedem anderen unbenommen, was Du oder sonst jemand selbst verwenden möchte, jeder soll so glücklich werden, wie er mag, ich sträube mich aber gegen Aussagen wie "das ist in Access richtig", "das ist richtig, weil es schon in der FAQ bei DonKarl steht", "das ist richtig, weil Microsoft es so empfiehlt". Dadurch wird es nicht richtiger. Für meine Begriffe ist das Ausrufezeichen sinnlose und unnütze Spielerei, die die Programmierzeit unnötig verlängert und den Code deutlich unleserlicher macht, Änderungen erschwert.
Ach ja, und ein immer wieder gesehenes Argument würde ich gern mal nachgewiesen haben: Das Ausrufezeichen soll angeblich ein wenig performanter sein als der Punkt. Wo das dann wirkliche Auswirkungen auf die Laufzeit hat, würde ich gerne mal sehen. Zumal wir hier von einer Datenbank sprechen, deren Hauptaufgabe das performante Ausführen von SQL ist und nicht lang laufende VBA-Programme (wer programmiert denn einen 3D-Shooter mit Access...?).

Mit SelLength: Du hattest recht, bei meinem Test war das getestete Feld zufällig das erste in der Zeile, und wenn man dann außerhalb des Feldes klickt (also auch knapp am Rand) wird eben das erste Feld vollständig markiert. Bei den weiteren Feldern dann nicht mehr.

Gruß

Christian

Hallo derArb,

welche Problematik? Ich kann auch in Access 2007 bisher keine Unterschiede feststellen, was soll mit Ausrufezeichen besser funktionieren als mit Punkten?
Und ich greife in A07 auch immer wieder auf ältere Datenbanken zurück, arbeite seit rund einem Jahr 8 Stunden täglich mit Access 2007, habe noch nicht ein einziges Mal ein Problem gefunden, das nicht mit einer defekten Datenbank oder falschen Referenzen zu tun gehabt hätte.

Gruß

Christian
derArb
getting better


Verfasst am:
07. Sep 2009, 23:36
Rufname: derArb
Wohnort: Berlin

AW: Datumsfeld an 1. Position Wechseln - AW: Datumsfeld an 1. Position Wechseln

Nach oben
       Version: Office 2007

Hallo,

Ich hatte eine Acc XP DB, welche nicht in ACC 07 funktionierte.
Erst, nachdem ich konsequent die Punkte mit Rufzeichen entsprechend den mir hier beigebrachten Regeln austauschte, funktionierte es.
Das ist Fakt. Leider hab ich die ursprüngliche DB nimmer
Vielleicht kann ja Willi Wipp noch eine weitere Aufklärung dazu beitragen.
Oder wer auch immer kompetent sich fühlt.

_________________
MfG
derArb

Scio me nihil scire...Εν οίδα οτι ουδέν οίδα... Ich weiss, dass ich nichts weiss (Sokrates)
Ich bevorzuge Beiträge mit korrekter deutscher Grammatik.
Willi Wipp
Moderator


Verfasst am:
08. Sep 2009, 06:16
Rufname:
Wohnort: Raum Wiesbaden

Re: Datumsfeld an 1. Position Wechseln - Re: Datumsfeld an 1. Position Wechseln

Nach oben
       Version: Office 2007

@Bitsqueezer,

OK dann auch noch ich Wink
Und wie siehst Du das dann beim Recordset-Objekt?
Code:
    Dim rs As DAO.Recordset
   
    Set rs = CurrentDb.OpenRecordset("SELECT * FROM tblDeineTabelle")
Debug.Print rs.Fields(0)
Debug.Print rs.Fields("DeineID")
Debug.Print rs!DeineID
'Debug.Print rs.DeineID                ' Fuehrt ja zu Fehler beim Kompilieren:
                                     ' Methode oder Datenobjekt nicht gefunden
    rs.Close
    Set rs = Nothing
Im Formular funktioniert dagegen dann
Code:
Debug.Print tbxDeineID   ' Textbox im Formular mit Steuerelementinhalt DeineID
Debug.Print Me.tbxDeineID
Debug.Print Me!tbxDeineID
Debug.Print Me.Controls("tbxDeineID")
'Debug.Print Me.Recordset.Fields("tbxDeineID")          ' Na klar Fehler 3265:
                                 ' Element in dieser Auflistung nicht gefunden
'Debug.Print Me.Recordset!tbxDeineID                                     'Dito
Debug.Print DeineID  ' Nur Feld im Recordset (kein Steuerelement im Formular!)
Debug.Print Me.DeineID
Debug.Print Me!DeineID
Debug.Print Me.Controls("DeineID")     ' Warum spaetestens hier kein Fehler???
Debug.Print Me.Recordset.Fields("DeineID")
Debug.Print Me.Recordset!DeineID
Solange eine saubere Trennung zwischen Steuerelementen und Feldern erfolgt OK,
aber was wenn der Benutzer sie gleich benennt oder gar Namen wie Name verwendet?
Da ist man dann aus meiner Sicht mit dem Ausrufezeichen besser dran,
zumindest als Anfaenger, und gerade an diese richtet sich diese Forum primaer.

_________________
Eine kurze Rueckmeldung waere nett
SL Willi Wipp

(Anleitung fuer das Anhaengen von Dateien: Klicke links auf [www], Gaeste muessen sich dafuer anmelden)
Bitsqueezer
Office-VBA-Programmierer


Verfasst am:
08. Sep 2009, 11:49
Rufname:

AW: Datumsfeld an 1. Position Wechseln - AW: Datumsfeld an 1. Position Wechseln

Nach oben
       Version: Office 2007

Hallo Willi,

kann ich Dir sagen: GERADE als Anfänger sollte man sich von vornherein an eine Schreibweise gewöhnen, die Fehler abfängt. Die !-Schreibweise fängt den Fehler nicht ab, sie geht einfach davon aus, daß es ein so benanntes Feld schon geben wird (kannst Du mit einem Compile-Durchlauf schnell feststellen).

Was auch der Grund ist, warum Intellisense mit "!" nichts anfangen kann, weil hier einfach auch nichts geprüft wird.

Bei Recordsets ist es genauso: Die richtige Schreibweise hast Du ja bereits geschrieben, nämlich die beiden "Fields"-Varianten, die auch dem Leser eines Codes eindeutig vermitteln, was man hier gerade macht. Wenn ich mein Feld "xy" nenne und "rs!xy=4" schreibe, weiß ein Leser nicht, worum es sich hier handelt, bei "rs.Fields("xy")" ergibt sich aber beim Lesen bereits, daß ich auf ein Feld des Recordsets zurückgreife - mit "!" kann ein Nicht-VBA-Programmierer nichts anfangen.

Der Grund, warum es zu den "unerklärlichen Fehlern beim Kompilieren" kommt, ist genau der, den Du beschrieben hast: Weil Steuerelemente den gleichen Namen erhalten haben wie Datenfelder der zugrundeliegenden Abfrage eines Formulars. Leider etwas, daß die Automatik von Access vorexerziert, aber absolut zu vermeiden ist. Ganz einfach nachzuvollziehen:
Wenn ich meinem Formular eine RecordSource direkt im Formulareditor zuweise und dann gleiche Namen Felder/Datenfelder habe, ist es egal, ob ich Punkt oder Ausrufezeichen verwende, der Compile funktioniert immer. Warum? Weil die RecordSource beim Compile geprüft wird, und wenn sich der Feldname hier findet, funktioniert der VBA-Code. Geprüft wird aber nur, wenn der Punkt verwendet wird ("Element in dieser Auflistung nicht gefunden").
Aus Performance-Gründen (besonders bei Verwendung von Backends, Datenbankserver oder Access Projekten) ist es aber besser, die RecordSource nicht mit dem berühmten "SELECT * FROM MeineTabelle" zuzuweisen, um sie dann mit OpenForm und dem Where-Argument auf ein bestimmtes Element zu setzen. Es geht bedeutend schneller, wenn man stattdessen das WHERE-Kriterium in den OpenArgs festlegt und bei Form-Load dann die RecordSource zusammenbastelt und auf das Formular legt (wer's nicht glaubt, sollte sich mal den Datenverkehr zwischen Access und einem SQL Server mit dem SQL Profiler anschauen - es ist erstaunlich, was Access da alles überflüssigerweise macht... das gilt übrigens auch für das automatische Verlinken von HFO und UFO mit den Link-Feldern - besser ist, selber machen.).
Da diese Methode aber erst zur Laufzeit eine RecordSource einstellt, wird auf einmal jeglicher Compile-Versuch, bei dem im Code direkt auf die Datenfelder zugegriffen wird, mit dem o.g. Fehler abgestraft (wenn die Punkt-Schreibweise verwendet wird). Wechselt man hier auf "!", geht der Compiler darüber hinweg, aber nun ist es meine eigene Aufgabe, zu sichern, daß der Feldname auch wirklich existiert. Greife ich dagegen mit einem korrekt unterschiedlichen Namen auf das Formularfeld mit Punkt-Schreibweise zu, akzeptiert der Compiler ohne Fehlermeldung, und wenn ich ein Formularfeld dann umbenenne, zeigt mir der Compiler im Code schnell alle Stellen an, die ich nun anpassen muß - beim Ausrufezeichen stellt man das erst zur Ausführung fest und muß nun selbst nach allen Stellen suchen.

Warum "Controls("DeineID")" keinen Fehler bringt, ist auch klar: Weil die Controls-Auflistung eine Auflistung aller Elemente eines Formulars enthält, von denen man mit dem Literal "DeineID" auf ein bestimmtes Element zugreifen möchte - aber erst zur Laufzeit. Das ist exakt der Sinn dieser Auflistung, denn nicht die Verwendung von Literalen macht diese Auflistung so sinnvoll, sondern die Verwendung von Variablen. Dazwischen unterscheidet der Compiler nicht und prüft nur die korrekte Syntax und das Vorhandensein der Auflistung "Controls" im Formularobjekt, entsprechend gibt es auch keine Fehlermeldung, auch nicht, wenn dort "xxx" steht und es kein Feld "xxx" gibt - letzten Endes also ähnlich wie das Ausrufezeichen (nur bei diesem kann man keine Variablen verwenden, also wieder sinnlos).

Also: GERADE für Anfänger ist es sinnvoll, sich von Beginn an die bessere Methode einzuprägen und konsequent zu verwenden, weil es im Nachhinein viele Probleme vermeidet, man kann es so zusammenfassen:

- wenn ich auf ein Datenfeld eines Formulars MIT vorher eingestellter RecordSource zugreife, dann sollten Datenfelder und Formularfelder IMMER unterschiedlich benannt werden - zum Beispiel durch ein einheitliches Prefix vor allen Formularfeldnamen mit dem Datenfeldnamen als zweiten Teil. Dadurch findet man alle Formularfeldnamen in Intellisense an der gleichen Stelle der Auflistung
-> schnellere Eingabe
- wenn ich auf ein Datenfeld eines Formulars OHNE vorher eingestellter RecordSource zugreifen möchte, dann ist es besser, folgende Schreibweise zu verwenden: Me.RecordSet.Fields("Datenfeld"). Im Regelfall ist das aber gar nicht nötig, da VBA ohnehin schneller und einfacher auf Formularfelder zugreifen kann, die man nach oben genannter Benennungsmethode in der Auflistung schnell findet. Der Inhalt entspricht ohnehin dem Datenfeld der ControlSource, also ist der umständliche Weg eines Direktzugriffs gar nicht notwendig. Felder, die nicht gezeigt werden sollen, aber verwendet werden, bindet man am besten als versteckte Felder ein, gleiche Benennungsregeln. Damit ist IMMER sichergestellt, daß alle VBA-Zugriffe auf ein eindeutiges Objekt verweisen und IMMER richtig compiliert wird, wenn konsequent die Punkt-Schreibweise verwendet wird.
- weil Access beim Erstellen eines Formulars OHNE eingestellter RecordSource weder die Feldliste anzeigen kann noch die Felder ohne die "grüne Fehlerecke" anzeigt, kann man bis zur Fertigstellung des Formulars die RecordSource in den Form-Eigenschaften belassen und erst am Schluß entfernen. Hat man überall die richtige Punkt-Schreibweise verwendet, werden alle Objekte im Code geprüft und Direktzugriffe auf Felder, die nicht richtig benannt wurden oder kein Pendant im Formular haben, werden vom Compiler schnell gefunden und angemeckert.

Man vermeidet einen Haufen Probleme durch diese Technik und die Verwendung von versteckten Feldern hat zudem noch den Vorteil, daß ich als Programmierer sofort sehen kann, welche Felder im Code verwendet werden. Das wiederum führt automatisch zur nächsten Optimierung, nämlich die konsequente Vermeidung von "SELECT *", die man aus Bequemlichkeit so gern verwendet. Wird eine Tabelle später erweitert, werden auch die Spalten jedesmal mit eingelesen, die in diesem Formular vielleicht gar nicht verwendet werden. Stattdessen ist es wesentlich performanter, nur die Spalten anzugeben, die genau dieses Formular auch wirklich verwendet (man kann etwa in fast jeder SQL-Server-Tabelle, die TimeStamp-Felder ausklammern, da diese i.d.R. nicht verwendet werden und Access und SQL Server sich selbst aushandeln, was sie damit machen, mit "SELECT *" wird dagegen auch diese Spalte übertragen - unnötiger Datenmüll). Wenn man dagegen im Formular explizit die verwendeten Felder in der RecordSource angibt, eine Entsprechung im Formular hat, die Benennungsregeln befolgt, funktioniert das gleiche Formular ohne Änderungen auch später noch.

Das Argument "Anfänger" ist also nun wirklich kein Argument, eher unterstützt die Verwendung von "!" Bequemlichkeit beim Programmieren, die man aber später durch schwierige Fehlersuche mit weit mehr Zeitaufwand bezahlen muß (natürlich nicht bei der Verwaltung der heimischen Adresskartei, bestehend aus zwei Tabellen und Formularen). Wer es sich gleich von Anfang an angewöhnt, ein winziges bißchen Mehraufwand zu betreiben, wird durch sauberen Code und einfachere Wartung belohnt.

Übrigens, die Verwendung von "Debug.Print DeineID" ist auch so eine Ultrakurzschreibweise, die Access erlaubt, die aber ebenso bekloppt ist. Was ist nun "DeineID"? Eine Variable? Eine Konstante? Ein Feldname? Ein Datenfeldname?
Schreibt man dagegen konsequent IMMER bei Zugriff auf lokale Objekte "Me.", erhält man nicht nur eine sinnvolle Intellisense-Auflistung, sondern auch einen lesbaren Code: Es ist schon mal sicher, daß es keine Variable und keine Konstante ist. Und um die Datenfelder von den Formularfeldern zu unterscheiden, ist der o.g. Prefix ein deutlicher Hinweis. So ist dann in meinem Code etwa "Debug.Print Me.DeineID" automatisch als Datenfeld zu identifizieren (hier vorausgesetzt, daß eine RecordSource im Formular existiert) und "Debug.Print Me.frmDeineID" das zugehörige Formularfeld, dessen ControlSource "DeineID" ist.

Disziplin bei der Programmierung ist bei allen Projekten, die auch nur ein bißchen größer sind, oberstes Gebot, dann begreift man auch seinen eigenen Code noch nach ein paar Jahren sofort - und bei konsequenter Vermeidung von "!"-Schreibweise oder sonstigen Abkürzungen macht man sich das Leben viel leichter.

Aber Abkürzungen sind doch so schön? Dann sollte man sich lieber von Beginn an die "With"-Schreibweise angewöhnen, etwa so:
Code:
    With Me
       .frmDeineID = 1
    End With
Wieder ist der Punkt sinnvoller, weil er mir wieder alle Intellisense-Auflistungen bietet.

Und wo wir gerade bei Objekten sind, in der Deklaration eines Recordsets gehört, wie Du es auch schon oben geschrieben hast, immer der Objektursprung hinzu:
Code:
    Dim rs As DAO.Recordset
und nicht, wie oft verwendet, weil es so schön abkürzt:
Code:
    Dim rs As Recordset
Auch hier zeigt sich dann wieder der Sinn der Punkt-Schreibweise, nämlich die Auflistung aller Objekte, Methoden und Eigenschaften, die die DAO-Bibliothek bietet.

@derArb: Du siehst, woran das Problem Deiner Datenbank vermutlich gelegen haben wird: Daß es Zugriffe auf Objekte gab, die der Compiler anhand von fehlerhafter Gleichbenennung oder fehlerhaft verwendeter Schlüsselwörter als Objektnamen nicht akzeptiert hat. Richtig ist also nicht, die Punkte gegen Ausrufezeichen zu ersetzen, es sind auch keine "unerklärlichen Fehler", wie bei DonKarl zu lesen ist, es ist schlicht inkonsequente und falsch benannte Objektbenennung und, wie ich meist zu sagen pflege: In der Regel hat der Computer immer recht, hier der Compiler. Wenn er einen Fehler anmeckert, dann gibt es auch eine Fehlerursache, und die richtige Methode ist nicht, den Compiler auszuhebeln, indem man das Ausrufezeichen einsetzt und damit einfach die Fehleranzeige abschaltet, sondern richtig ist, die Fehlerursache zu finden und zu beheben - und das geht immer, Ausnahme sind lediglich offensichtliche Datenbankfehler (Dateifehler), die man mit Reparaturmaßnahmen beheben muß. Solche Fehler kann man in Modulen schnell herausfinden, indem man ein Modul exportiert, löscht und dann wieder importiert. Dadurch werden alle binären Anteile eines Moduls entfernt. Wenn es danach noch Compilerprobleme gibt, handelt es sich garantiert um einen Programmierfehler nach dem oben beschriebenen Prinzip.

Wie gesagt, ich will niemanden "bekehren", jeder soll mit seiner Methode glücklich werden, aber bitte keine Aussagen wie "wir sind hier in Access und da ist ! richtig" oder gar "Korrekturen" von Code, der die Punkt-Schreibweise verwendet.

Gruß

Christian
derArb
getting better


Verfasst am:
08. Sep 2009, 20:54
Rufname: derArb
Wohnort: Berlin

AW: Datumsfeld an 1. Position Wechseln - AW: Datumsfeld an 1. Position Wechseln

Nach oben
       Version: Office 2007

Hallo,
vielen Dank Bitsqueezer für die ausführliche Erklärungen.
Ich kann dem allerdings weder zustimmen, noch das Gegenteil davon behaupten..
Dafür bin ich viel zu sehr Amateur und kein Programmierer.
Für mich wirkte das nur logisch, dass Acc07 anscheinend diesen Mismatch
von Punkt und Rufzeichen, der in meiner XP Version noch funktionierte,
erst akzeptierte, als ich denselben Code auf die hier gelernte Eindeutigkeit mit dem Rufzeichen umstellte.
Ich kann natürlich nicht im Nachhinein nachvollziehen, ob das wirklich das einzige Problem war. Mir erschien es aber so.

Jedenfalls vielen Dank für Deine exzellente Erklärung.
Das weitere Philosophieren darüber beobachte ich gerne weiter und bin sehr gespannt darauf.

_________________
MfG
derArb

Scio me nihil scire...Εν οίδα οτι ουδέν οίδα... Ich weiss, dass ich nichts weiss (Sokrates)
Ich bevorzuge Beiträge mit korrekter deutscher Grammatik.
Bitsqueezer
Office-VBA-Programmierer


Verfasst am:
08. Sep 2009, 22:45
Rufname:

AW: Datumsfeld an 1. Position Wechseln - AW: Datumsfeld an 1. Position Wechseln

Nach oben
       Version: Office 2007

Hallo derArb,

möglicherweise lag es an den eingestellten Compiler-Optionen in Deinem Access XP, denn meines Wissens hat sich an der Art der Unterscheidung nicht wirklich viel verändert. Vielleicht ist der Access 2007 Compiler nun "schärfer", was gut wäre, aber rein gefühlsmäßig würde ich sagen, daß es da keinen Unterschied gab.

Während Access eine brandneue Oberfläche hat, wurde der VBA-Editor gerade mal um die Fähigkeit erweitert, mit der Maus zu scrollen...Smile
Also neben vielen hinzugekommenen Objekten sollte es wohl nicht viele Unterschiede zwischen beiden Versionen geben, was diese spezielle Geschichte angeht.

Gruß

Christian
derArb
getting better


Verfasst am:
08. Sep 2009, 23:12
Rufname: derArb
Wohnort: Berlin

AW: Datumsfeld an 1. Position Wechseln - AW: Datumsfeld an 1. Position Wechseln

Nach oben
       Version: Office 2007

Hallo,

@Bitsqueezer...mir erschien die schärfere Kontrolle auch als logisch.
eine neuere Version...könnte man sich vorstellen.
....werde das Thema weiter beobachten

_________________
MfG
derArb

Scio me nihil scire...Εν οίδα οτι ουδέν οίδα... Ich weiss, dass ich nichts weiss (Sokrates)
Ich bevorzuge Beiträge mit korrekter deutscher Grammatik.
Bitsqueezer
Office-VBA-Programmierer


Verfasst am:
09. Sep 2009, 14:50
Rufname:


AW: Datumsfeld an 1. Position Wechseln - AW: Datumsfeld an 1. Position Wechseln

Nach oben
       Version: Office 2007

Hallo,

zwei Problemvarianten sind mir heute noch über den Weg gelaufen, die das Thema IntelliSense betreffen:

Problem: Wenn man ein Formularfeld umbenennt, erscheint in IntelliSense nicht nur noch der neue Name, sondern der alte UND der neue Name, mit jeder Umbenennung kommt ein neuer Name in die IntelliSense-Auflistung hinzu.

Ursache: Das ist offensichtlich ein Bug mindestens in Access 2007 (bei den älteren Versionen weiß ich es nicht). Aufgetreten bei mir in einem Access Projekt in einem Formular mit eingestellter RecordSource, passiert aber möglicherweise auch in normalen Access Datenbanken.

Lösung: Bei mir hat es in diesem Fall geholfen, die RecordSource zu entfernen, danach wurde die IntelliSense-Auflistung aktualisiert und das Problem der mehrfachen Objekte trat nicht mehr auf.


Problem 2: Der Compiler zeigt einen Fehler an und behauptet, das Feld "Me.frmFeldname" im VBA-Code würde nicht existieren, die Textstelle wird markiert. IntelliSense zeigt aber, daß es da ist.

Ursache: Passiert, wenn man eine Zeile mit dem Unterstrich über mehr als eine physikalische Zeile hinaus schreibt, z.B.:
Code:
    strText = Me.frmFeldname & _
              Me.Feldname2
Lösung: Der Compiler markiert ganz einfach die erste Codezeile, kann aber mit den Zeilenfortsetzungen offenbar nicht umgehen - was die Fehlermarkierung angeht. Der Fehler wird trotzdem richtig gefunden, eben nur nicht richtig markiert. Das Problem in diesem Fall hier ist, daß "Me.Feldname2" nicht im Formular existiert, was der Compiler (zu recht) anmeckert. Behebt man den Fehler, funktioniert auch das Compilieren.

Wieder mal zwei Fehler der Kategorie "Häh?"...Smile
Aber auch hier behebbar.

Gruß

Christian
Neues Thema eröffnen   Neue Antwort erstellen Alle Zeiten sind
GMT + 1 Stunde

Diese Seite Freunden empfehlen

Seite 1 von 1
Gehe zu:  
Du kannst Beiträge in dieses Forum schreiben.
Du kannst auf Beiträge in diesem Forum antworten.
Du kannst deine Beiträge in diesem Forum nicht bearbeiten.
Du kannst deine Beiträge in diesem Forum nicht löschen.
Du kannst an Umfragen in diesem Forum nicht mitmachen.
Du kannst Dateien in diesem Forum nicht posten
Du kannst Dateien in diesem Forum herunterladen

Verwandte Themen
Forum / Themen   Antworten   Autor   Aufrufe   Letzter Beitrag 
Keine neuen Beiträge Access Tabellen & Abfragen: Datumsfeld mit Datum() abgleichen 4 lurot 506 14. Jul 2010, 09:45
lurot Datumsfeld mit Datum() abgleichen
Keine neuen Beiträge Access Tabellen & Abfragen: Komma statt Punkt 7 Access00815 1711 14. Jul 2009, 11:27
Willi Wipp Komma statt Punkt
Keine neuen Beiträge Access Tabellen & Abfragen: Datumsfeld ändern 1 Twix22 280 22. Sep 2008, 10:03
KlausMz Datumsfeld ändern
Keine neuen Beiträge Access Tabellen & Abfragen: Datumsfeld+xMonate 4 Bernd62 397 23. Jun 2008, 15:18
Bernd62 Datumsfeld+xMonate
Keine neuen Beiträge Access Tabellen & Abfragen: 2 Tabellen in 1 3 lodstyle 291 19. März 2008, 18:08
KlausMz 2 Tabellen in 1
Keine neuen Beiträge Access Tabellen & Abfragen: 3 Jahre zu einem Datumsfeld hinzufügen 2 Hundhausen 392 11. Nov 2007, 12:09
Hundhausen 3 Jahre zu einem Datumsfeld hinzufügen
Keine neuen Beiträge Access Tabellen & Abfragen: Mit Abfrage letztes Zeichen löschen wenn das ein Punkt ist 2 PeterD 3332 24. Aug 2007, 12:29
PeterD Mit Abfrage letztes Zeichen löschen wenn das ein Punkt ist
Keine neuen Beiträge Access Tabellen & Abfragen: Parameterabfrage nach Jahreszahl bei Datumsfeld 8 Co1m-Co1tus 3010 22. Aug 2007, 13:20
Co1m-Co1tus Parameterabfrage nach Jahreszahl bei Datumsfeld
Keine neuen Beiträge Access Tabellen & Abfragen: Aktualisierungsabfrage: Eckige Klammern und Ausrufezeichen 8 Kira 5044 08. Jul 2007, 01:03
Thomas2007 Aktualisierungsabfrage: Eckige Klammern und Ausrufezeichen
Keine neuen Beiträge Access Tabellen & Abfragen: mit punkt rechnen? 6 networker + 697 15. März 2007, 13:29
networker + mit punkt rechnen?
Keine neuen Beiträge Access Tabellen & Abfragen: Relation 1:m zeigts nur als 1:1 an 2 Kusel 501 21. Feb 2007, 11:56
Kusel Relation 1:m zeigts nur als 1:1 an
Keine neuen Beiträge Access Tabellen & Abfragen: Aus Punkt mach Komma 1 Gast 694 09. Nov 2006, 14:52
steffen0815 Aus Punkt mach Komma
 

----> Diese Seite Freunden empfehlen <------ Impressum - Besuchen Sie auch: Microsoft Excel-Formeln