Office: (Office 2016) Do While Loop Schleife

Hallo zusammen,

ich brauche Unterstützung bei der Entwicklung einer Schleife. In Access habe ich eine Datenbank welche Trainingspläne fürs Schwimmen speichert. Nun soll automatisch ein neuer Trainingsplan angelegt werden. Kommend aus dem bereits erzeugten Rahmenplan soll im nächsten Einzelplan eine Gesamtumfang von z.B. 1219 m Grundlagenausdauer I (GA I) geschwommen werden. Aus der Tabelle mit allen bereits erstellten Trainingsplänen werden per Abfrage alle Trainingszeilen mit GA I ausgefiltert. Aus diesen nun z.B. 100 Datensätze sollen einige Datensätze aufaddiert werden bis der Gesamtumfang erreicht wird. D.h. ich definiere aus den 1219 m eine Untergrenze = 1200m und eine Obergrenze = 1250m. Nun soll die besagte Scheife solange zufällige Zeilen aus der Abfrage auslesen und die jeweiligen Umfangswerte aufaddieren bis der Gesamtumfang 1200m oder 1250m erreicht hat. Beispiel: Im ersten Durchlauf ergibt sich aus der zufällig ausgewählten Zeile ein Einzelumfang von 400m = Gesamtumfang 400m. Im zweiten Durchlauf ergibt sich eine Einzelumfang von 500m = Gesamtumfang von 900m. Im dritten Durchlauf ergibt sich ein Einzelumfang von 200m = Gesamtumfang von 1100m. Im vierten Durchlauf ergibt sich ein Einzelumfang von 500m - geht nicht weil Gesamtumfang dann überschritten ist. im 6 Durchlauf ergibt sich ein Einzelumfang von 100m = Gesamtumfang = 1200m = Schleife wird abgebrochen.

Diese Schleife bekomme ich aktuell nicht auf die Reihe, daher bitte ich dazu um eure Unterstützung.

Grüße th0104

:)

 

Sinnvoller als Deine vielen Zeilen Prosa wäre ein Blick auf die Datenstruktur.
Ein Screenshot vom Beziehungsfenster mit allen beteilgten tabellen zum Beispiel.

 

Hallo,

okay, als erstes die Beziehungsstruktur, Access.png.
Die Schleife stützt sich nur auf Daten aus der Tabelle "tbl_TraingsplanInhalt"

Auch die aktuelle Programmierung habe ich angefügt, Access_Programm.txt.

Ich hoffe, dass hilft weiter.

Grüße

th0104

 

Es fehlen bei den Beziehungen zwischen den Tabellen die referentiellen Integritäten.

Die vielen berechneten Felder gehören imho nicht in eine Tabelle, sondern sollten zur Laufzeit mit einer Abfrage ermittelt werden. Insofern könnte über das Datenmodell noch mal gründlich nachgedacht werden.

Der Code ist schwer lesbar, so wie Du ihn postest ....
In Code-Tags gekleidet kann man ihn hier auch prima direkt im Beitrag veröffentlichen.
Auch hier sähe ich Verbesserungsbedarf.
14 mal DLookUp mit Zuweisung in Variablen und dann wieder 14 mal diese Werte in Felder geschrieben ...
Könnte das nicht mit einer Aktualisierungabfrage direkt erledigt werden?

 

Hallo hcscherzer,

danke für die Infos zur Verbesserung des Datenmodells. Auch die vorgeschlagenen Techniken helfen den Code zu verbessern.

Doch sind das im Bezug auf die Frage allgemeine Hinweise oder sehe ich die Lösung für die Frage nur nicht?

Grüße
th0104

 

Selbst mit Code ist diese Beschreibung zu dünn.

Setze einen Haltepunkt auf die WHILE und schau die Variablen an, die den Durchlauf beeinflussen.

 

Hallo th0104,

die Idee, mit zufällig ausgewählten Werten an die Zielmarke zu gelangen, halte ich nicht für so sinnvoll.

Alternativ könnte man das vielleicht auch so gestalten:
- Abfrage absteigenden nach Umfang mit der Bedinung

 

Hallo knobbi38,

die geschilderte Abfrage ist soweit okay. Doch für mich ist unschön daran, dass beim Erzeugen von mehreren Trainingseinheiten immer die gleichen Trainingszeilen im Bereich z.B. GA I erzeugt wird. D.h. in jedem Trainingsplan sind die gleichen Einzelstrecken im Bereich GA I. Ergänzend zum ersten Post, wenn es funktioniert kann ich 2-36 Trainingspläne auf einen Funktionsaufruf erzeugen.

Ich nutze doch Move.First, Move.Next, warum der Hinweis bzgl. der Move Methode.

Die laufende Summe zu bilden klappt. In meiner Schleife funktioniert der Ausstieg aus der Schleife zwischen Untergrenze und Obergrenze nicht.

Grüße
th0104

 

Hallo drambeldier,

dem einem ist es zu viele Prosa, dem anderen ist die Beschreibung zu dünn *Smilie

Mit Haltepunkten oder Ausgabefenstern habe ich das schon zahlreich geprüft, komme aber auf keine Lösung.

Wie bei "knobbi38" geschrieben, der richtige Ausstieg ist das Problem.

Was fehlt an Info?

Grüße
th0104

 

Na ja, das ist wohl immer so.

Setz mal einen
Code:

direkt hinter das WHILE, da solltest Du doch sehen, was da gerechnet wird.

Ich vermute mal, dass niemand im Trockenschwimmen Deine Schleife nachrechnen wird.

 

Wo ist die 5?
Im Erstbeitrag folgt dem 4. Durchgang der 6.
Kommt da nur mein Logikprozessor ins Stottern?

2) Ist die zufällige Auswahl nun gewünscht oder nicht?

3) Die Summe soll zwischen den genannten Grenzen bleiben. Ist die Anzahl der Durchläufe dafür uninteressant oder auch gegeben?
Mangels Bekanntgabe der Daten kann man auch nicht deren Spannbreite erahnen.
Je nach Datenlage(?) kann es auch passieren, dass alle Durchläufe nicht genügen, um auf die gewünschte Summe zu kommen?

4) Der Code ist überarbeitungswürdig und aus meiner Sicht sehr unübersichtlich. Das geht schon los mit zwei DB-Referenzen, die beide CurrentDb zum Inhalt nehmen.

5) Nur für ein Recordset muss man kein gespeichertes Abfrageobjekt erzeugen, das klappt auch unmittelbar mit der SQL-Anweisung.

Losgelöst davon: Die ursprüngliche Abfrage kann man gleich um eine zufällige Sortierung bereichern
Code:

Mit Erstellung des Recordsets wäre diese Reihenfolge fixiert, so dass man eine einfache Schleife laufen lassen kann.

Ausstieg aus der Schleife (nachlesen in der Hilfe):
Code:

 

Hallo th0104,

Schon mal die Move-Methode angeschaut? Anstatt mit einer Schleife von einem Satz zum nächsten zu positionieren, könnte man auch einfach direkt auf den gewünschten DS positionieren.

Warum zwei Abbruchbedingungen?
Int_berechnet wird in deinem Beispiel nicht definiert?

Wie andere auch schon angemerkt haben, muß eine echte Abbruchbedingung existieren, sonst loopst du mit zufälligen Werten u.U. bis in alle Ewigkeit. Wieviel Versuche mit RND möchtest du Zulassen, bis eine Lösung gefunden werden sollte?

Der Algorithmus ist verbesserungswürdig, oder?

Gruß Ulrich

 

Hallo knobbi38,

die Definitionen der Move Methode muss ich mir noch detaillierter ansehen.
Weiter oben im Programm wird Int_berechnet definiert, = der theoretische Wert im Trainingsplan, basierend auf dem Rahmenplan. Daraus erfolgt dann die Obergrenze und die Untergrenze. z.B. Int_berechnet = 1219m Obergrenze = 1250, Untergrenze = 1200m.
Zwei Abbruchbedingungen kommen aus dem Versuch die Schleife richtig ans laufen zu bringen. Ich habe dazu schon viel ausprobiert, daher wirkt es mittlerweile eher "chaotisch".
Es gibt eigentlich keine Versuchsbegrenzung. Die einzelnen Datensätze in der Tabelle mit GA_I gehen von 100m bis 2200m. Daher kann es bei z.B. 1200-1250m, siehe oben, bei zufälliger Auswahl zu zwei, drei vier oder auch 8 Durchläufen kommen bis der Grenzwert erreicht wird.

Grüße
th0104

 

Hallo ebs17,

1) richtig, nach vier kommt fünf.

2) Zufällig, ja - damit nicht immer die gleichen Trainingspläne entstehen.

3) Die Anzahl der Durchläufe ist uninteressant, es geht mit einem, mal sind es zwei, mal 5 Durchläufe, die Bandbreite liegt zwischen 100m und 2200m.

4) ja, das habe ich jetzt gelernt.

5) danke für den Vorschlag, muss ich nun ausprobieren.

Grüße
th0104