dynamic portals

[veganboyjosh]

hey kiddos.

happy holidays to one and all.

we are trying to keep track of things like vacation dates, or employees available to work outside their normal schedule...etc.

Files being used:

employee file: each employee =one record.

date file: each date =one record. right now i have thru 12/31/2004. (i basically scripted the creation of new records in the date file for one year. near the end of 2004, i'll prolly create 2005's records)

i would like to have a portal in the employee file that has 366 rows. Row 1 is the current date, row 2 will be tomorrow, row 366 is today's date +365. when i use the db tomorrow, row 1 will be tomorrow's date, row two will be the next day's date, and row 366 will be tomorrow's date +365. the key needs to somehow be dynamic.

right now, i have the relationship set to show this year's dates. so the portal only lists the 365 dates that match today's date's year. this works fine at the beginning of the year, (or appears to, i know it doesn't really count as "working", but it'll pass for now) but as was apparent quickly (since i'm building this at the end of december,) this is a pain at the end of the year. i need to scroll to the end of the portal to get to this week's dates, and the portal does not display anything past 12/31 of _this_ year.

I hope this makes sense, if i need to post more info, please let me know.

thanks in advance, as always...

josh

[Robert Kidd]

I'm not sure how practical it will be to work with a 366 row portal but here are two options..

One solution would be to script the creation of the "left" key of the relationship.

SetField G_DateMatch = Status(CurrentDate)

SetField G_Date = Status(CurrentDate)+1

SetField G_LoopCount =1

Loop

SetField G_DateMatch = G_DateMatch & "

[veganboyjosh]

thanks robert.

i think the calc is the way to do it. i was thinking about something like this but trying to avoid it... the script wouldn't work that well for us cos the files stay open all the time(we get calls late at night or early in the mornig for jobs, and don't want to wait for the files to open when customers are on the phone)

doing it by weeks wouldn't really work, and i don't think months would either.

here is a basic breakdown of the way the files work together:

employee file:each emp gets one record.

client file:each clint gets one record.

job file: each job gets one record.

i recently created a date file, where every date gets it's own record.

each record in each file has it's own unique id number.

clients can have more than one job, and more than one job per day/date.

employees can work any number of jobs in one day/date.

each job has one client and one employee.

in the main job file layout, i have a related field fromt he client files so that when i create ajob for a client, i call up a notes field specific for that client. ie-"don't send employee 342, this client really likes employee 815." i would like to have a similar related field from the date file, with notes like "steven is not available this date, but rory is" that show up when a job is created and the date assigned. does this make sense?

if a employee is out of town, or available for dates not usually on their schedule, i would go to the individual employee's record, to the layout with the date portal, and see the coming year's dates, and would enter the abnormal schedule items in the proper date's portal row(s).

thinking about it this way, i suppose i could use weeks, but i think dates would make my calcs a lot simpler to start with, yeah?

thanks again for your help.

josh

[SteveB]

Goto web page and download David McKee's free Ranges Plugin. Use it to form the left side of the relationship. I don't think you need a portal with 365 rows. You just need the relationship to match the next 365 days.

Steve

[veganboyjosh]

thanks steve, i'll try that.

[-Queue-]

You could also use a global number repeating field gIndex with 365 repetitions, the first containing zero and incrementing to the last rep at 364. Then create an unstored repeating date calculation field with 365 reps and the calc Status(CurrentDate) + gIndex. Use Ray's indexing of nonindexable fields technique to store this data in a new field. Lastly, create a value list based on this field, and an unstored calculation text field using ValueListItems( thisfile, valuelistname ). Use this as your left-hand side of the relationship.

[Ugo DI LUCA]

veganboyjosh said:

doing it by weeks wouldn't really work, and i don't think months would either.

Why ?

I'd use a fixed portal for this, the opening script would just "capture" the current month records from your "365 days file" - just have an indexed calc there with Month(DateField) -, then pick from the stack of related Ids those seven days of the current week as a default setting.

Wouldn't it be possible to have a 7 rows portal, each row being one day (Sun-Sat), then a fake portal scrowlbar that would move from weeks to weeks with one button, and from month to month with the lower one.

...Or just use some calendar setting, just the same as Dj's sample. Having it done on a 365 days file rather than a infinite calendar solution wouldn't be a problem.

BTW, 365 days wouldn't be accurate for leap years...