Microsoft Access - Starthilfe

Diskutiere Microsoft Access - Starthilfe im Alles für den Einsteiger Forum im Bereich Computerprobleme; Guten Morgen. Falls ich das im falschen Bereich poste, so bitte ich gleich mal um Entschuldigung, aber ich brauche Starthilfe in Microsoft Access...

  1. #1 Shiro Tagachi, 10.05.2015
    Shiro Tagachi

    Shiro Tagachi Neuer Benutzer

    Dabei seit:
    10.05.2015
    Beiträge:
    9
    Zustimmungen:
    0
    Guten Morgen. Falls ich das im falschen Bereich poste, so bitte ich gleich mal um Entschuldigung, aber ich brauche Starthilfe in Microsoft Access und hoffe, dass man mir hier weiterhelfen kann.

    Es ist so, dass in der Firma für die Lagerverwaltung nun EDV-mäßig was erstellt werden soll, und so wie es aussieht, soll ich das nun machen, also nicht nur umsetzen sondern auch "planen", und meine Access-Kenntnisse beschränken sich auf einen kleinen Kurs vor etwa 15 Jahren und ich habs inzwischen nicht mehr gebracht und bin somit mit dieser Aufgabe doch ein wenig überfordert. Aber ich denke, dass ich lediglich eine "Starthilfe" brauche, also wie ich das Ganze nun richtig beginne, und die weitere Umsetzung ergibt sich dann schon irgendwie.

    Also das Ganze soll in etwa folgendes beinhalten:
    Material
    - genaue Bezeichnungen und Details
    - wieviel ist der derzeitige Anfangsbestand
    - regelmäßige Entnahmen müssen eingetragen werden können (Person XY hat am XY-Datum so und so viele Stück/Meter/etc. von Produkt XY entnommen)
    - der Bestand muss dann somit automatisch mitgeändert werden, wenn jemand einen Entnahmeeintrag tätigt

    Es geht eben darum, dass man wirklich gleich sieht, von welchem Material noch wieviel da ist, wo man wann nachbestellen muss und somit einen guten Überblick hat, wie eben der derzeitige Stand ist.

    Könnte mir da vielleicht jemand ein wenig helfen, wieviele und welche Tabellen ich erstellen muss, dass diese Kriterien erfüllt werden können? Zumindest meines Gedankens nach reicht es ja nicht, da einfach alles in eine Tabelle zu packen, aber ich brauche hier eben einen kleinen "Schubs", wie hier das Ganze strukturiert sein soll bzw. welche Tabellen hier angelegt werden müssen, und ich glaub, danach pack ich das alleine.

    Auf jeden Fall dank ich schon mal, falls sich jemand da Gedanken machen will und mir somit ein wenig weiterhelfen kann.
     
  2. Anzeige

    schau mal hier: Windows-Wartungs-Tool. Viele Probleme lassen sich damit einfach beheben. Oftmals ist der PC dann auch schneller!
    Registrieren bzw. einloggen, um diese und auch andere Anzeigen zu deaktivieren.
  3. #2 xandros, 10.05.2015
    Zuletzt bearbeitet: 10.05.2015
    xandros

    xandros IT Consultant, Cisco Registered Partner
    Moderator

    Dabei seit:
    05.07.2007
    Beiträge:
    26.162
    Zustimmungen:
    116
    Ort:
    Umkreis Duisburg, neben Mannheim, hinter Hamburg
    Stammdaten in eine eigene Tabelle mit den Werten, die sich nicht ändern.
    Bewegungsdaten in eine separate Tabelle mit Fremdschlüssel auf den jeweils zugehörigen Datensatz der Stammdatentabelle.
    Hier eben Inventurbestand mit Buchungsdatum, Ein- und Ausgänge mit Datum/Mitarbeiter etc.
    Könnte z.B. so aussehen

    - Primary ID - Autowert
    - Foreign Key (Fremdschlüssel auf Artikelstammdatensatz)
    - Buchungstext, als Text (Inventur, Zugang, Abgang) - nach Belieben kann das auch via Fremdschlüssel auf eine eigene Tabelle gelöst werden, alternativ vielleicht sogar als Bitwert (lediglich Inventur oder Bestandsveränderung)
    - Menge (bei Inventur ist dies der Anfangsbestand, bei Zugängen positive Werte, bei Abgängen negative Werte; Die Summe dieser Werte ergibt dann den aktuellen Bestand)
    - Datum
    - MitarbeiterID

    Andere Informationen wie z.B. Lieferanten für einen Artikel inkl. Einkaufspreis, Lieferzeit, Lieferanten-ArtNr, ... gehören in eine eigene Tabelle.

    Im Prinzip: Alle Informationen notieren, die du zu einem Artikel speichern willst (OHNE berechnete Werte!), diese dann in logische Tabellen aufteilen -> dabei die Regeln der Datenbanknormalisierung befolgen und wenigstens bis zur dritten Normalform gehen.

    Nein, muss nicht! Wenn du den Anfangs-/Inventurbestand und die Zu- bzw. Abgänge hast, dann hast du auch den Bestand. Der Wert muss (und sollte) NICHT gespeichert werden, da er jederzeit per SQL aus den Tabellen neu berechnet werden kann. (Im Prinzip wird der neueste Inventurbestand ermittelt und ab diesem Zeitpunkt dann die Zu- und Abgänge kummuliert. Alle vorangehenden Bewegungsdaten können unberücksichtigt bleiben.)

    Das ist lediglich eine Frage der Anzeige. Die Werte stehen ja in den Tabellen und müssen nur für die Anzeige aufbereitet werden.
    Die Berechnung für den aktuellen Bestand ist an mehreren Stellen verwendbar und sollte daher als eigenständige Funktion je nach DB-Aufbau mit Formularen in einem eigenen Modul abgelegt werden. Darauf kann dann die Anzeige des aktuellen Bestandes, Inventurlistendruck und auch der Hinweis zum Nachbestellen/die Bestellvorschlagsliste zurückgreifen.
     
  4. #3 Shiro Tagachi, 10.05.2015
    Shiro Tagachi

    Shiro Tagachi Neuer Benutzer

    Dabei seit:
    10.05.2015
    Beiträge:
    9
    Zustimmungen:
    0
    Vielen Dank schon mal für deine Antwort. Bin zwar derzeit mit dieser noch stark überfordert, aber ich werd mich da dann wenns so weit ist reinhängen und mich durcharbeiten. Auf jeden Fall hoffe ich, dass ich da dann was zustande kriege.

    Also ich bin dir echt dankbar für deine Mühe mit der ausführlichen Antwort :)
     
  5. #4 xandros, 11.05.2015
    Zuletzt bearbeitet: 11.05.2015
    xandros

    xandros IT Consultant, Cisco Registered Partner
    Moderator

    Dabei seit:
    05.07.2007
    Beiträge:
    26.162
    Zustimmungen:
    116
    Ort:
    Umkreis Duisburg, neben Mannheim, hinter Hamburg
    Genau genommen ist es schon recht einfach, sich die passenden Tabellen zu basteln.
    Die einzige Herausforderung dabei ist, dass man hierbei eben auf das Thema Normalisierung eingeht.
    Was hierbei ein wenig Verständnis erfordert: Wann sind Daten normalisiert?

    Beispiel:
    Wenn du in einer Artikeltabelle folgende Werte speicherst

    tbl_Artikel
    0 Artikelnummer
    1 Artikelbezeichnung
    2 Lieferantenname
    3 Bestand
    4 Zugang
    5 Abgang
    6 Datum
    7 Mitarbeiter
    9 Verkaufspreis
    10 Einkaufspreis
    11- weitere Artikeleigenschaften (Größe, Gewicht, Farbe, Beschreibungen, whatever)

    dann sind darin Daten enthalten, die sich für diesen Artikel nicht verändern dürfen (z.B. die Artikelnummer) und Daten, die sich verändern können (z.B. Lieferantenname wenn das gleiche Produkt aus unterschiedlichen Quellen eingekauft werden kann, Verkaufs- und Einkaufspreis) und Daten, die sich verändern müssen (Bestand, Zugang, Abgang).
    Daneben finden sich auch wiederkehrende Daten (Lieferantenname, evtl. der Mitarbeitername für die letzte Änderung).
    Wenn alle diese Daten in einer einzigen Tabelle stehen, hast du verschiedene Probleme.
    Einmal kannst du lediglich einen Lieferanten für einen Artikel erfassen und auch nur von diesem Lieferanten den Preis. Ändert sich der Lieferant und/oder der Preis, kannst du anhand dieser Tabelle keine Informationen über andere Lieferanten oder frühere Einkaufspreise festhalten. (Alternativ müsste man bei jeder Änderung einen neuen Datensatz anlegen, in dem die unveränderten Werte erneut gespeichert werden. Das sollte jedoch vermieden werden!*)
    Es wird also eine History benötigt, aus der auch ehemalige Preise und Lieferanten ersichtlich werden.
    Bestand, Zugang und Abgang halten für die Bestandsveränderungen jeweils nur den letzten Wert fest und überschreiben immer den vorangegangenen Wert. (Ausnahme man schreibt jeweils einen neuen Datensatz je Änderung und produziert unnötigen Ballast.*)
    Auch hier wird irgendwann eine History notwendig, aus der die Einkäufe/Verkäufe zu einem späteren Zeitpunkt nachvollziehbar sind.
    Erster Schritt für die Aufteilung in Tabellen -> Stammdaten separat von Bewegungsdaten halten und beide Informationen über Schlüsselwerte miteinander verknüpfen.
    Aus der oben gezeigten Tabelle wird also

    tbl_Artikel
    0 pkArtikelID (Primärschlüssel)
    1 Artikelbezeichnung
    2- weitere Artikeleigenschaften (Größe, Gewicht, Farbe, whatever)

    tbl_ArtikelLieferant
    0 fkArtikelID (Primärschlüssel)
    1 fkLieferantID (Primärschlüssel/Fremdschlüssel auf tbl_Lieferant - pkLieferantID)
    2 Einkaufspreis

    tbl_Artikelbewegung
    0 pkID (Primärschlüssel)
    1 fkArtikelID (Fremdschlüssel auf tbl_Artikel - pkArtikelID)
    2 Bestand (yes/no) <- yes = Bestandswert, no = Zugang/Abgang
    3 Menge <- Bei Bestandswert = aktueller Inventurbestand, bei Zugang/Abgang positiv als Zugang, negativ als Abgang.
    4 Buchungsdatum
    5 fkMitarbeiterID (Fremdschlüssel auf tbl_Mitarbeiter - pkMitarbeiterID)

    tbl_Artikelpreis
    0 fkArtikelID (Primärschlüssel, Fremdschlüssel auf tbl_Artikel - pkArtikelID)
    1 Buchungsdatum (Primärschlüssel)
    2 Verkaufspreis

    tbl_Lieferant
    0 pkLieferantID (Primärschlüssel)
    1- ....

    tbl_Mitarbeiter
    0 pkMitarbeiterID (Primärschlüssel)
    1- ...

    Auf diese Weise hast du zwar eine Menge Tabellen und musst dir für bestimmte Informationen Abfragen über mehrere Tabellen basteln, dafür sind die enthaltenen Daten immer eindeutig und Wiederholungen von diversen Werten sind auf das Nötigste reduziert.
    Parallel sind Stammdaten und Bewegungsdaten getrennt und anhand des Datums jederzeit die aktuellsten Werte abrufbar. Zudem wird auch eine History bereitgestellt, damit man auch auf ehemalige Werte zurückgreifen könnte. (Was bei den Preisen durchaus interessant sein kann. Eine Preisänderung bei einem Lieferanten muss sich nicht zwangsläufig auf den Verkaufspreis der Artikel auswirken, die aktuell noch an Lager sind.
    Und wenn man eine Rechnung erzeugt, dann will man zu einem späteren Zeitpunkt sicherlich auf den zum Rechnungsdatum gültigen Verkaufspreis zurückgreifen wollen und nicht auf den aktuellsten Betrag.)
    Der aktuelle Bestand eines Artikels ergibt sich dann aus dem neuesten Bestandswert plus den danach erfolgten Zu/Abgängen. (Da Abgänge negative Zahlen sind, kann hier einfach eine Summe auf die Werte gezogen werden).


    Bei der Bezeichnung der Tabellenfelder darauf achten, dass Schlüsselworte von Access oder VBA vermieden werden! Bezeichnungen wie Name/Datum/Text werden wohl akzeptiert, verursachen jedoch zur Laufzeit mitunter ungewollte Verhaltensweisen.
    Daneben in allen Tabellen eine einheitliche Benamsung beibehalten. Wie diese aussieht, ist dir überlassen. Ich bevorzuge z.B. bei Schlüsselwerten die Präfix-Angaben "pk" für PrimaryKey und "fk" für ForeignKey. So erkennt jeder anhand der Feldbezeichnung, ob es sich um einen Primärschlüssel handelt oder bei Fremdschlüsseln umeinen Verweis auf einen Wert in einer anderen Tabelle.

    Das Beispiel oben ist als Denkanstoss gedacht und keinesfalls vollständig. Weitere Informationen zu einem Artikel lassen sich in verschiedenen Arten ergänzen oder ebenfalls auf weitere Tabellen verteilen. Ideal ist es, wenn anstelle von wiederholenden Texten in Tabelle a diese Texte in eine eigene Tabelle ausgelagert werden und nur die zugehörigen Primärschlüssel aus der eigenen Tabelle dann in Tabelle a gespeichert werden.
    Wie umfangreich man hier die Normalisierung betreibt, ist geschmackssache. Ich für meinen Teil bin bislang immer perfekt mit der driten bzw. vierten Normalform ausgekommen. Je atomarer man die Daten aufbaut, desto komplexer werden die Abfragen später. Ab der vierten Normalform muss man sich in relationalen Datenbanken schon überlegen, ob eine weitere Aufspaltung nicht auch Perfomanceeinbussen bei den Abfragen auslösen.... Eine Abfrage aus einem Join über zwei Tabellen ist noch überschaubar und schnell. Eine Abfrage aus fünf Joins (oder mehr) - teilweise mit Unterabfragen - über sechs (oder mehr) Tabellen ist nur schwer lesbar, selten anständig beim Debuggen verfolgbar und braucht Prozessorzeit.

    * unnötige Mehrfachspeicherung unbedingt vermeiden. Dadurch sprengt man relativ schnell die Maximalgröße für eine Tabelle durch Daten, die man gar nicht braucht.
     
  6. #5 Shiro Tagachi, 13.05.2015
    Zuletzt bearbeitet: 13.05.2015
    Shiro Tagachi

    Shiro Tagachi Neuer Benutzer

    Dabei seit:
    10.05.2015
    Beiträge:
    9
    Zustimmungen:
    0
    Wow! Vielen Dank! Ich sitz ja jetzt grad eben schon mal an dem "Ding" dran, staune wie sehr sich doch alles seit Office 97 verändert hat (^^) und hoffe mal dass ich irgendwie klar komme.

    Und ich bin eher grad ein wenig überfordert mit deiner Erklärung, selbst wenn ich dir total dankbar dafür bin. Aber Lieferanten und so brauchen wir gar nicht. Es geht echt einfach nur darum, eine Stammdatenbank zu haben mit all dem Kram, der sich im Lager befindet, man muss sehen können, wer wann wieviel von welchem Zeug entnommen hat und man sollte dann auch eben auf einen Blick sehen können, wovon noch wieviel da ist.

    Bislang bin ich mal so weit:

    Tabelle 1 - Material
    Nr (mit Primärschlüssel)
    Bezeichnung (für Artikelname)
    Einheit (Stück, Packung, Rolle, etc.)
    BestellNr. (damit man immer das selbe erwischt)
    Firma (damit man weiß wo mans her hat)
    Anmerkung (für eventuelle Notizen)

    Tabelle 2 - Bewegungen
    Nr (mit Primärschlüssel
    Entnahme/Zukauf (ob eben was rausgenommen oder ob aufgestockt worden ist)
    Menge (wieviel)
    Datum (wann es war)
    Mitarbeiter (wer es genommen hat)

    Aber nun bin ich grad ein wenig ratlos, zumal ich auch nicht weiß, was der von dir erwähnte "Foreign Key" ist bzw. wie ich das einstelle/einsetze oder wie das genau läuft.

    Also es ist sicher weniger als das worauf du bereits so ausführlich eingegangen bist, aber für mich ist es dennoch mehr als eine Herausforderung und ich wäre auch über ein paar weitere "Tipps für Dummies" (basierend auf meinen hoffentlich brauchbaren zwei Tabellen) wirklich dankbar :) Ist leider schon arg lang her, dass ich mal damit ein wenig zu tun hatte und ich hab so ziemlich alles vergessen. Dachte immer, dass ich das eh nie brauch. Na, so kann man sich irren ^^
     
  7. #6 xandros, 13.05.2015
    Zuletzt bearbeitet: 13.05.2015
    xandros

    xandros IT Consultant, Cisco Registered Partner
    Moderator

    Dabei seit:
    05.07.2007
    Beiträge:
    26.162
    Zustimmungen:
    116
    Ort:
    Umkreis Duisburg, neben Mannheim, hinter Hamburg
    Deine beiden Tabellen sehen für den Anfang doch schon recht gut aus.

    Jetzt greife ich mal den Begriff Datenbanknormalisierung auf, ueberspringe anhand deiner Tabellen gleich mal die erste und zweite Normalform und du bekommst z.B. eine Tabellenstruktur wie diese:

    Tabelle 1 - tblMaterial
    Nr (mit Primärschlüssel)
    Bezeichnung (für Artikelname)
    IDEinheit (ID aus Tabelle Einheiten) -> Einheit ...würde sich wiederholende Eingaben und ggfs. sogar Falscheingaben/Tippfehler bedeuten.
    BestellNr. (damit man immer das selbe erwischt)
    IDFirma (ID aus Tabelle Firma/Lieferant) -> Firma ...siehe Einheit!
    Anmerkung (für eventuelle Notizen)

    Tabelle 2 - tblBewegungen
    Nr (mit Primärschlüssel)
    IDMaterial <- Damit du auch weisst, von welchem Material hier eine Bewegung erfasst wird.
    Entnahme/Zukauf (ob eben was rausgenommen oder ob aufgestockt worden ist)
    Menge (wieviel) <- nicht als berechneter Wert! Sofern wie oben gezeigt als reiner Bestandswert für Inventur, ist das ok.
    Datum (wann es war)
    IDMitarbeiter (ID aus Tabelle Mitarbeiter) -> Mitarbeiter ...siehe Einheit

    Tabelle 3 - tblEinheiten
    Nr (Primärschlüssel)
    Bezeichnung (Stück, Kilo, Pack, Palette, ...)
    Diese Tabelle wird vorgefüllt mit ALLEN benötigten Einheitsbezeichnungen. Die zugehörige Nummer speichert man dann in der Tabelle Material anstelle der Bezeichnung und spart sich etliche Bytes pro Datensatz ein.

    Tabelle 4 - tblMitarbeiter
    Nr (Primärschlüssel)
    Vorname
    Nachname
    ...

    Tabelle 5 - tblFirma
    Nr (Primärschlüssel)
    Firmenname
    (Straße
    PLZ
    Ort
    ...)

    Und schon hast du über diverse Felder in der Tabelle Material eine Beziehung zu einem Datensatz in einer anderen Tabelle.
    Tabelle Material
    Feld IDEinheit -> Feld Nr aus Tabelle Einheiten
    Feld IDMitarbeiter -> Feld Nr aus Tabelle Mitarbeiter
    Feld IDFirma -> Feld Nr aus Tabelle Firma

    Kleiner Tipp: Verwende bei deinen Objekten innerhalb von Access Praefixe, an denen du erkennen kannst, um welche Art von Objekt es sich handelt!
    Beispiel aus meiner Praxis:
    Tabellen -> tbl... (tblArtikel, tblMitarbeiter, tblEinheiten, ...)
    Formulare -> frm... (frmMain, frmMitarbeiter, frmArtikel, frmMaterial, frmEinheiten, ...)
    Abfragen -> qry... (qryArtikelbestand, qryVerbrauch, ...)
    Berichte -> rpt... (rptArtikel, rptEinheiten, rptMitarbeiter, rptMaterial, ...)
    Module -> mod_... (mod_Feiertage, mod_Standard, ...)

    Sinn dahinter: Wenn du in einem Formular Material über eine Abfrage Material auf die Tabelle Material zugreifst, das Ergebnis dann an den Bericht Material übergeben willst, .... irgendwann weisst du selbst nicht mehr von welchem Material-Objekt du gerade schreibst.
    Greifst du stattdessen von frmMaterial über qryMaterial auf tblMaterial zu und übergibst das Ergebnis an rptMaterial, musst du nicht mal als Kommentar dabei schreiben, welche Objektbezeichnung nun für welches Objekt vorgesehen ist. Die Bezeichnungen sind eindeutig und selbsterklärend.

    innerhalb von Formularen und Berichten ebenso mit den Feldbezeichnungen umgehen.
    Ein Bezeichnungsfeld ist ein Label. Dafuer verwende ich als Praefix lbl
    Ein Textfeld erhält das Praefix txt, ein Auswahlfeld zum Aufklappen cbo (Combobox), eine Listbox lst, ein Button btn usw. Dann ist auch der Code für Aussenstehende erfassbar.
     
  8. #7 Shiro Tagachi, 14.05.2015
    Shiro Tagachi

    Shiro Tagachi Neuer Benutzer

    Dabei seit:
    10.05.2015
    Beiträge:
    9
    Zustimmungen:
    0
    Wow! Danke! Werd mich da heut noch damit beschäftigen und werde versuchen, deine Infos zu kapieren und umzusetzen. Auf jeden Fall danke für all deine Mühe, und ich meld mich dann wieder, wenn ich sicherlich dann wieder überfordert bin. Auf jeden Fall find ich es klasse, wieviel Zeit du dir hier nimmst mit Doofis wie mir...
     
  9. #8 Shiro Tagachi, 14.05.2015
    Shiro Tagachi

    Shiro Tagachi Neuer Benutzer

    Dabei seit:
    10.05.2015
    Beiträge:
    9
    Zustimmungen:
    0
    So, hab nun mal gewerkelt und auch das mit den Beziehungen gefunden. Hier mal kurz ein Screenshot (Firma hab ich bewusst nur als Text gelassen) mit der Bitte, mir zu sagen ob das mal so vom groben Drüberschauen her passt bzw. ob ich das richtig verstanden hab. Vielen Dank schon mal.

    [​IMG]
     
  10. #9 xandros, 14.05.2015
    xandros

    xandros IT Consultant, Cisco Registered Partner
    Moderator

    Dabei seit:
    05.07.2007
    Beiträge:
    26.162
    Zustimmungen:
    116
    Ort:
    Umkreis Duisburg, neben Mannheim, hinter Hamburg
    jep. Sieht gut aus.
     
  11. #10 Shiro Tagachi, 16.05.2015
    Shiro Tagachi

    Shiro Tagachi Neuer Benutzer

    Dabei seit:
    10.05.2015
    Beiträge:
    9
    Zustimmungen:
    0
    Ach, das freut mich :)

    Und "Entnahme/Zukauf" hab ich auf "Ja/Nein" und "Menge" auf Zahl. Und das heißt also, ich muss in der Materialtabelle mal alle Waren eingeben und ich muss sie auch alle in der Bewegungen-Tabelle eingeben, wo ich dann bei "Menge" den aktuellen Bestand reinschreibe, oder? Und wie genau läuft das nun mit dem "Ja/Nein"?

    Und wenn ich das dann mal soweit hab und Mitarbeiter XY was entnimmt, gebe ich das als nächste Zeile ein, und bei Menge schreib ich dann, wieviel entnommen wurde, oder? Bzw. wieviel zugekauft wurde. Aber wo genau seh ich dann den aktuellen Stand? Irgendwie blick ich da immer noch nicht ganz durch befürchte ich. Wäre da echt für weitere Hilfe dankbar.
     
  12. #11 xandros, 16.05.2015
    xandros

    xandros IT Consultant, Cisco Registered Partner
    Moderator

    Dabei seit:
    05.07.2007
    Beiträge:
    26.162
    Zustimmungen:
    116
    Ort:
    Umkreis Duisburg, neben Mannheim, hinter Hamburg
    Normalerweise baut man sich dafür ein Formular.
    In diesem Fall wäre das ein Formular für die Artikelstammdaten und ein weiteres für die Bewegungen.
    Das Formular für die Bewegungsdaten kann dann vom Artikelformular aufgerufen werden (OpenArgs können dabei verwendet werden die Datenbestände zu filtern) oder man fügt es gleich als Endlosformular in das Artikelformular ein.
    (Datensatzherkunft wäre dann eine SQL-Abfrage, die dann nur die Bewegungsdaten ausgibt, die zu dem in Hauptformular gewählten Datensatz gehören.)
     
  13. #12 Shiro Tagachi, 16.05.2015
    Zuletzt bearbeitet: 16.05.2015
    Shiro Tagachi

    Shiro Tagachi Neuer Benutzer

    Dabei seit:
    10.05.2015
    Beiträge:
    9
    Zustimmungen:
    0
    Muss es mit Formular sein? Mir wär ehrlich gesagt die Tabelle an sich lieber und von der Funktionsweise sollte es keinen Unterschied machen, oder? Formular ist ja nur grafisch ein wenig aufbereitet bzw. sowas kann man auch später machen, oder? Mir persönlich gefällt die Tabelle besser... nur ist mir leider nicht ganz klar, wie ich das hier eintrage bzw. wie das Ja/Nein nun verwendet wird und wo ich dann genau den aktuellen Stand des Materials ablesen kann. In der Tabelle selbst seh ich dann ja die einzelnen Bewegungen (was ja auch wichtig ist), aber muss ich dann für den Stand an sich, wo eine extra Berechnung (ähnlich wie es im Excel möglich wäre... quasi Anfangsbestand +/- Ankauf/Entnahmen) erstellen?

    Edit:
    Nochmals ich. Ich wurde von einem Freund auf eine Nordwind-Datenbank verwiesen, die für sowas recht gut sein soll zum Nachschauen. Wo findet man diese bei Access 2010?
     
  14. #13 xandros, 17.05.2015
    Zuletzt bearbeitet: 17.05.2015
    xandros

    xandros IT Consultant, Cisco Registered Partner
    Moderator

    Dabei seit:
    05.07.2007
    Beiträge:
    26.162
    Zustimmungen:
    116
    Ort:
    Umkreis Duisburg, neben Mannheim, hinter Hamburg
    Es ist dir solange lieber, bis du feststellst, dass du mit Schlüsselwerten Datensätze falsch miteinnander verknüpfst, bis deine Eingaben kontrolliert werden sollen/müssen, bis die Tabellenfelder Aktionen auslösen sollen, bis du Code benötigst um Funktionalität zu ergänzen. Das alles geht in Tabellen nicht.


    Tabellen haben keinerlei Möglichkeit für:
    - Eingabekontrolle
    - Plausibilitätsprüfung
    - Fehlerbehandlung
    - Diverse Steuerelemente sind in Tabellen gar nicht verfügbar.

    In einem Formular kann man genau darauf Einfluss nehmen und/oder Aktionen auslösen.

    Ich schreibe auch schon mal Daten direkt in Tabellen. Hier bietet sich dafür z.B. die Tabelle Einheit an, in der die Bezugseinheiten erfasst werden.
    Da werden auch nur die Bezeichnungen eingetragen und fortlaufend eine ID ergänzt. (Entweder als Autowert direkt von Access oder manuell - ist in diesem Fall noch relativ Wurscht, solange die Werte eindeutig sind.)
    Aber bei anderen Tabellen wird das kaum dauerhaft funktionieren. Und sinnvoll ist es auch nicht, schliesslich soll ja irgendwo auch der aktuelle Artikelbestand angezeigt werden. Das ist ein berechneter Wert, den man sich aus den Tabellendaten errechnet, aber nicht speichert. Eine Tabelle kann das nicht darstellen.

    Wenn du Access vollständig installiert hast, dann ist auch die Nordwind/Northwind auf dem Rechner vorhanden. Ab Office 2007 hat sie als Dateiendung .accdb und sollte über den Explorer zu finden sein.

    Anbei noch ein Link zu Karl Donaubauer: www.donkarl.com
    Die Access-FAQ ist ein schönes Nachschlagewerk zu oft auftauchenden Fragen und Stolpersteinen, auf die man als Entwickler unter Access mit Sicherheit stossen wird.
     
  15. #14 Shiro Tagachi, 17.05.2015
    Shiro Tagachi

    Shiro Tagachi Neuer Benutzer

    Dabei seit:
    10.05.2015
    Beiträge:
    9
    Zustimmungen:
    0
    Vielen Dank nochmals für deine Rückmeldung! Und Nordwind seh ich zwar, aber wenn ich es aktivieren will, krieg ich eine Fehlermeldung, dass was fehlt. Und so ungern ich es auch zugebe, aber ich glaub, die Sache mit Access überfordert mich einfach, und ich werde doch eher auf Excel zurückgreifen und hoffen, dass die Firma damit zufrieden ist, zumal ich mich dort immerhin mit Formeln und dergleichen auskenne und auf jeden Fall zustande kriege, was ich haben will. Ich hab nicht mehr die Zeit zum langen Herumprobieren und muss da wohl nun echt aufgeben.

    Aber nochmals danke für all deine Mühe mit mir, für all die guten Tipps, auch wenn ich wohl leider zu doof bin, sie alle wirklich zu kapieren, um sie tatsächlich umsetzen zu können. Und mit Excel kann ich eine Übersichtsseite machen, wo man alles schön berechnet sieht, das man haben will, und damit bin ich einfach schneller, weil ich nicht herumprobieren muss.

    Also Daumen hoch für die nette und tolle Unterstützung in diesem Forum! Danke!
     
  16. #15 xandros, 17.05.2015
    xandros

    xandros IT Consultant, Cisco Registered Partner
    Moderator

    Dabei seit:
    05.07.2007
    Beiträge:
    26.162
    Zustimmungen:
    116
    Ort:
    Umkreis Duisburg, neben Mannheim, hinter Hamburg
    Eine Exceltabelle ist da sicherlich schneller realisiert als eine Access-Anwendung.
    Das ist auch mit ein Grund dafür, dass Access weit weniger verbreitet ist.
    Es dauert Vielen einfach zu lange, um damit etwas Brauchbares aufzubauen und von Tabellenkalkulation auf Datenbank umzudenken.
    Die Zeit muss man sich nehmen (können), damit Access ein nützliches und leistungsfähiges Tool wird.
     
  17. Anzeige

    Es ist generell erstmal empfehlenswert alle ggf. veralteten oder fehlerhaften Treiber zu scannen und auf neue zu aktualisieren. Hier kannst du einen Treiber-Scanner downloaden. Das erspart oftmals viel Ärger und hilft gegen diverse Probleme.
    Registrieren bzw. einloggen, um diese und auch andere Anzeigen zu deaktivieren.
  18. #16 Shiro Tagachi, 17.05.2015
    Shiro Tagachi

    Shiro Tagachi Neuer Benutzer

    Dabei seit:
    10.05.2015
    Beiträge:
    9
    Zustimmungen:
    0
    Ja, glaub ich gern. Und ich hatte gehofft, dass ich besser damit klar komme, aber das war definitiv ein Irrtum. Aber ich hab in Excel bereits was gebastelt und das wird hoffentlich so passen, damit ich es dann weiter ausführen kann. Dachte immer, in Access kann man auch Berechnungen ähnlich wie in Excel realisieren, aber das ist wohl nicht ganz so einfach.
     
  19. #17 xandros, 19.05.2015
    xandros

    xandros IT Consultant, Cisco Registered Partner
    Moderator

    Dabei seit:
    05.07.2007
    Beiträge:
    26.162
    Zustimmungen:
    116
    Ort:
    Umkreis Duisburg, neben Mannheim, hinter Hamburg
    In Access kann man Berechnungen realisieren. Sogar weit komplexer als in Excel. Nur eben nicht wie in Excel....
    Die Anforderungen an Tabellenkalkulation und Datenbank sind auch völlig verschieden.
     
Thema:

Microsoft Access - Starthilfe

Die Seite wird geladen...

Microsoft Access - Starthilfe - Ähnliche Themen

  1. Wo kann ich eine Microsoft Office Lizenz günstig und risikofrei kaufen?

    Wo kann ich eine Microsoft Office Lizenz günstig und risikofrei kaufen?: Hallo! Seit längerer Zeit nutze ich auf meinem Rechner OpenOffice als Büroanwendung. Damit bin ich aber nicht mehr ganz zufrieden, weil es öfters...
  2. Kaufberatung Access Point

    Kaufberatung Access Point: Hallo, ich bin auf der Suche nach einem geeigneten Access Point welcher auch noch gleichzeitig als Switch genutzt werden kann, da mein Router...
  3. MSM und Microsoft HoloLens bringen das holografische Einkaufserlebnis

    MSM und Microsoft HoloLens bringen das holografische Einkaufserlebnis: In Kooperation mit einer Werbeagentur für den stationären Handel (MSM) bringt Microsoft ein holografisches Einkaufserlebnis in den Handel....
  4. Internet Explorer Problem bei Microsoft-Websites

    Internet Explorer Problem bei Microsoft-Websites: Hallo liebe Modernboard-Gemeinde, Ich habe ein echt interessantes Problem, bei dem ich am Ende von meinem Latein bin. Per Internet-Explorer kann...
  5. Einrichten eines Access-Points

    Einrichten eines Access-Points: Hallo, (gleich vorweg, ich besitze nur Grundkenntnisse) ich bräuchte am besten eine genaue Anleitung, um einen Access Point einzurichten....