Hallo Zusammen,
ich versuche mich aktuell an einer kleinen Datenbank in Access.
Den aktuellen Benutzer lese ich mit Hilfe einer Funktion aus, jedoch stehe ich vor folgendem Problem:
Ich möchte das in einer Tabelle beim Start der Datenbank der aktuelle Benutzer eingetragen wird, jedoch nur, wenn dieser nicht bereits in der Tabelle enthalten ist.
Kann mir hier vielleicht einer einen Tip geben, wie ich dieses löse?
Vielen Dank im Voraus
René
Moin,
Meine Empfehlung: Mit der Frage zu https://www.ms-office-forum.net/forum/forumdisplay.php?f=60 umziehen, dort gibt es Experten, Code-Beispiele und vieles mehr, was hier nicht geht.
Gruß
Ralf
vielen Dank Ralf - ich werd dann mal mit der Frage umziehen 
Grundsätzlich startest Du keine Datenbank. Ich gehe mal davon aus, Du meinst die Anwendung. Auch wenn das in Access Recht vermischt wird, solltest Du das strikt auseinanderhalten. Dann ergeben sich so einige Fragen erst gar nicht.
Wie auch immer … deine Anwendung startet ja. Vermutlich öffnet sich automatisch ein Formular. In diesen Formular erstellt Du das Ereignis „Form_Load()“ in diesem kannst Du dann den Aufruf deiner Funktion packen.
Für „mehr“ musst Du den Aufbau deiner Tabelle(n) nennen.
Hallo lfm001,
vielen Dank für Deine Antwort.
Ich muss gestehen ich bin bei Access ein absoluter noob.
Das hier ist meine erste richtige DB, bzw der Versuch
Zuerst, danke für das einnorden des Wordings, werde mich dran gewöhnen
Dann zu meiner DB.
Ich habe eine Datenbank aufgesetzt, wo mehrere Nutzer Lieferantenfehler über ein Formular eintragen.
Der aktuelle Nutzer und das aktuelle Datum wird mit in den Datensatz geschrieben.
Soweit so gut.
Jetzt möchten wir die Daten ja auch auswerten können. Um hier mehr Komfort zu bekommen, hatte ich die Idee, dass eine weitere Tabelle vorhanden sein sollte, wo alle in Frage kommenden Nutzer (die haben das Formular ja dafür mind einmal geöffnet) festgehalten werden. Aus dieser Tabelle kann dann ein DorpDown feld zugreifen, um den gewünschten Nutzer auszuwählen.
Meine Idee war es, beim Öffnen den Nutzer (den ich ja über eine Funktion sowieso auslese) direkt in diese Tabelle schreibe. Allerdings ohne Doublette und ohne Fehlermeldung bei Doublette.
Die Tabelle mit den Nutzern besteht nur aus dem Primärschlüssel (ID) und dem Nutzer.
Ich hoffe die Info reicht um mir hier den Schubs zu geben, den ich brauche um das hinzubekommen…
Vorab solltest Du erstmal klären, ob das Ganze von datenschutzrechtlicher Seite überhaupt implementiert werden sollte.
Ansonsten brauchst Du nicht unbedingt eine separate Tabelle. Die DropDown-Liste kannst Du mit „SELECT DISTINCT MyUser FROM LieferantenFehler ORDER BY 1“ füllen. Das „DISTINCT“ sorgt dafür, dass es keine Dubletten gibt. Ist zwar nicht besonders performant, aber wenn die Tabelle nicht sonstwie gross ist, sollte es schnell genug sein.
Also ich denke dass es Datenschutzrechtlich passen dürfte - Bei der aktuellen Weise hat unser DSB nichts dagegen und wir arbeiten noch mit Excelsheets die hin- und hergeschickt werden…
Naja klein ist die Tabelle nicht gerade aber ich denke für ne Datenbank ist das nichts.
Wie ich schon schrieb bin ich in Access ein absoluter newbee - trage ich das in den Eigenschaften der Abfrage (bei der Auswertung) in das Feld „Nutzer“?
Sorry, wenn ich ggfs nicht direkt folgen kann…
Dann solltest du Access sofort zur Seite legen und mit MySQL, MongoDB o.ä. anfangen. Programmieren lernt man auch nicht, indem man erstmal mit GW-Basic übt.
Warum nicht mal bei DuckDuckGo „mysql getting started“ eingeben und schauen, was sich da ergibt?
Vorab: Verwende bitte die Antworten und/oderZitier-Funktion des Forums. Dann hätte ich eher von deiner Rückfrage erfahren.
In den Eigenschaft des DropDown-Feldes in der Datensatzherkunft. Mit einem Klick auf „…“ kommst in den Abfrage-Assistenten.
Die Eigenschaft „Herkunftstyp“ muss auf „Tabelle/Abfrage“ stehen. Wenn nicht, funktioniert o. g. nicht.
Das DISTINCT wird im Abfrage-Assistenten erreicht, wenn die dortige Eigenschaft „keine Duplikate“ auf „Ja“ gestellt wird.
… oder Du gibt das SQL-Statement von Hand ein.
Und ich dachte immer, dass es auf das Anwendungs-Szenario ankommt, so dass solch eine pauschale Aussage auf Basis der wenigen bekannten Eckdaten gar nicht sinnvoll ist.
Bei Access nicht.
Es lebe das Vorurteil.
Es ging hier ganz eindeutig darum:
Und das ist nun mal das Gegenteil von Access.
Und das weißt du auch selber.
Wenn jemand mit RDBMS-Background mit Access arbeiten muss und dabei den Begriff „Datenbank“ vorgesetzt bekommt, ist es kein Vorurteil mehr.
Sondern Tatsache.
Access ist eine richtige DB ist und erfüllt alle Kriterien eines RDBMS.
Es ist halt eine Desktop-Datenbank mit allen Vor- und Nachteilen. In diesem Segment ist Access seit Jahren ungeschlagen … und das sage ich, obwohl ich von Microsoft nicht mehr viel halte.
Ich wiederum kann eine Empfehlung für mySQL nicht verstehen. Seit der Übernahme durch Oracle halte ich den Fork MariaDB für sinniger.
Ich werde hier aber nicht weiter an einer Meta-Diskussion teilnehmen, wer welche individuellen Kriterien für „richtig“ heranzieht. Am Ende gibt es nur ein „Richtig“ … es wird ein für den Zweck passendes Tool verwendet. Und ohne Hintergrundinfos zu dem Projekt-Eckdaten Mal eben pauschal vom Tool abzuraten ist schlicht nicht zielführend.