Office: (Office 2003) Neu-Erstellung Datenbank- sinnvolle Aufteilung einer importierten Excel-Tabelle

Hallo Bernd

Habe für den Reifen 1 das Historienformular inklusive Laufleistungen der einzelnen Reifen-Popup integriert. Hurra*grins *grins
Siehe angehangene DB.

Habe allerdings festgestellt, daß, siehe K-TL 5073, Historie 1, Laufleistungen einzelne Reifen die Laufleistung beim Reifen 100001 immer 140.000 km bleibt, egal was beim Datensatz vom 10.04.2007 an Montagekm eingetragen wird.

Rechnet die Laufleistung nicht von 40.000 bis 140.000 km = 100.000 km

Kann aber denke ich mal, trotzdem schon mal die anderen 6 Historien anlegen.
Wenn du Zeit haben solltest, könntest du es dir vielleicht ja mal anschauen.

Vielen Dank schon mal

Bis dann

Mario

 

Hallo Mario,

in allen 3 Fällen JA. Alles muss am Ende achtmal da sein.

Vielleicht noch eine Bemerkung zum Historienformular. Möglicherweise kriegst du das mit dem Kopieren und Umfrisieren inzwischen hin, denn du hast ja jetzt gerade durch deine letzten Aktionen schon einiges gelernt. Versuch es also einfach noch mal.

Ich habe probehalber in deiner neuen DB die Schaltfläche und das Historienformular für Rad 1 erstellt und das klappte problemlos. Du kannst also insofern sicher sein, dass der "Untergrund" in der DB stimmt und es nicht deshalb nicht klappt, weil ein Feld vergessen worden wäre, eine Abfrage nicht richtig funktioniert etc. Das ist ja auch schon mal beruhigend.

Aber wo könnte dann evtl. der Hase noch im Pfeffer liegen? Weiß ich natürlich auch nicht, doch nachfolgend ein paar Tipps um das Risiko zu mindern.

a) benenne im kopierten Historienformular als erstes die Datenherkunft des Formulars um (also von qry_LL2 zu qry_LL1). Dadurch sind auch alle Einser-Felder in der Feldliste drin.

b) nimm dir dann die einzelnen Felder vor. Natürlich könntest du - z. B. - bei dem Feld Dim2_A2 einfach sowohl in der Zeile Steuerelementinhalt wie auch in der Zeile Name aus den Zweien jeweils Einsen machen. Sicherer ist aber, dass du in der Zeile Steuerelementinhalt rechts auf die Pfeiltaste klickst und dann ja die Auswahl aller Felder siehst (das ist nichts anderes als die Feldliste, die ja nun mit den "richtigen" Feldern erscheint, weil du Pkt. a) ausgeführt hast.
In der Liste klickst du das Feld Dim1_A1 an und kopierst dann den Inhalt der Zeile Steuerelementinhalt in die Zeile Name. Auf den ersten Blick erscheint das umständlich, doch dafür hast du die absolute Gewissheit, dass das Feld auch tatsachlich in der zugrundeliegenden Abfrage vorhanden ist (und bei den vielen Feldern, die du nachgetragen hat, könntest du ja mal ein vergessen haben.)

c) nun musst du ja noch den Code ändern. Im Grunde gehst du einfach in die Codeansicht und änderst in allen Prozeduren bei den entsprechenden Feldern die Zweien in Einsen um.

d) Bei dieser Gelegenheit kannst du noch den Code der Demo-Msgbox löschen (Prozedur "Private Sub ReifenNrAlt2_GotFocus()")
Am besten machst du das als allererstes im Historienformular2 und kopierst das dann erst siebenmal ...

e) bei einer Prozedur ist es nicht damit getan, dass du die Zweien gegen die Einsen austauscht. Es geht um die Prozedur "Private Sub ReifenNrNeu2_AfterUpdate()" (ist ja direkt unter der, die du löschen kannst).
Der Grund dafür ist, dass du den Prozedurkopf, also genau den, den ich gerade hier aufgelistet habe: "Private Sub ReifenNrNeu2_AfterUpdate()" nicht handschriftlich ändern darfst.
Du doppelklickst also im Historienformular1 beim Feld ReifenNrNeu1 einfach noch einmal in in die Zeile Beim Klicken rein (da steht ja schon "Ereignisprozedur" drin) und gelangst damit wieder in den Code-Editor der dir nun aber eine leere Prozedur Private Sub ReifenNrNeu1_AfterUpdate() anzeigt. Dahinein kopierst du den Inhalt der Prozedur Private Sub ReifenNrNeu2_AfterUpdate() und änderst dann noch im Codetext wie gewohnt die Zweien in Einsen. Danach kannst du die Prozedur Sub ReifenNrNeu2_AfterUpdate() löschen.

Wenn du diese Tipps beherzigst, sollte es auch mit den Historienformularen klappen.

Weiterhin gutes Gelingen.

Bernd

Oh, da haben sich jetzt unsere Antworten gekreuzt. Achte aber mindestens auf Pkt. e)

 

Na Logo. Das stimmt ja auch hinten und vorne nicht. Du kannst nicht im Nachhinein noch "Geschichtsklitterung" *grins vornehmen.

- wenn am 10.04. der Reifen 100001 neu montiert wird, dann gehört er in das Feld ReifenNeu und nicht ins Feld ReifenAlt!!! Und dann hat er natürlich MontageKM = 100.000 und LL = 0. Ins Feld ReifenAlt hört dann eine andere ReifenNr (12345), nämlich die, die von Anfang an drauf war. Im blauen Formular hat diese Nr. 12345 natürlich eine LL von 100.000

- oder es ist der allererste Reifen, dann hört er ins Feld ReifenAlt, hat dann aber MontageKM = 0 und eine LL = 100.000. Und in diesem Falle hat er auch richtigerweise im blauen Formular am 20.04. eine LL = 140.000, weil er da vom neuen Reifen 1000010 abgelöst wird.
Und es ist ihm völlig schnuppe, ob böse Geschichtsfälscher wie du da irgendwelche MontageKM austauschen, weil er sich (siehe die entsprechenden Abfragen) nicht nach den MontageKM, sondern ausschließlich nach dem KM-Stand richtet).

- stünde am 10.04. die ReifenNr 100001 tatsächlich in ReifenAlt und hätte MontageKM = 40.000, dann müsste es, um zu einer richtigen Berechnung zu kommen, noch mind. einen Datensatz vor dem 10.04. geben, sagen wir mal 20.03., bei dem gäbe es den KM-Stand = 40.000, in ReifenAlt die Nr. 12345 und in ReifenNeu die Nr. 100001 (und dort dann erstmalig MontageKM = 40.000).
Dann würde im blauen Formular Nr. 12345 von 0 - 40.000 berechnet, also LL = 20.03 /40.000 und Nr. 100001 hätte am 20.04. eine LL =100.000).

Aber nun einfach mal versuchsweise die MontageKM am 10.04. von 40.000 in eine andere Zahl ändern bringt nur dann richtige Ergebnisse im blauen Formular, wenn du in dem Datum davor (20.03.) einen andern KM-Stand einträgst.

Alles klar? *tongue.gif*

Durch die Einführung des neuen Feldes ReifenNrNeu werden vermutlich auch die Zahlen bei den anderen Rädern nicht stimmen.
Im Historienformular2 müsste z.B. in der Zeile 10.04. bei MontageKM = 100.000 stehen und LL = 0

Um es wirklich sauber zu prüfen, erstelle ein neues Kennzeichen und gib dort, Datum für Datum die Zahlen von Rad1 / K-TL 5073 ein. Und das von mir aus mit den oben aufgezeigten drei Alternativen.

Bernd

 

Hallo Bernd

Geschichtsklitterung ?? - guter Ausdruck.

Bekenne mich teilweise schuldiig.*grins *grins
Habe, da ich nach Anlegen der Historie 1 die Sache überprüfen wollte,
festgestellt, das da was nicht stimmt mit dem ersten Datensatz.
Habe dann, um zu probieren, etwas eingetragen bei Montage-Km und das Ergebnis im blauen Formular vorher und nachher kontrolliert.
Es war das gleiche. ( siehe mein Beitrag)

Wollte damit nicht sagen, das deine Spitzenprogrammierung schlecht sei, hatte eher vermutet, das durch mein Kopieren etwas schiefgelaufen ist.

Bin jetzt bei Historienschaltfläche 5.
Muß Punkt e) auch noch überall durchführen.
Wenn ich die restlichen gemacht habe, lege ich wie von dir vorgeschlagen mal ein neues Fahrzeug an mit allen 8 Positionen.
Dann schauen wir mal, was passiert.

Melde mich dann wieder.
Danke für die Rückantwort.

Bis dann

Mario

 

Hallo Mario,

*Smilie Nein, das hatte ich so auch gar nicht aufgefasst. Der springende Punkt ist wirklich das neue Feld ReifenNrNeu. Du hattest ja die Testzahlen aller Reifen vorher eingegeben und zwar so, dass die MontageKM erst beim zweiten Check eingetragen wurden, weil bei Installation des neuen Reifens noch letztmalig die MontageKM des alten Reifens ausgewiesen wurden. Dann haben wir das durch die Einführung des neuen Feldes quasi umgeschmissen aber nur beim Reifen 2 hatte ich die Zahlen den neuen Gegebenheiten angepasst, weil ja sonst die Copy-Taste nicht funktioniert hätte.

Und erst, nachdem die drei Abfragen für das kleine blaue Formular im Anfang noch ein falsches Ergebnis lieferten, habe ich mir die Situation so richtig durchdacht und bin auch darauf gekommen, dass man besser den KM-Stand zum rechnen nimmt und nicht die MontageKM.

Jetzt bist du beim Reifen1 praktisch in die selbe Falle getappt wie ich zuerst auch. Also, zwei Doofe, ein Gedanke. *tongue.gif* Und nun konnte ich natürlich den Schlaumeier rauslassen, obwohl ich zunächst genau den selben gedanklichen Fehler gemacht hatte. Aber das verrate ich dir natürlich nicht. *grins

Bernd

 

Hallo Bernd

Kann es sein, daß du dich hier vertan hast?

e) bei einer Prozedur ist es nicht damit getan, dass du die Zweien gegen die Einsen austauscht. Es geht um die Prozedur "Private Sub ReifenNrNeu2_AfterUpdate()" (ist ja direkt unter der, die du löschen kannst).
Der Grund dafür ist, dass du den Prozedurkopf, also genau den, den ich gerade hier aufgelistet habe: "Private Sub ReifenNrNeu2_AfterUpdate()" nicht handschriftlich ändern darfst.
Du doppelklickst also im Historienformular1 beim Feld ReifenNrNeu1 einfach noch einmal in in die Zeile Beim Klicken rein (da steht ja schon "Ereignisprozedur" drin) und gelangst damit wieder in den Code-Editor der dir nun aber eine leere Prozedur Private Sub ReifenNrNeu1_AfterUpdate() anzeigt. Dahinein kopierst du den Inhalt der Prozedur Private Sub ReifenNrNeu2_AfterUpdate() und änderst dann noch im Codetext wie gewohnt die Zweien in Einsen. Danach kannst du die Prozedur Sub ReifenNrNeu2_AfterUpdate() löschen.

Das ist nicht vorhanden?

Du meinst sicherlich in die Zeile Nach Aktualisierung

Dort steht schon Ereignisprozedur drin.
Wenn ich auf die 3 kleinen Pünktchen klicke, dann wird eine leere Prozedur am Ende unter

Err_Formular_schließen_Click:
MsgBox Err.Description
Resume Exit_Formular_schließen_Click

End Sub

angefügt.
Und dort kopiere ich dann die Prozedur vom Reifen 2

Private Sub ReifenNrNeu2_AfterUpdate()
DoCmd.RunCommand acCmdSaveRecord

If Me.ReifenNrNeu2 > 0 Then
Me.MontageKM2 = Me.KMStand
DoCmd.RunCommand acCmdSaveRecord
End If
End Sub

hinein und ändere die 2en dann in 1en, 3en , 4en usw.

Ist das so korrekt, oder muß die Prozedur in der vorigen Reihenfolge unter

Private Sub btnLLalt_Click()
DoCmd.OpenForm "frm_LLAlterReifen1"
End Sub



einfügen?

Danke für die Rückantwort

Mario

 

Hallo Mario,

ja, da hast du recht. Vielleicht sollte ich nachts um 2:21 nichts mehr schreiben. *frown.gif*

Die (b) sind nur unvollständige Formatierungszeichen für Fettschrift, bei denen das schließende (/b) fehlte.

Aber entscheidend ist, dass das Ereignis tatsächlich nicht Beim Klicken, sondern Nach Aktualisierung heißt (eben AfterUpdate).

Was wichtig ist, am Ende darf die neue Prozedur NICHT so aussehen:

Private Sub ReifenNrNeu1_AfterUpdate()
Private Sub ReifenNrNeu2_AfterUpdate()
DoCmd.RunCommand acCmdSaveRecord

If Me.ReifenNrNeu2 > 0 Then
Me.MontageKM2 = Me.KMStand
DoCmd.RunCommand acCmdSaveRecord
End If
End Sub
End Sub

weil du die komplette alte Prozedur in die neue reinkopiert hättest. Die beiden blauen Zeilen müssen raus, bzw. von vornherein gar nicht erst reinkopiert werden!!

Tut mir leid, dass ich dich verwirrt habe.

Bernd

 

Hallo Bernd

Hast mich nicht verwirrt.
Wollte nur sicher gehen, daß ich nichts falsch mache.

Wie schaut es mit der Positionierung des Codes aus?

Kann es ruhig ans Ende, wo es sich selber hinschreibt?

Mario

 

Hallo Mario,

die Positionierung ist egal, die Prozeduren ordnen sich dann sowieso von selber ein, gewissermaßen alfabetisch. Wenn du den Code-Editor einmal schließt und wieder öffnest, kann die Prozedur vom Ende zu irgendeiner Position inmitten der anderen gewandert sein.

Allerdings, wenn du über das Eigenschaftenfenster eine ganz neue Prozedur anlegst und die sich von selbst ans Ende schreibt, dann hört sie von der Sortierung her auch dort schon hin.

Bernd

 

Hallo Bernd

Habe das Formular fertig gestellt. Hurra*grins *grins *grins

Habe ein neues Kennzeichen K-TL 5045 angelegt.
Datensätze 25 - 27.
Klappt alles prima von Reifen 1-8.

Das einzige, was noch nicht auf die anderen Felder übertragen wurde, ist deine Spezialprogrammierung für die Anzeige Montagekm und LL ( weiß auf weiß, wenn ... usw)

Habe es mit dem Pinsel Format übertragen versucht - klappt aber nicht.

Vielleicht kannst du mir dein Geheimnis noch verraten, so daß ich es vielleicht selber hinbekomme.

Wenn es zu kompliziert ist, wäre es nett, wenn du es einbauen könntest.

So, dann wäre es ja fast so weit, an anderer Stelle der DB weiterzumachen.
Ich versuche mal, bevor Berichte erstellt werden, Abfragen zu erstellen, um den Gesamtpreis a) Material x Menge
b) Pannenleistungen x Menge
C) Reparaturen x Menge

sprich die 3 Register im frm_AUFTRAEGE abzufragen.

Diese Werte müßte ich dann ins Register Finanzen integrieren.

Bin auf jeden Fall mit dem jetzigen Stand happy.*grins *grins

Habe die aktuelle DB hochgeladen

Gute Nacht

Mario

 

Hallo Mario,

habe zwar nur ganz kurz mal in die neue DB geschaut und nix geprüft, doch sieht das jetzt schon prächtig aus - du kannst stolz auf dich sein!! *top

Was die Sache der Anzeige von MontageKM und LL im sfrm_Raeder angeht, so funktioniert das - allerdings nur bei Reifen 2 -, denn der Code bezieht sich bisher nur auf diesen Reifen (Ereignis Beim Anzeigen des Formulars sfrm_Raeder).

Diese Päckken If ... End If müsstest du jetzt auch noch siebenmal kopieren, innerhalb der selben Prozedur, und dann wieder aus den Zweien Einsen, Dreien, Vieren usw. machen.

Bevor du das aber tust, überlege mal, ob diese Anweisungen überhaupt noch Sinn machen???

Früher, lang, lang ist´s her *grins , wurde bei MontageKM und LL nur etwas eingetragen, wenn ein neuer Reifen montiert wurde, sonst nicht. Und nur dann sollten die Inhalte der beiden Felder angezeigt werden; bei Reparaturchecks ohne Reifenwechsel sollte keine Anzeige erfolgen.

Daher die Regel:
• wenn MontageKM nichts (Null) oder eine 0 enthält, mach die Schriftfarbe von MontageKM und LL weiß,
• ansonsten mach sie schwarz.

Nunmehr, durch die Automatisierungen im Historienformular etc., wird aber nahezu immer etwas in MontageKM angezeigt und somit bleibt natürlich auch die Schrift schwarz. M. E. müsste der Code jetzt dahingehend abgewandelt werden, dass da steht:
• wenn ReifenNrNeu einen Eintrag enthält, mach die Schriftfarbe von MontageKM und LL schwarz
• ansonsten mach die Schriftfarbe von MontageKM und LL weiß

Siehst du das auch so?


Was die Abfragen angeht, so steck ich da momentan noch nicht so drin. Aber versuch es doch ruhig mal erst mit den Abfragen. Selbst wenn sie hinterher nicht gebraucht werden sollten, kannst du die berechneten Felder dann an anderer Stelle einsetzen.

Vorschlag
- mach das mal erst mit den Abfragen
- lade dann nochmal die neue DB hoch
- beantworte bei der Gelegenheit meine Frage zu MontageKM etc
- beschreibe vor allem genau, was du im Register Finanzen vorhast, im Sinne von "Diese Werte müßte ich dann ins Register Finanzen integrieren"

Wie ich schon sagte, bei mir ist es diese Woche zeitlich knapp. Ich bin gleich wieder weg und kann dir vermutlich erst morgen (Samstagmittag) antworten.

Bernd

 

Hallo Bernd

Zu dem Punkt: Kannst stolz sein - Bin ich auch. Aber gebührt uns beiden.

Zu dem Punkt: Anzeige vonMontagekm und LL.

Hast recht - war einmal.
Können ruhig alle angezeigt werden.

Habe den Code entfernt

Private Sub Form_Current()
If IsNull(Me.MontageKM2) Or Me.MontageKM2 = 0 Then
Me.LL2.ForeColor = vbWhite
Me.MontageKM2.ForeColor = vbWhite
Else
Me.LL2.ForeColor = vbBlack
Me.MontageKM2.ForeColor = vbBlack
End If

End Sub

Hoffe, daß das so richtig war.

Zu den Abfragen.

Habe folgende Abfragen erstellt:

qry_Pannenpreis
qry_PannenpreisSumme

qry_Materialpreis
qry_MaterialpreisSumme

qry_Reparaturpreis
qry_ReparaturpreisSumme

Dann habe ich noch die Abfrage:

qry_GesamtAuftragsSumme

erstellt.

Dabei habe ich allerdings das Problem, das nur der Datensatz 10 angezeigt wird, da er der einzige ist, bei dem in allen 3 Kategorien etwas steht.
Die anderen Datensätze werden nicht angezeigt, da sie in mindestens einer der 3 Kategorien Nullwerte enthalten.

Ich wollte eigentlich aus allen 3 GesamtNettopreisen zu jedem Auftrag eine AuftragsGesamtNettoSumme errechnen lassen per Abfrage.

Die 3 einzelnen GesamtNetto (GesamtNettoMat - GesamtNettoPanne - GesamtNettoRep) wollte ich dann unter anderem in das Register Finanzen einfügen.

Aus den 3 GesamtNetto Preisen soll sich dann der AuftragsGesamtNettoPreis
errechnen.

Kann man zwar wahrscheinlich auch in dem Register selbst ausrechnen lassen, hatte aber noch im Kopf, das man sowas in Abfragen errechnen lassen soll, damit man es nicht immer in anderen Formularen wiederholen muß.

Kannst du es Dir vielleicht mal anschauen?

Zu den anderen Feldern im Register Finanzen:

Feld : Materialpreis soll aus dem Feld GesamtNettoMat bestehen
Dienstleistungen soll aus dem Feld GesamtNettoRep bestehen
GesamtNettoPanne fehlt noch, auch in der Grundtabelle.

Lieferant soll man aus dem Nachschlagefeld auswählen oder, wenn noch nicht vorhanden, anlegen können ( Stichwort - Not In List).
Bekäme ich hin, hätte dann aber wieder, wie bei den anderen Registern auch das Problem mit der Aktualisierung.
Angelegter Artikel, Reparatur, Pannenleistung, Kennzeichen, EPID ist erst nach Schleißen und Neuöffnen des Formulars drin.

Rechnungsnummer - Gutschriftnummer und Vergölst Rechnung Nr wird händisch eingetragen.

Bei KK (Karkasse) wird die Menge händisch eingetragen.

Das Feld EPID (Einzelpreis-ID) für Karkasse soll auch wieder aus dem Nachschlagefeld ausgewählt oder angelegt werden können.

Aus der EPID mal KK-Menge soll sich dann die Gutschriftsmenge in Euro errechnen.
Das Feld fehlt noch.

Bei dem Feld EPID tritt zeitweise ein Kuriosum auf.
Mal wird z.Bsp. 5 € angezeigt, das nächste Mal auf einmal 5,000.00€

Weiß nicht wieso.
Formatierung scheint ok zu sein.

Die Abfragen, die ich erstellt habe, wollte ich für die 3 Felder zugrunde legen.
Vielleicht ein bischen zu kompliziert gedacht?

Im Formularfuß des Registers Finanzen ( Register muß wahrscheinlich komplett neu erstellt werden) soll sich dann aus den 3 GesamtNettoX eine AuftragsGesamtNetto errechnen.

Daraus dann natürlich die MWST(19%) und AuftragsGesamtBrutto

Ich habe die aktuelle DB mit hochgeladen.
Probiere zwischenzeitlich selber auch noch parallel ein wenig herum für das Register Finanzen.

Oh je, habe wahrscheinlich wieder den Rekord für lange Beiträge gebrochen.*grins *grins

Bis dann - Danke

Mario

 

Hallo Bernd

Kann ich meine Meinung vom vorigen Beitrag noch ändern.

Hast recht - war einmal.
Können ruhig alle angezeigt werden.


Mir ist nämlich eingefallen, warum wir das zuerst so gemacht hatten.
Der erste Reifencheck wird ja meistens nicht von 0 km erfasst.
Meist hat das Fahrzeug schon mehrere 100.000 km gelaufen.
Und nicht alle Reifen werden beim ersten Fahrzeug-Kontakt(Einmessung der Reifen) erneuert.

Damit da dann nicht Laufleistung Reifen = 688.000 km steht, sollte die Laufleistung und MontageKM erst bei Erneuerung eines Reifens erscheinen.

Da wäre vielleicht dein Vorschlag, daß an das Feld ReifenNrNeu1 - 8 zu kopplen, nicht verkehrt. Für das Formular Reifeneingaben wäre das optimal.

Ich denke, das dafür die Formatierung der Historienformulare und der blauen Popups ebenfalls geändert werden müßten.
Eine korrekte Aussage über die Laufleistung eines Reifens kann ja eigentlich erst getroffen werden, wenn man den Montagekm-Stand hat und den DeMontagekm-Stand.

Jetzt im Moment werden ja alle Laufleistungen der erfassten Reifen (egal ob neu oder mittendrin alt erfasst) angezeigt in allen Formularen.
Wäre schön, wenn man das ändern könnte.

Ich weiß nur nicht wie das dann in dem Historienformular und dem Popup aussähe.

z.Bsp: K -TL 5045 Datensatz 30 (neu angefügte DB)

Dort wurde der Reifen 2 am 05/01/2008 bei km 399.788 ersetzt.
In dem Fall passiert bei den nächsten 2 Einmessungen an dem Reifen nichts ( wird nicht erneuert) - Dementsprechend natürlich kein Eintrag bei ReifenNrNeu.
Das würde ja dann denke ich mal bedeuten, das dort die wünschenswerte Anzeige des Montage-KM Standes und der bisherigen Laufleistung mit der neuen Formatierung auch nicht angezeigt würden, sondern erst wieder, wenn ein neuer Reifen montiert wird.

Oder kann man beides mit einer Super-Duper-Spezielformatierung kombinieren???
so nach dem Muster.

Zeige MontageKm und LL erst nach der ersten Neureifennr an, danach aber kontinuierlich, auch wenn im Feld ReifenNrNeu die nächsten Datensätze nichts mehr passiert, außer das die mm-Angaben korrigiert werden und mit der Copy-Taste die Werte (ReifenNrAlt und ProfilAlt) vom vorigen Mal übernommen werden.
Und in dem PopUp - Zeige Laufleistung nur für die ReifenNr an, die einmal im Feld ReifenNr Neu gestanden hat.

Das wäre vielleicht für alle Formulare des Rätsels Lösung.
Man müsste vielleicht die Formatierung (Anzeige von MontageKM und LL ) an die Bedingung knüpfen, das die ReifenNr irgendwann innerhalb der eingegeben Reifenchecks einmal als ReifenNrNeu aufgetaucht ist.Und ab da soll es immer angezeigt werden

Wow, was für ein Geistesblitz.

Wäre das programmiertechnisch machbar?????

Das wäre super.

Ich füge die aktuelle DB nochmal an.

Vielen Dank im Voraus


Mario

 

Hallo Mario,

ich versuche mal, deine beiden Beiträge zusammenzufassen.

qry_GesamtAuftragsSumme

Ich habe in der Entwurfsansicht bei jeder der 3 Verbindungslinen die Option 2 („Beinhaltet alle Datensätze aus der tbl_Auftraege ...“) eingestellt.

Register Finanzen
Bei den Feldern, die du ansonsten noch in dem Register Finanzen darstellen möchtest, steige ich z. T. nicht durch.

Mit „Grundtabelle“ meinst du die tbl_Auftraege?? Und dort sind die 2 (3) Felder nur als leere „Container“ geparkt, damit sie im Register dann die Inhalte von qry_GesamtAuftragsSumme aufnehmen können?

Falls das so richtig ist, dann ist das falsch!! *grins
Du benötigst nicht solche „Container“, denn Felder wie GesamtNettoMat existieren ja jetzt in der Abfrage und können somit auch „irgendwie“ ins Register eingebracht werden.

Das, was du im Register beim Feld Materialpreis vergeblich versucht hast (Steuerelementinhalt = [qry_Materialpreis]![NettoSummeMat]) geht allerdings so nicht, denn:

a) ist das dann fast schon so, als würdest du ein ungebundenes Textfeld verwenden (dann benötigst du aber auch nicht mehr das Feld Materialpreis)

b) einen Feldinhalt auf diese Weise einzubringen, geht anders. Dafür benötigst du ein ungebundenes Textfeld und die DLookup-Funktion (auf Formularebene: DomWert), was aber in diesem Falle noch zu prüfen ist ... erstmal muss ich Klarheit haben.
Ich habe dir als Demo neben die beiden Felder Materialpreis und Dienstleistungen solche DomWert-Felder erstellt und von den beiden die Summe gebildet.

Falls es das ist, was du willst, kannst du die Felder Materialpreis und Dienstleistung aus der tbl_Auftraege und ggf. aus einigen Abfragen löschen, falls dort vorhanden. GesamtNettoPanne müsste dann ja auch noch erzeugt werden, doch lass das mal erst, denn der bisherige Code (auch der Code der beiden anderen DomWert-Felder) müsste eh noch erweitert werden. Erstmal geht es nur darum, ob du das überhaupt so willst.


Das Feld Lieferant lege ruhig schon an, kümmer dich nicht um die Aktualisierung. Auch, falls noch andere Felder anzulegen sind und du das kannst, so mach das ruhig schon.


MontageKM / Laufleistung
Jetzt wird´s aber langsam filigran. Soll die DB auch noch Kaffee kochen und Brötchen schmieren können? *entsetzt *tongue.gif*

Wenn ich es richtig verstehe, sollte es hinterher so aussehen:

- im Historienformular bleibt alles, wie es jetzt ist, MontageKM und LL werden immer angezeigt, außer beim „Erstreifen“, weil der ja nie im Feld ReifenNrNeu auftaucht

- im PopUp soll gewissermaßen der erste Reifen ausgeblendet werden, also der, der nicht im Feld ReifenNrNeu vorkommt (bei deinem Beispiel Nr. 2000)

- im Register soll MontageKM und LL nur dann sichtbar sein, wenn ein Reifen im Feld ReifenNrNeu erscheint (wobei die LL in dem Falle immer = 0 wäre. Also lieber nur MontageKM sichtbar machen?)

Falls du das so möchtest, würde ich das wohl umsetzen können. Aber die Frage ist auch hier erstmal, ob ich es korrekt gedeutet habe.


Also,
- füge auf jeden Fall schonmal die Felder im Register Finanzen ein
- lösche Materialpreis und Dienstleistung aus der Tabelle
- beantworte mir alle offenen Fragen mit einem JA *grins
- lade dann die neue DB hoch; anbei die geänderte DB.

Ich kann allerdings wohl erst Montagabend daran arbeiten (danach habe ich voraussichtlich wieder etwas mehr Zeit).

Bernd

Nachtrag
Das Feld EPID habe ich einfach mal gelöscht und wieder reingenommen, seitdem trat bei mir der Effekt nicht mehr auf. Beobachte das einfach mal weiter.

 

"Houston, wir haben ein Problem."

Mich wunderte, warum schon wieder die DB nicht mit hochgeladen wurde. Doch dieses Mal lag´s daran, dass sie inzwischen zu groß ist!!! 195 MB darf sie haben, 197 MB sind es.

Wenn man bedenkt, dass da wohl noch einige Abfragen, vor allem aber Berichte hinzu kommen, wird die DB in Zukunft noch deutlich größer werden. Sie jetzt umständlich zu teilen, damit man zwei DBs hochladen kann, halte ich auf Dauer auch für lästig.

Vorschlag: schick mir eine PN mit deiner Mailadresse und wir kommunizieren ab jetzt direkt per Mail.

Bernd