[AccessD] miracle required apparently

[jack drawbridge]

Good stuff Steve! Thanks for sharing.

On Wed, Oct 18, 2023 at 3:57 PM 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
>
>
>
> 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
> >>>  >>>  --
> >>>  >>>
> >>>  --
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> https://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>