Microsoft Access - Starthilfe

Dieses Thema im Forum "Alles für den Einsteiger" wurde erstellt von Shiro Tagachi, 10.05.2015.

  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. AdMan

    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:
    25.891
    Zustimmungen:
    91
    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:
    25.891
    Zustimmungen:
    91
    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:
    25.891
    Zustimmungen:
    91
    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. AdMan

    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.
  11. #9 xandros, 14.05.2015
    xandros

    xandros IT Consultant, Cisco Registered Partner
    Moderator

    Dabei seit:
    05.07.2007
    Beiträge:
    25.891
    Zustimmungen:
    91
    Ort:
    Umkreis Duisburg, neben Mannheim, hinter Hamburg
    jep. Sieht gut aus.
     
  12. #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.
     
Thema:

Microsoft Access - Starthilfe

Die Seite wird geladen...

Microsoft Access - Starthilfe - Ähnliche Themen

  1. 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....
  2. 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...
  3. 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....
  4. Microsoft Office Word 2013 - Fehler bei Rändern

    Microsoft Office Word 2013 - Fehler bei Rändern: Hallo liebe Community, Wir haben hier bei uns im hause eine Mitarbeiterin, die ein merkwürdiges Problem mit Word 2013 hat. Jedes mal beim...
  5. Microsoft zieht Updates zurueck.

    Microsoft zieht Updates zurueck.: Microsoft hat am letzten Patchday ein Update ausgeliefert, welches auf diversen Systemen zu Abstuerzen gefuehrt hat. Allen Benutzern wird...