Office: (Office 2010) Kontrollkästchen in Abhängigkeit aktivieren/deaktivieren

Hallo,
Code:

das Jahr ist klar, aber wie kommt der 14.2. zu Stande, wie kommst Du auf den 14.02. ?
Und sind das immer 3 Jahre zurück ?

 

Ja das sind meine Formeln die so sein müssen. Es ist immer der Stichtag sozusagen der 14.02 und 3 Jahre im Vorrauss.

 

Hallo,
aber in Deiner PN war doch eine ganz andere Formel.
Da gibt es den 1.7. -3 Jahre, den 1.3. - 2 Jahre und dann noch Baubeginn -279.
Das ist doch offensichtlich von der Anmeldeart abhängig.

Solche verschachtelten Wenn Formalen sind immer ein Hinweis auf eine fehlende Tabelle. Hier fehlt einfach eine Tabelle für die Anmeldarten in der die Parameter (Tag und Monat) für DatSeriell abgelegt werden. Dann kannst Du ganz einfach in einer Abfrage alle Termine rechnen ohne das Wenn Gedöns.

Ich würde mal behaupten, in Deiner DB wäre 95% programmieren überflüssig, wenn man ein korrektes Datenmodell erstellt hätte.

 

Ja das stimmt, das Fälligkeitsdatum ist von der Anmeldeart abhängig deswegen die unterschiedlichen Formeln.
Aber diese Formel wird nur an einer Stelle einmal eingegeben, wo ist dann der Vorteil von der Tabelle. Den dort gebe ich ja auch einmal die Formel ein. Und ich hatte ja in meiner Version alles in 2 Tabellen drin. Das mache ich deshalb so, weil es kompliziert ist viele Tabellen zu erstellen wo dann bestimmte Felder von anderen Felder von anderen Tabellen abhängig sind und miteinander verbunden sind.

 

Hallo,

Du brauchst keine Wenn Verschachtelung mehr. Es wird eine Formel benötig, ohne Wenn, je nach Anmeldeart werden automatisch die richtigen Parameter verwendet.

aber das was Du jetzt machst, ist letztendlich viel komplizierter, weil Du das was bei richtigem Datenmodell automatisch, geht alles programmieren musst. Und unflexibel ist es obendrein, weil Datenänderungen immer eine Änderung aller Objektentwürfe erforderlich macht.
Stelle Dir mal vor, was Du für ein Aufwand hast, wenn mal eine Aufgabe dazukommt ?
Du musst alles ändern, Tabellen, Abfragen, Formulare, Berichte, Formeln einfach alles. Oder Du hast alles fertig und entdeckst einen Schreibfehler bei den Aufgaben, oder der Chef hätte gern einen anderen Text (Sag niemals nie).
Bei einem normalisierten Datenmodell ist das nur das Hinzufügen eines neuen DS in der Aufgabentabelle, fertig. Der Rest geht automatisch.

 

Ja das stimmt, dass wenn solche Änderung hinzukommen ein konkretes Datenmodell das ganze vereinfacht. Es war nur leichter Daten aus einer Tabelle miteinander zu kombinieren.

 

Zum Beispiel hatte ich ein Formlular in dem ich ein Projekt anlegen konnte. Das so so aus. Dort konnte ich den Name des projektleiters auswählen und die ganzen Angaben eintragen und das ganze Speichern und meine Angaben wurden in die Tabelle Projekte gespeichert. Jetzt geht es theoretisch fast genauso. Nur war bei mir die ID direkt der Name vom Projektleiter und jetzt ist die BesitzerID eine Nummer. Wenn ich also den Namen angezeigt bekommen will muss ich mein Formular irgendwie mit 2 Tabellen verknüpfen.

 

Hallo,

das ist ja auch richtig so. Textfelder taugen nur bedingt als Schlüsselfelder, daher nimmt man Zahlen. Und Verknüpfungen sind ja der Sinn von Datenbanken.
Du kannst auch ohne zu Verknüpfen den Namen anzeigen. Zur Auswahl des Namens hast Du ja ein Kombi. Über die Spaltenbreiten des Kombis kann man einstellen, was das Kombi anzeigt. Ein Kombi kann die Zahl speichern aber den Namen anzeigen. Das geht also mit der Zahl genau wie vorher auch, das ist nur eine Einstellungssache.

Datenherkunft für das Kombi: Abfrage mit den Namen
Spaltenreihenfolge in der Abfrage: Zahl, Name
Gebundene Spalte: 1
Steuerelementinhalt: Fremdschlüsselfeld
Spaltenbreiten: 0cm;5cm

Mit Spaltenbreite 0cm wird die 1.Spalte (die Zahl) unsichtbar und der Name ist zu sehen.

Wie bereits gesagt, Du denkst zu kompliziert, das ist alles viel einfacher als Du Dir es jetzt ausmalen kannst.

 

Hallo,
Nachtrag, es war zu spät um den Beitrag zu ändern:

Das oben beschrieben Verhalten eines Kombis kannst Du in meiner Beispieldb (#53) auf dem Formular "Erfassung" genau so wie oben beschrieben sehen. Im Kombi für den Besitzer ist der Name zu sehen, aber die ID wird gespeichert.

 

Das Problem ist nicht nur das einfache anzeigen der Namen statt der Zahlen sondern alles miteinander zu verknüpfen welcher Name dann zu welchen Projekt gehört. Die gesamten Verknüpfungen in der deiner Datenbank sind für mich nicht ganz leicht nachvollziehbar.

 

Hallo,

statt über die Namen geht es über die ID, das lässt sich doch ganz einfach nachvollziehen. Im Beziehungsbild ist das doch alles zu sehen.

Du bringst immer neue, nicht stichhaltige Argumente um die Umstrukturierung der DB zu vermeiden. Aber so wie das jetzt ist, ist das eine Sackgasse.

 

Nein nein ich will die Umstrukturierung nicht vermeiden ich versuche das ja alles mit der Struktur anzupassen. Um ein Projekt in einen Formular anzulegen habe ich jetzt wie früher ein beschreibbares Formular erstellt, wo ich den Namen und die Projektnummer und Umbaujahr eintragen kann. Und zusätzlich die Anmeldungsart auswählen kann. Und jetzt ist nur das Problem mit den namen für den Projektleiter. Ich lasse mir die ID anzeigen (BesitzerID) und wähle diese aus, und dann wird das Projekt wie gewünscht gespeichert. Das einzige Problem ist wie gesagt das ich nur die ID mir anzeigen lassen kann mit:
select besitzerID from Projekte

den Vorgang mit der zusätzlichen Abfrage für den Namen den du geschrieben hast versuche ich gerade noch zu.

 

Hallo,
Du verwendest auch Nachschlagefelder in Tabellen, die sind dort unbedingt zu vermeiden. Nur in Formularen (als Kombis) sind diese sinnvoll.
Die Einstellungen eines Kombis kannst Du exakt in meinem Beispiel nachvollziehen. Da braucht es keine zusätzliche Abfrage.

 

Bei dir steht aber Datenherkunft für das Kombi: Abfrage mit den Namen
So eine Abfrage habe ich nicht

 

Hallo,

was hindert Dich ein zu machen, musst doch nur sinngemäß abschreiben.

Übrigens, wenn Du ein Kombi mit dem Assi anlegst, wird das genau so eingestellt wie Du es brauchst, mit der Abfrage. Automatisch.