[AccessD] miracle required apparently

[Steve Schapel]

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



On 18/10/2023 2:13:47 pm, "Steve Schapel" 
<steve at datamanagementsolutions.biz> wrote:

>Thanks again, Stuart.
>
>As I said to Paul, I will upload a simple sample database to illustrate the basics of what I've been trying.  Maybe I'll get that done today.
>
>It's awesome getting this kind help and support from you and other members of the group.  From the standpoint of my organisation, it is important to get it working if possible, so it would mean a lot to me if we can crack it.
>
>Regards
>Steve
>
>
>On 18/10/2023 1:38:30 pm, "Stuart McLachlan" <stuart at lexacorp.com.pg> wrote:
>
>>I had a bit of a play with it last night, but avoiding the same two people competing against
>>each other more than once is proving very tricking.  I'll have another go later 😀
>>(incluindg some demo code without the limitation)
>>
>>On 17 Oct 2023 at 18:50, Steve Schapel wrote:
>>
>>>  So, Stuart, are you suggesting the "very simple solution" being to
>>>  abandon the project?  Or do you think it's achievable?
>>>
>>>  Thanks again.
>>>
>>>  Regards
>>>  Steve
>>>
>>>  On 17/10/2023 5:46:41 pm, "Steve Schapel"
>>>  <steve at datamanagementsolutions.biz> wrote:
>>>
>>>  >Thank you very much, Stuart.
>>>  >
>>>  >Your astute observation was indeed initially a stipulation of the
>>>  >project.  But I have already abandoned the dream of having that
>>>  >happen, and accepting the fact that at times there will be "the luck
>>>  >of the draw" where the same two teams are paired up.
>>>  >
>>>  >I can't even get it to work without shooting for that limitation!
>>>  >
>>>  >Regards
>>>  >Steve
>>>  >
>>>  >On 17/10/2023 3:41:48 pm, "Stuart McLachlan" <stuart at lexacorp.com.pg>
>>>  >wrote:
>>>  >
>>>  >>There is a very simple solution to your stated problem, but I don't
>>>  >>think that is what you want.     I'll leave you to work it out.
>>>  >>
>>>  >>But I assume there is another unstated limitation:
>>>  >>No two participants can participate  together in more than one
>>>  >>event.
>>>  >>
>>>  >>Yes?
>>>  >>
>>>  >>
>>>  >>
>>>  >>
>>>  >>On 17 Oct 2023 at 1:22, Steve Schapel wrote:
>>>  >>
>>>  >>>  Hi all
>>>  >>>
>>>  >>>  I'm trying to do something that I initially thought would be
>>>  >>>  reasonably easy.  But alas, so far success has eluded me.  Any
>>>  >>>  insights accepted with much gratitude!
>>>  >>>
>>>  >>>  The goal:  Assign a number of Participants to a number of
>>>  >>>  Activities over a number of Sessions.
>>>  >>>
>>>  >>>  Very simple example:
>>>  >>>       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
>>>  >>>
>>>  >>>  The stipulation is that each participant should do each activity
>>>  >>>  one time.
>>>  >>>
>>>  >>>  By trial and error brute force, I know that there is at least one
>>>  >>>  solution, namely:
>>>  >>>
>>>  >>>                        chess       tai chi       bowls
>>>  >>>                        diving
>>>  >>>     9am           A & E        C & F        D & G        B & H
>>>  >>>  10am           C & G       A & H       B & E         D & F
>>>  >>>  11am           D & H      B & G        A & F         C & E
>>>  >>>  12pm           B & F       D & E        C & H        A & G
>>>  >>>
>>>  >>>  HOWEVER, I have tried multiple angles of looping through nested
>>>  >>>  (and sometimes randomised) recordsets based on the core data
>>>  >>>  elements (sessions, activities, and participants), to write the
>>>  >>>  assignments to the available slots in a schedule table, and to my
>>>  >>>  shock (and horror) we always reach the point in the procedure
>>>  >>>  where it gets stuck, due to trying to assign a participant to two
>>>  >>>  activities in the same session, but with no valid alternative
>>>  >>>  slot available.
>>>  >>>
>>>  >>>  There is no problem if the model calls for the super simple
>>>  >>>  option of only one participant for each activity.  But otherwise,
>>>  >>>  no dice, so far.
>>>  >>>
>>>  >>>  There MUST be a way to make this work?  Surely?
>>>  >>>
>>>  >>>  Thanks a lot.
>>>  >>>
>>>  >>>  Regards
>>>  >>>  Steve
>>>  >>>  --
>>>  >>>
>>>  --