Probleme mit dem Datentyp “Datum/Uhrzeit erweitert”

Der Felddatentyp “Datum/Uhrzeit erweitert” wurde mit Access 2021 beziehungsweise mit Access aus Office 365 eingeführt. Er speichert genau wie der Datentyp “Datum/Uhrzeit” Datums- und Zeitangaben. Allerdings hat er eine höhere Genauigkeit und Uhrzeiten können nun auch Bruchteile von Sekunden enthalten. Der Grund für die Einführung ist die Herstellung von Kompatibilität mit dem SQL Server, der den Datentyp “datetime2” enthält. Wenn wir Tabellenverknüpfungen zu den Tabellen einer SQL Server-Datenbank herstellen, werden Felder des Typs “datetime2” automatisch mit dem neuen Access-Datentyp “Datum/Uhrzeit erweitert” übersetzt. Allerdings bringt das diverse Probleme mit sich. Zum Beispiel können die in Access eingebauten Datumsfunktionen nicht richtig mit diesem Datentyp umgehen. Was das im Detail bedeutet und welche Lösungsmöglichkeiten es gibt, erläutern wir in diesem Beitrag.

Weiterlesen

Datenmodelle für die Rechnungsverwaltung, Teil 2

Im ersten Teil dieser Beitragsreihe haben wir die grundlegenden Ideen vorgestellt, die wir zum Thema Bestellungen/Rechnungen/Lieferungen haben. Uns ist jedoch noch eine Feinheit entgangen, die wir in diesem Beitrag noch nachreichen wollen. Dabei geht es darum, eventuelle Inkonsistenzen beim Erstellen von Rechnungspositionen auf Basis von Bestellpositionen zu vermeiden. Normalerweise sollte mit dem aktuellen Datenmodell nichts schiefgehen, aber das Datenmodell sollte so viele Probleme wie möglich bereits durch die enthaltenen Restriktionen in Form von Beziehungen verhindern.

Weiterlesen

Standardwerte für Fremdschlüsselfelder pflegen

Für Felder in Tabellen kann man jeweils einen Standardwert im Tabellenentwurf festlegen, der beim Anlegen eines neuen Datensatzes in dieser Tabelle vorbelegt wird. Etwas anspruchsvoller ist es, wenn wir Standardwerte durch den Benutzer festlegen wollen. Noch einen Schritt weiter gehen wir, wenn der Standardwert für ein Fremdschlüsselfeld verwendet werden soll – also zur Auswahl eines Datensatzes aus einer verknüpften Tabelle. Einfache Beispiele sind Anreden, Zahlungsmethoden, Prioritäten oder Kategorien. Hier können wir jeweils einen Eintrag anwendungsweit festlegen. Es geht aber auch noch anspruchsvoller: Wenn wir beispielsweise Adressen für Kunden in einer eigenen Tabelle speichern, wo mehrere Adressen je Kunde angelegt werden können und nur eine als Standard verwendet werden soll. Spätestens hier müssen wir auch beim Datenmodell umdenken. In diesem Beitrag schauen wir uns erst einmal an, wie wir Standardwerte für Nachschlagefelder komfortabel auswählen können.

Weiterlesen

Standardzuordnung per Datenmakro

Während wir den Beitrag “1:n-Beziehung mit Standardzuordnung verwalten” (www.access-im-unternehmen.de/1469) schrieben, haben wir uns gefragt, ob man die Einhaltung der Konstistenz bei 1:n-Beziehungen mit Standardzuordnung nicht auch auf andere Weise sicherstellen kann als per VBA-Code. Zumal wir diesen auch noch in allen Formularen erneut programmieren müssten, welche die Daten aus dieser 1:n-Beziehung darstellen. Uns fielen zwei Lösungsansätze ein: Der erste sind die mit Access 2010 eingeführten Datenmakros, also eine Art Trigger für Access-Datenbanken. Die zweite sind die echten Trigger, und zwar die vom SQL Serve. In diesem Beitrag schauen wir uns nun die Variante mit den Datenmakros an. Kann man unser Vorhaben damit abbilden? Und wenn ja, wie?

Weiterlesen

Datenmodelle für die Rechnungsverwaltung

Beim Schreiben von Anwendungen, mit denen Rechnungen erstellt werden sollen, stellt sich immer wieder die Frage nach dem korrekten Datenmodell. Davon ausgehend, dass es nicht das perfekte Datenmodell für alle Anwendungsfälle gibt, wollen wir in diesem Beitrag einmal unterschiedliche Ansätze betrachten und diskutieren. Diese haben eines gemein: Die Anwendung mit diesem Datenmodell soll die Möglichkeit bieten, sowohl Bestellungen zu erfassen als auch Rechnungen und Lieferscheinen zu erstellen. Wie welche Daten gespeichert werden und welche Möglichkeiten es gibt, schauen wir uns nun an.

Weiterlesen

Benutzerdefinierte Standardwerte

Standardwerte für Felder legt in der Regel der Entwickler beim Definieren des Datenmodells in der Entwurfsansicht der Tabellen fest. Während man in bestimmten Maßen dynamische Werte nutzen kann wie beispielsweise mit der Datum()-Funktion für Datumsfelder, ist man ansonsten recht unflexibel. Leider lassen sich dort nur einige eingebaute Funktionen nutzen, wir können keine benutzerdefinierten VBA-Funktionen einsetzen. Aber welche benutzerdefinierten Standardwerte wollen wir überhaupt nutzen – und wo wollen wir diese festlegen? Die Einsatzzwecke sind vielfältig und prinzipiell können wir jedes Feld mit einem benutzerdefinierten Standardwert nutzen. Wichtig ist der Gedanke dahinter: Sinnvoll gewählte Standardwerte sparen dem Benutzer wertvolle Zeit bei der Dateneingabe. Wenn wir zum Beispiel eine Datenbank planen, die überwiegend weibliche Kontakte verwaltet, ist es sinnvoll, als Anrede “Frau” vorzugeben. Oder wir haben eine Autowerkstatt, die hauptsächlich Fahrzeuge einer bestimmten Marke repariert – dann macht es Sinn, diese vorzubelegen. Wir können auch dynamisch den zuletzt verwendeten Eintrag als Standardwert angeben oder auch den meistgenutzen. Wie wir dies realisieren, zeigen wir im vorliegenden Beitrag.

Weiterlesen

1:n-Beziehung mit Standardzuordnung verwalten

Im Beitrag “Rechnungsverwaltung: Kundenadressen ausgliedern” (www.access-im-unternehmen.de/1470) verwalten wir zu jedem Kunden mehrere Adressen, die dem Kunden über ein Fremdschlüsselfeld in der Adresstabelle zugewiesen sind. Für jeden Kunden legen wir in dieser Tabelle eine Standardadresse fest. Damit ist einiger Pflegeaufwand verbunden, denn wir müssen sicherstellen, dass immer genau eine Adresse je Kunde als Standardadresse markiert ist. In diesem Beitrag schauen wir uns an, wie wir sicherstellen können, dass die Daten immer konsistent sind und wir nicht plötzlich mehrere Standardadressen je Kunde vorfinden – oder gar keine.

Weiterlesen

Ungebundene Listen und Kombis mit Daten füllen

Im Beitrag “Daten in ungebundenen Formularen bearbeiten” haben wir gezeigt, wie man die Daten einer Tabelle in einem ungebundenen Formular darstellt und dieses zum Bearbeiten und Anlegen von Datensätzen verwendet. Wenn wir dies konsequent umsetzen wollen, benötigen wir auch eine Möglichkeit, um Daten in Listenform anzuzeigen. Die Datenblatt- oder Endlosansicht fallen aus, also müssen wir uns um Alternativen kümmern. Für die mehrspaltige Listenansicht bietet Access das Listenfeld. Und für die Auswahl von Daten aus Lookup-Tabellen steht das Kombinationsfeld zur Verfügung. Beide sind jedoch, wie auch Formulare, für die Bindung an Tabellen oder Abfragen optimiert. Ungebundene Daten müssen wir dort erst einmal einpflegen. Auf welche Arten das gelingt, zeigt dieser Beitrag.

Weiterlesen

Datenbanken automatisch komprimieren

In vielen Datenbankanwendungen fallen temporäre Daten an, also Daten, die in Tabellen geschrieben und in der gleichen Session wieder gelöscht werden. Das kann in nicht aufgeteilten Datenbanken der Fall sein, aber auch in aufgeteilten Datenbanken mit Frontend und Backend geschehen. Man könnte denken, die Größe der Datenbankdatei würde nach dem Anfügen und Löschen von Daten einigermaßen konstant sein. Das ist jedoch nicht der Fall: Gelöschte Daten sind zwar nicht mehr in den Tabellen zu finden, allerdings benötigt die Datenbank anschließend ungefähr genauso viel Speicherplatz wie vor dem Löschen. Wie das zu erklären ist und wie wir durch die Komprimierung einer Datenbank dennoch dafür sorgen können, dass eine Datenbank sich durch die Verwendung temporärer Daten nicht allzusehr aufbläht, beschreiben wir in diesem Beitrag.

Weiterlesen

Sperrung durch Memofeld statt anderer Sitzung

Neulich bat mich ein Kunde, mir einmal ein Netzwerkproblem beim ihm anzusehen. Aufgrund der Fehlermeldung konnte es keine andere Ursache geben – sie lautete “Aktualisieren nicht möglich, momentane Sperrung durch eine andere Sitzung auf diesem Rechner”. Also haben wir uns diese Sache gemeinsam angesehen und zunächst schien die Meldung plausibel – immerhin arbeitete eine andere Mitarbeiterin gerade mit der Datenbank und es konnte gut sein, dass der Datensatz gesperrt war. Allerdings trat das Problem später immer noch auf, obwohl niemand sonst mehr mit der Datenbank arbeitete. Gemeinsam sind wir dem Problem dann auf die Schliche gekommen. Die Überschrift deutet es bereits an: Ein Memofeld spielte eine große Rolle bei der Lösung des Problems.

Weiterlesen