[AccessD] miracle required apparently

[Stuart McLachlan]

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
> >>>  --
> >>>
> -- 
> AccessD mailing list
> AccessD at databaseadvisors.com
> https://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com