November 27, 2020, 06:22:00

Neuigkeiten:

Ist euer Problem gelöst, dann bitte den Knopf "Thema gelöst" drücken!


Gültigkeitsregeln

Begonnen von ChrisKr, November 18, 2020, 19:53:33

⏪ vorheriges - nächstes ⏩

ChrisKr

Hallo zsm.

ich habe in einer Tabelle 9 Checkboxen dazu 9 Datumsfelder.
Wenn di Checkbos wahr ist soll ein Datum eingetragen werden. Folgende Formel habe ich erstellt.

(([chkLocIEApproved]=Wahr) Und ([datILocIEApprovedDate] Ist Nicht Null) Oder (([chkLocIEApproved]=Falsch) Und ([datILocIEApprovedDate] Ist Null)) Oder (([chkGBSApproved]=Wahr) Und ([datGBSApprovedDate] Ist Nicht Null)) Oder (([chkGBSApproved]=Falsch) Und ([datGBSApprovedDate] Ist Null)) ....

das habe ich halt für jede checkbox eingegeben. Aber Access prüft immer nur die letzte Regel, oder gar keine. Was mache ich falsch. Oder kann Access mit so vielen Regeln nicht umgehen? (Vielleicht ähnlich wie bei Excel mit der Wenn-dann-sonst-funktion. Excel kann da ja auch nur 7 Verschachtelungen) Benutze 2016er Version.

Ich hoffe jemand hat eine Idee. Hab im www und im Access-Buch nichts gefunden,

Grüße und Danke vorab.

MzKlMu

Hallo,
es sind ja im wesentlichen die gleichen Funktionen. Auch Access hat die Grenze bei 7 Verschachtelungen.
Aber, wenn bei Access solche Wenn Orgien notwendig sind, ist der Aufbau grundsätzlich falsch.
Hier fehlt noch eine Tabelle in der die 9 (oder weniger) Zustände als je ein Datensatz gespeichert werden.

Bitte erkläre mal den Sinn der Checkboxen genauer. Aber bitte mit deutschen Feld/Box Namen, sonst muss ich so viel nachschlagen.

Löse Dich von dem Gedanken hier einen Excel Aufbau anlegen zu wollen. Access Tabellen sind mit Exceltabellen nicht vergleichbar.
Gruß
Klaus

ChrisKr

Hi,
danke schon mal für die Antwort. Ich will eine Datenbank erstellen die Kundenanfragen zu Verträgen bearbeitet.
Tabelle Kundenanfrage (Anfrage Kundenzuordnung)
Tabelle Vertragsart (Es gibt ca 15 verschiedene Verträge)
Tabelle Serviceart (Es gibt drei Servicearten. Jeder Vertrag kann in entsprechendem Service (vom Kundenwunsch abhängig) angegliedert sein.)
Tabelle Zu Genehmigende Abteilungen (je nach Serviceart 4 - 10 Abteilungen involviert)
Tabelle Mitarbeiterzuordnung zu Abteilung
Tabelle Genehmigungsprozess (Datentabelle der Genehmigungsboxen) Wir bekommen von den einzelnen Abteilungen per email das OK für den Vertrag. Diese soll in der DB zukünftig von der Abteilung angetickt werden.
Tabelle Vertragsbausteine (Je nach Anfrage wird der Vertrag am Ende, wenn alle geforderten Abteilungen ihr OK gegeben haben,  mit den entsprechenden Bausteinen per Makro zusammengesetzt und Versand)
Tabelle e-Mail Empfänger (Vertragsempfänger)

Nach deinen Infos sollte ich eine Tabelle machen wo die Abteilung enthalten ist eine Spalte für die Checkbox und eine für das Datum. Und diese Verbinde ich dann per stellvertretendem Schlüssel an die Tabelle Kundenanfrage. Richtig?

Danke für die Hilfe vorab.

MzKlMu

November 19, 2020, 14:35:38 #3 Letzte Bearbeitung: November 19, 2020, 14:39:53 von MzKlMu
Hallo,
Zitat von: undefinedDiese soll in der DB zukünftig von der Abteilung angetickt werden.
Was verstehst Du unter angetickt ?

Die Zusammenhänge mit den Ja/Nein Feldern habe ich auch nicht ganz verstanden.
Muss jede Abteilung Ihr OK geben ?
In der Von mir vorgeschlagenen Tabelle braucht es keine Checkbox mehr. Die Abteilung mit Dateum wird nur eingetragen wenn das OK vorliegt.
Zitat von: undefinedmit den entsprechenden Bausteinen per Makro zusammengesetzt und Versand)
Wieso Makro ?
Zu Access Makros wirst Du keine Hilfe bekommen.

Kannst Du mal ein Bild des Beziehungsfensters zeigen ?
Gruß
Klaus

Beaker s.a.

Hallo,
ZitatTabelle Genehmigungsprozess (Datentabelle der Genehmigungsboxen) Wir bekommen von den einzelnen Abteilungen per email das OK für den Vertrag. Diese soll in der DB zukünftig von der Abteilung angetickt werden.
Hier verbergen sich vermutlich die Checkboxen.
Wie Klaus schon schrieb, muss diese Tabelle die Neun als Datensätze enthalten.
Über eine n:m-Tabelle werden diese dann mit den Verträgen bzw. wohl erst Anfragen
in Beziehung gesetzt. Das "Antickern" geschieht dann über ein Listenfeld, das eben
diese neun DS (oder auch jeweils nur noch die, die noch nicht angetickert sind) an-
zeigt/zur Auswahl stellt, und eine Anfügeabfrage an die n:m.

gruss ekkehard
--
Beaker s.a., der lieber an seinem eigenen Projekt arbeiten würde/sollte, aber irgendwie immer gerne seinen Senf dazu gibt ;-)
S.M.I².L.E.

ChrisKr

Zwei Dinge vorab. Ich bin seit gestern hier angemeldet. Bin neu hier und mit Access nur in der Anwendung Vertraut. Habe kaum großartig Tabellen gemacht. An den Beziehungen lässt sich sicher noch was verfeinern. Habe mir das Buch Access 2019 gekauft und soll für den Job was erstellen.

Wie man hier Dateien hochlädt erschließt sich mir noch nicht.

Ziel ist es eine Datenbank zu erstellen in der Vertragsanfragen von Neukunden abgearbeitet werden können. Es gibt 20 verschiedene Verträge. 12 Davon werden von 10 Abteilungen geprüft und diese Müssen ihr OK geben bevor wir das finale GO geben und der Vertrag erstellt wird. 6 Verträge müssen von 8 Abteilungen genehmigt werden. 4 Verträge von 4 Abteilungen.
Die maximale Anzahl an Abteilungen ist zehn. ich habe das alles in mehrere Tabellen gesplittet um doppelte Einträge so wenig wie möglich zu haben. Die Tabelle Service wie oben beschrieben hab ich nur erstellt damit ich nicht 184 gleichnamige Verträge je Abteilung Anlegen muss.
Bisher bekommen wir das OK aller Abteilungen per email.

Vielleicht ist das kompliziert erklärt. Wenn mir jemand zeigt wie ich Daten hochladen kann tue ich das gerne. Mit den Symbolen in der leiste scheint es nicht zu gehen.

Grüße

MzKlMu

Hallo,
im Antwortfenster weiter unten gibt es die Zeile "Attachments and other options"
Dort kann man ein Datei anhängen. Vorher in Acccess komprimieren und reparieren und dann gezippt hier hochladen.
Gruß
Klaus

ChrisKr

Ah, ich verstehe. Ich war im Schnellantwortfenster. Gar nicht so leicht hier mit dem zurechtfinden. Suche ständig die Anmelden-Seite oder irgendwelche Antwortfunktionene. Hier sind jetzt auch Smileys. ;D

Ich werde jetzt erst mal schlafen. Schick euch alles morgen. Danke schonmal für den guten Willen und die Hilfe.
Grüße

ChrisKr

Es lässt mir keine Ruhe. :-)

Ich habe die Datei mal mit angehangen. Wie gesagt, bin mir noch nicht sicher das ich das Beziehungssystem verinnerlicht habe. Die Approvedboxen habe ich rausgeschmissen. Datum reicht.

Ich versuche eigentlich mit stellvertretenden Schlüsseln zu arbeiten. Hoffe das die Beziehungen das so auch erkennen lassen. Habe noch keine Beispieldaten integriert.

Bin für jede Hilfe Dankbar.

Grüße

MzKlMu

Hallo,
entweder Du "deutschst" auch Dein Beispiel ein, oder Du musst warten bis jemand antwortet der mehr Englisch kann.
Ich bin nicht in der Lage aus den englischen Feldnamen und Tabellennamen Zusammenhänge zu erkennen. Ich bin demzufolge auch nicht in der Lage das Datenmodell zu überblicken bzw. zu prüfen.
Gruß
Klaus

Beaker s.a.

Hallo,
@klaus
So ganz blicke ich auch nicht durch, aber vielleicht bekommen wir
das ja zusammen hin.
Die falsch aufgebaute Tabelle ist die "tblREQAproveDates" (hier
jetzt Datumsfelder statt Boolean, was m.E. eh besser ist).

@Chris
Mein Vorschlag soweit ich durchblicke zur Diskussion s. Anlage.
Anmerkungen: Die letzten fünf Felder in "tblREQContractRequest" kommen
aus deiner "tblREQApproveDates". Anlage-/Refuse- & Canceldatum sind
m.E. direkte Eigenschaften des Requests und keine Approvals in dem Sinne.
Die Beziehung zwischen "tblREQContractNumberToService" und "tblREQContractRequest"
habe ich umgedreht, weil der Request n.m.V. eine Eigenschaft des Contracts
ist und nicht umgekehrt, - ist ja schliesslich die Basis für einen Contract.
Was auf jeden Fall noch geklärt werden muss ist die "CustomerID", eine Tabelle
ist ja nicht zu sehen. Muss das zwingend ein Text sein? Eine ID (LongInteger)
wäre auch hier besser. Ob das deshalb jetzt so richtig ist, wie ich es gemacht
habe (siehe Beziehungsfenster ganz oben), musst du selber entscheiden.

gruss ekkehard

P.S.: Präfixes bei Tabellenfeldern sind so nützlich wie ein Kropf. Von mir
angelegte Felder deshalb ohne.
--
Beaker s.a., der lieber an seinem eigenen Projekt arbeiten würde/sollte, aber irgendwie immer gerne seinen Senf dazu gibt ;-)
S.M.I².L.E.

ChrisKr

Hallo Zusammen,

danke für die Hilfe und den vollen Einsatz. Bei so vielen Tabellen ist das umdeutschen schon ein wenig Aufwand. Danke das es auch so ging. Es scheint in die richtige Richtung zu gehen. Ich probiere es mal aus und meld mich wieder.

Vielen Dank vorab.
mfg
Chris.

Beaker s.a.

November 23, 2020, 17:52:50 #12 Letzte Bearbeitung: November 23, 2020, 18:24:26 von Beaker s.a.
Hallo Klaus,
Der TS hat mich per PN um tel. Hilfe gebeten. Wie hier üblich musste ich das
ablehnen. Habe ihm aber natürlich die Hilfe hier im Forum angeboten.
Mein Vorschlag des DM kommt mir nicht ganz koscher vor. Würdest du, trotz
Problemen mit englisch (da könnte der TS und ich dann helfen) mal drüber
schauen.
Einen Fehler habe ich gerade entdeckt. Die Beziehung "tblREQEmployeeDepartment" zu
"tblREQContractRequest" ist falsch. Auf alle Fälle muss die Beziehung auf "DepartmentOfRefuse"
gehen. Bin aber nicht sicher ob man dann auf der rechten Seite den FK "intDepartmentID_F" oder
"intID" nimmt. Ich denke letzteren, weil man dann den jetzt noch fehlenden MA *) auch
gleich hat.
*) Eine Tabelle "Employees" (MA) müsste auf jeden Fall dazu. Habe ich völlig übersehen.
@ChrisKr
Da gehören die Namen und sonstigen Eigenschaften (kann ich nicht erkennen) der MA hinein,
und in "tblREQEmployeeDepartment" nur ein FK auf den MA. Erst dann macht oben gesagtes
Sinn; - diese Tabelle ist dann eine n:m zwischen MA und Department. Das Feld "txtDepartmentName"
kannst du löschen; - der Name ergibt sich aus dem FK.
Ich würde ja noch weiter drüber nachdenken, bin aber diese Woche kaum noch Gelegenheit.
Vielleicht hat Klaus ja Lust den Fall zu "übernehmen". Wie ich Klaus kenne, aber auch nur hier
im Forum. Falls er zu mehr bereit ist wird dich wissen lassen.

gruss ekkehard
--
Beaker s.a., der lieber an seinem eigenen Projekt arbeiten würde/sollte, aber irgendwie immer gerne seinen Senf dazu gibt ;-)
S.M.I².L.E.