[AccessD] miracle required apparently

[Steve Schapel]

Hi Stuart

Thanks a lot.  Yes, something like that would be one possible 
application of the application.

Except that in your example it would be 5 groups of 6, rather than 6 
groups of 5.  Each of the 5 groups would do one of the 5 activities.

Then, in the next rotation (timeslot), the individuals are re-sorted 
into 5 groups, and then each of the the 5 groups once again would do one 
of the 5 activities - the only proviso being that this is done in such a 
way that no individual ends up in a group that is doing an activity that 
he has already done.

But to be honest, that is considerably more complex than the example I 
gave at the beginning, namely:

     4 Sessions
     4 Activities
     8 Participants (therefore 2 per Activity)

To illustrate:
Let's say the sessions are 9am, 10am, 11am, 12pm.
Let's sat the activities are chess, tai chi, bowls, diving
Let's say the participants are A, B, C, D, E, F, G, H

If we go with that example, for a start, then this is what is supposed 
to happen:

At 9am, each of the 4 activities takes place, and 2 of the participants 
(teams most likely, sorry about the confusing terminology!) take part in 
each.
Then at 10am, each of the 4 activities takes place, and again 2 of the 
participants take part in each - such that no participant does an 
activity that they have already done.
And so on, for 11am and 12pm.
No worries.

So, in the sample database, we can set up the above scenario.  4 records 
in the Rotations table, 4 records in the Activities table, and 8 records 
in the Participants table.

Click the 'Create Schedule' button on the 'DefineCarnival' form.
We should get 32 records created for a full schedule that matches the 
criteria.
Click the button again to re-calculate, as often as you like.  😀
We only successfully get the full complement of 32 slots filled every 
now and then.
Most of the time, the procedure reaches a point where it is trying to 
assign a participant to a slot, but is unable to because that 
participant has already done that activity in a previous rotation, and 
there is no further available slot to put them into.

Does that clarify?  Hope making sense.

Thanks a lot.

Regards
Steve


On 21/10/2023 5:12:30 pm, "Stuart McLachlan" <stuart at lexacorp.com.pg> 
wrote:

>Ah, I was thinking of something like a  sports series where one player or team played
>against a different player or team (i.e. two participants per match)
>Where the "pigeonholes" are dates or times  and venues.
>.
>Now I'm thinking of something like a military selection board where you can have say 30
>candidates  where you want to put them through 5 different activities so you split them into
>6 teams of  5 for the first activity and then into different team compositions for the next
>activity etc  where the objective is to mix the teams up for each activity. i.e. have the
>minimum number of people together in the same team  for different activities,
>
>Is that more along the lines of what you are doing?
>
>
>On 21 Oct 2023 at 3:13, Steve Schapel wrote:
>
>>  Many thanks for your continued interest, Paul, and for your clarifying
>>  questions.
>>
>>  The examples I have given are simpler than we would generally expect
>>  for actual events.  But I figured that getting it working for simple
>>  configurations hopefully points our noses in the right direction for
>>  managing more compex scenarios.
>>
>>  Anyway, to answer your questions:
>>
>>  1.  Yes, basically right.  Where I have used the word "participant",
>>  in practice this usually refers to a team or group rather than to an
>>  individual person - but conceptually comes down to the same thing. So
>>  yes, the same participant cannot be in the same time slot or activity
>>  more than once. The variation from what you have put, is that the
>>  number of participants per activity can be (and often would be) more
>>  than 2.  In the example database, the Teams field in the Activities
>>  table is to show the number of participants for each activity.
>>
>>  2.  Thankfully this would never happen.  The total number of
>>  particpant slots available across all activites for a given timeslot
>>  will always be the same as the total number of participants.  Everyone
>>  has to have a go - this is fundamental to the structure of this type
>>  of event, and will be enforced within the application.  So if there
>>  are 4 activities, each allowing the allocation of 2 participants,
>>  there will never be more than 8 participants registered.
>>
>>  Regards
>>  Steve
>>
>>
>>  On 21/10/2023 3:14:03 pm, "Paul Hartland via AccessD"
>>  <accessd at databaseadvisors.com> wrote:
>>
>>  >Hi Steve,
>>  >
>>  >I have to work overtime this weekemd, but want to try and have a look
>>  >into this making it as flexible as possible, so am I right in
>>  >thinking the basics of it are as below
>>  >
>>  >1. The time slots, activities and amount of people can vary, a
>>  >minimum of 1 person per activity, per time slot but no more than 2,
>>  >the same person cannot be in the same time slot or activity more than
>>  >once.
>>  >
>>  >2. What if you had more people than available slots take a very
>>  >simple example of 1 time slot, 1 activity and say 4 people, will 2
>>  >people be left out ?
>>  >
>>  >Paul
>>  >
>>  >On Sat, 21 Oct 2023, 01:36 Steve Schapel,
>>  ><steve at datamanagementsolutions.biz> wrote:
>>  >
>>  >>  By the way, I have discovered that my earlier statement, that I've
>>  >>  got it working correctly in the simple case of only one
>>  >>  participant per activity, is incorrect.
>>  >>
>>  >>  I had to try with a real-life example, being 10 teams, 10
>>  >>  activites, and only 6 rotation.  And with that scope, running the
>>  >>  code in the attached database repeatedly, I found it only
>>  >>  correctly filled all 60 required slots roughly 20% of the time.
>>  >>
>>  >>  Increasing the number of rotations to 7, reduces the success rate
>>  >>  to the vicinty of 2%.
>>  >>
>>  >>  Regards
>>  >>  Steve
>>  >>
>>  >>
>>  >>  On 19/10/2023 8:57:43 am, "Steve Schapel"
>>  >>  <steve at datamanagementsolutions.biz> wrote:
>>  >>
>>  >>  >I have put together a bare-bones example database, to show one
>>  >>  >approach I
>>  >>  have taken to this problem.  I have tried to keep it simple, hope
>>  >>  it makes sense.
>>  >>  >
>>  >>  >I tried attaching it to a post to the list, not realising that it
>>  >>  >would
>>  >>  breach the post size limit.
>>  >>  >
>>  >>  >So, if you're interested, please feel free to download it from
>>  >>https://sportsrunner.net/files/CarnivalSchedule.zip
>>  >>  >
>>  >>  >Thanks a lot.
>>  >>  >
>>  >>  >Regards
>>  >>  >Steve