I wonder if you ever been involved in assigning rotating shifts. As I understand it can an employee rotate between 5 shift-types based on what he/she haven't done in the previous 4 shifts in theory. But in this case depends the assignment also on availability among the rest of the staff so it can't be a too rigid scheduling. The next task in line should more act as guidance, than be the actual one to assign.

My initial thought was let the new GetNth... function gather the 4 previous assignments and use a custom function makes the opposite of what the FilterValue( does. with all the possible shift-types.

That would be easy to do, if it weren't that the client haven't upgraded to Fm7 yet, and the IT-responsible isn't sure when and if she would be given permission to do so.

So good ideas would be great.

--sd

I am not quite sure what is it that you want to do, but with a value list you can do just about anything that GetNthRecord does.

Thats right, but the sortorder worries me slightly!

--sd

It shouldn't. Use a second field, that is a text calc that determines the sort order, and append a serialID to the end to ensure the inclusion of all records.

The problem is that it uses the data stored in a join table, liekely to be containing an exorbitant number of records over time, so a leading zero scheme is likely to be the straw that breaks the camels back one day...

I have also considered a sorting upon the recordID subtracted from a very large number and concatanated with the record value for this sorting purpose, which might be the way I do it ...because trimming it off the concatation is very simple:

Middle(theDerivedValue;10;99999)

And since the newest record have the smallest integer ahead of the value, will picking the first 4 with middleValues( and then followed by the above. be a tiny tad faster than using Substitute( all values 0123456789 away.

--sd

a leading zero scheme is likely to be the straw that breaks the camels back one day

I don't quite see why - the calc can be stored. And since it seems you are interested in the last N records, the second field can be the serialID directly, with no leading zeros and no concatenation.

Unless you're worried about the size of the value list itself - in such case, perhaps a script of:

GTRR

Unsort

Go to Record [First]

Omit Multiple [Get(FoundCount) - 4]

Copy All Records

...

This should sound familiar to you, no?

It does, but event-triggers yikes! It has to be hidden somewhere very crafty ...I'm beginning to feel the data structure is somewhat wrong, not that I have anything against scripting - but if the need for event-triggers creaps in on me, is something definately wrong.

I build a portal full of available staff by relations entirely, where I wish to watch next to their name, a guide to what their next shifttype rather/better be. It would be to rigid a system that only lists the portal with the ones who "ought" to be assigned next to this particular shift type.

I had second thoughts to the concatanation idea, since it's based on a join tables records, would deliberate redundancy be introduced and cause hogging of twice the storage space, which perhaps would be alright, if it weren't for the massive size the tables content might grow to.

Rotations in shift serves several purposes, where I can't be absolutely sure which counts the most here, but sometimes is a kind of repressive tolerance hidden in words like "job-enrichment" at other times is it like pilots working themself thru a randomly generated list of checks before liftoff ...to rule out carelessness and idiosyncrasies.

--sd

If you want features, you have to commit some resources. The most efficient db has no relationships, no calculations, no data and no fields. I don't think you'd need event-triggers - seems to me this could be triggered by user navigation.

Another idea that comes to mind: every time an assignment is made, add the type to a text field in Staff. Set the text field to auto-enter (replace) LeftValues ( field ; 4 ), so that it always keeps the last 4 assignments of staff member. OTOH, this could get quite tricky if an assignment is changed...

I don't know about your situation, but usually people will exchange shifts assigned by the system. This can even lead to negative feedback that will overflow and defeat the system: Say Adam doesn't like night shifts, so every time he exchanges with Betty, who doesn't mind. Eventually, all night shifts will be assigned to Adam, and none to Betty, while the reality will be just the opposite.

Another idea that comes to mind: every time an assignment is made, add the type to a text field in Staff. Set the text field to auto-enter (replace) LeftValues ( field ; 4 ), so that it always keeps the last 4 assignments of staff member. OTOH, this could get quite tricky if an assignment is change

This is great, and no it wont be a problem because a script is executing whenever a assignment is changed - Thanks a lot thats the way to do it!!

Say Adam doesn't like night shifts, so every time he exchanges with Betty, who doesn't mind. Eventually, all night shifts will be assigned to Adam, and none to Betty, while the reality will be just the opposite.

Good point indeed, and the person in charge of assigning people to shifts might even abuse the system to bully some he/she don't favours ...but thats exactly why I only makes suggestions to what type of shift each person is candidate to, without demanding it being followed strictly.

--sd