Looping around !!!

[malagasy]

hi,

I have a portal in which dates can be entered (only saturdays). I also have created a field first_saturday and another field number_of_saturdays.

What I'm trying to get is if i enter 26/05/07 in the field first_saturday and 5 in Number_of_saturday, then in the portal 26/05 will be in first row, 2/6 second, 9/6 third, ect and this depending on the value number_of_saturday.

So far, I've only managed to automatically have 26/5 in portal (by copy and paste) and 2/6 with a calculation first_saturday +7... but don't know how to get the loop for the remaining .

Hope someone can help.

regards

[Søren Dyhr]

This is hardly a looped matter, well you can obviously ...but is it worth it??

--sd

test.zip

[malagasy]

i reckon it's worth it since it greatly any mistakes (forgetting a saturday for exemple) and save me the pain of having to record dates in the portal individually...which takes ages

[Søren Dyhr]

i reckon it's worth it since it greatly any mistakes (forgetting a saturday for exemple)

it greatly what???

--sd

[malagasy]

oups,

greatly reduce the chances of making any mistakes -)

[Søren Dyhr]

I do humbly dissagree, you're bound to trigger the execution of the script then. Like my template are the loopings similarly sensitive to the riddance of a portal row record in the sequence. I've set out to solve this flaw, but still isn't any looping required, a scripted replace is what it takes, but still only when deletions screws up the sequence.

Inspect my changes, the reason I use autoenters is that filemaker otherwise should have implemented an event trigger plugin to sync'e to the alterations.

I have beefed the logic up slightly, if you in the first line enter something wich isn't a saturday, will the field value seek the next comming saturday and enter it. Similar in the following lines if you enter an arbitrary value will the above value +7 days be what's in the field after the record is committed.

--sd

test.zip

[malagasy]

hi,

I have a portal in which dates needs to be entered automatically (only saturdays). I also have created a field first_saturday and another field number_of_saturdays. (these 2 fields are not part of the portal).

What I'm trying to get is if i enter 02/06/07 in the field first_saturday and 5 (or 6,7,8) in Number_of_saturday, then in the portal 02/06 will be in first row, 9/6 second, 16/6 third, ect and this depending on the value number_of_saturday.

I want to use the loop technique and believe i have to use set variable, ect... but quite bad at applying.

Hope someone can help.

regards

[Søren Dyhr]

I might have read you post wrongly, but why double post instead of correcting my blunders?

--sd

[Søren Dyhr]

Alright here's some looping!

--sd

test.zip

[malagasy]

i realised i had posted in the wrong section !

Reason I want looping (i know i gonna sound like a grandpa) is because i've used this system before and found it efficient... hope i won't get blamed for this -)

[malagasy]

cheers for your attachment, looks pretty similar to what i want !!

One more question, is there a way i could have the drop list appearing in first_saturday to only displaying current and future saturdays and not the one that have gone past ?

[Lee Smith]

I have merged the two topics.

Lee

[Søren Dyhr]

I think some trickerty is required since the Get(CurrentDate) is best used in a unstored field while a dropdown/popup is bound to have some indexing working. This means the data should originate from stored field a relation away, as prefab records with tons of future dates (saturdays) to which a thetajoin relation is pointing and selecting ...hardly convenient. I need to think!

--sd

[malagasy]

Thanks for that solution Soren however, it doesn't seem to be working on my database.

From what i can observe in your script, it deletes all the records when mine indeed already have a table with all the saturdays...and don't want these to be deleted everytime i use the script.

It seems my problem comes from a set variable part of the script...just don't know how to stop the loop / and cant manage the rows in the portal to have 7 days between eachothers

[malagasy]

Alright, so far, my script is >

Copy [select; Orders::First_saturday]

Past [select; Orderline::DateID]

Loop

Go to Portal Row [select; Next]

Paste [select; (OrderLine::DateID]

Exit Loop if [(Count (OrderLine::DateID] = Orders::Number_of_saturdays)]

End Loop

My 2 big problems are

1> the loop never stops

2> the date in the portal row should be First_saturday + 7 then First_saturday + 14 then First_saturday + 21 ,ect.... depending on how many saturdays have been chosen on Numbers_of_saturdays.

Hope someone understand and can help with a simple language (i'm not advanced!)

[Søren Dyhr]

..and don't want these to be deleted everytime i use the script.

Then don't use the script steps that get rid of previous generated records! But the problem I see is that this thread is kept in a very economizing mode letting out only some lumps of information, so I constantly guess wrong what you wish to achieve.

What roles plays the dropdown in this whole picture?

Why have you prefab'ed records, eventhough you wish the portal and script to genererate others?

Is this in fact a many2many structure? If so is absolutely no scripting needed, but instead two calc'fields as upper and lower range in a non-equijoin.

You might benefit from reading this thread, and especially when it turns into "recuring events":

http://www.fmforums.com/forum/showtopic.php?tid/124596/fromsearch/1/tp/1/

--sd

[Søren Dyhr]

Copy [select; Orders::First_saturday]

Past [select; Orderline::DateID]

Loop

Go to Portal Row [select; Next]

Paste [select; (OrderLine::DateID]

Exit Loop if [(Count (OrderLine::DateID] = Orders::Number_of_saturda ys)]

End Loop

In order to make your script stop correctly are you bound to issue a Commit Record just after the pasting.... But Copy and paste should be reserved for external dealings only, you tampers with what the user might have stored in the clipboard ...this is a developers NO NO!

--sd

[malagasy]

First, thanks for your patience...

I'll try to be clear about it...we provide services happening on saturdays to customers...

I have a

1/ Customer table

2/ Saturday table

3/ Order table

4/ Orderline table

When a customer place an order for a service, he states how many saturdays the service will be provided and from which saturday. The order layout (order table) allows entry such as prices, ect... and also the details of the saturdays the service will be provided (on his invoice, he can clearly see this).

On my side, with this system, i can go in the Saturday layout and see via a portal which customers need attentions for such day.

The dropdown display the saturday already recorded in the saturday table.

EXAMPLE >

Mr X wants service provided from 2/6 for 3 saturdays in the row. I will enter 2/6 in the field Firstsaturday and 3 in numberofsaturdays

and run the script which will automatically display 2/6 in row 1, 9/6 in row 2 and 16/6 in row 3.

Mr Y...same story but only 2 saturdays from 2/6

so row 1 is 2/6 and 9/6 in row 2.

When i'll be looking in my saturday layout, i can see X and Y for 2/6 and 9/6 but only X for 16/6 (this story is not relevant to the script).

This is why i trying to have a script which can do this...gosh, i think i even confused myself !

[comment]

Why is this so difficult?

CreateSaturdays.fp7.zip

[Søren Dyhr]

Why is this so difficult?

It's difficult because we have too little to go on, my previous attempt did the same. This seems like straight forward Hernandez, if the solution is inadequately structured will it lead comprehensive scripting to remedy ...but this is booking, which in essence isn't particular far away from:

http://www.fmforums.com/forum/showtopic.php?tid/176396/post/204083/hl//fromsearch/1/

Except we here, not are dealing with a monthly calendar, but a weekly only showing saturdays, there are in the thread sevaral ways to deal with the prefabs, either via calculaltions or genuine records. Since the grid here is only a portal of a predefined number of dates, doesn't it really matter if the booking contains irrelevant match dates in the matching straining would require a tighter algorithm in the keyfield generation.

Now we can't show portal in portals, so a concatanation of the persons X and Y needs to be done via List( and with the ¶'s repalced with ;'s ...

Try to dissect the template, not one single script is required ...but a selfjoin and a global is instead all it takes!!

--sd

test2.zip

[comment]

I don't think the first Saturday can be global, since:

"When a customer place an order for a service, he states how many saturdays the service will be provided and from which saturday."

But the truth is I have no idea what you did there. All I can say is "why is this so difficult?"

[malagasy]

"Why is this so difficult? "

> Pretty silly and simple...I started this database from scratch with no experience whatsoever.

I know for sure it has to be optimized and some changes need to be done but I don't really have the funds to get a consultant working on it. I also know from my short experience that everytime I have tried to make something work better by easier steps, it has had a lot of negative effects on other elements of the work I've done !

I'm totally open to help and improvement but no one will be bothered anyway...

[Søren Dyhr]

I don't think the first Saturday can be global

No it shall not be a global in the bookings, but in the viewer the one with the portal does it make good sense since you in the selfjoin at present is in one particuar record having an arbitrary selected pair.

Do not worry, I've tightend it up for you - take a look at the template!

But the truth is I have no idea what you did there

If you take a close look at the image above, guess who've made them?? This is exactly the same priciple at upper graph where a global field changes the values in the sanwiched TO's records ...which was your take on an improvement on JMO's template ...which I then said was a CPU hogging approach compared with the original where endless number of records were made upfront each with it's own date and a key field to the viewer which in your case was a carthesian link.

Mine differs by having a global for the start of the range and the > relation makes sufficient number of records show up in the portal, showing calc'ed values for dates.

I'm totally open to help and improvement but no one will be bothered anyway...

Thanks a lot : : ...I can see from the number downloads of my latest template and Comment's reply (he mentions a detail revealing he's the only one who cared), and that you not even bothered to examine what i did....

--sd

test2update.zip

[comment]

I am still not sure I understand your concept, so I may be wrong in this:

I believe the comparison to bookings is inappropriate here. Booking is all about resolving competing demands on the same resources. Here, there is no conflict. Each "booking" is independent and discrete, and you can have as many as orders for the same Saturday as your office staff can handle.

This also suggest that each order should have its own portal row on the Viewer layout - because each order may have distinct attributes. Much more importantly, each order item needs a record of its own, for the same reason. If this last assumption is incorrect, then it could be even simpler than I have suggested - see attached.

I'm totally open to help and improvement but no one will be bothered anyway...

That is indeed a strange thing to say in the circumstances.

ShowSaturdays.fp7.zip

[Søren Dyhr]

Booking is all about resolving competing demands on the same resources. Here, there is no conflict. Each "booking" is independent and discrete, and you can have as many as orders for the same Saturday as your office staff can handle.

Perhaps am just running dry of synonyms here? It's closely related to booking then - Could you figure out why none of these approaches doesn't work:

http://www.fmforums.com/forum/attachment.php?attid/10846/

http://www.fmforums.com/forum/attachment.php?attid/10913/

In principle are they doing exactly the same!

What caught my attention was this:

When i'll be looking in my saturday layout, i can see X and Y for 2/6 and 9/6 but only X for 16/6

On my side, with this system, i can go in the Saturday layout and see via a portal which customers need attentions for such day

1/ Customer table

2/ Saturday table

3/ Order table

4/ Orderline table

I read this as if the entire purpose of scripting is to spread an order across some record in the saturday table.

Much more importantly, each order item needs a record of its own, for the same reason

I agree! This is why I provide this in the "booking" layout, which is showing the data entered in the Orders table, I haven't dealt with neither the Orderline- , nor the Customer- table yet. The structure your latest template suggest is what I have in mind, but the supposed scripting needed here was to establish a view of saturdays (in plural), not just one - hence my measures not to display a portal in a portal.

I think malagazy uses a portal to facilitate dropdown'ish behaviour in the Saturday table, and wish to set values in each row to pull a status for each of the days point at. Notice that the word DateID occures in malagazys own script!

--sd

[comment]

Well, the truth is I also pick and choose from the "specification" as I see fit. For example, I will not have a table of Saturdays, because that's not information. The important thing is to facilitate the expected workflow.

[Søren Dyhr]

I will not have a table of Saturdays, because that's not information

Exactly, it's there to provide a summary or a morphed or reorganized appearance of the same data. I think it where the scripting is supposed to work ...

he truth is I also pick and choose from the "specification" as I see fit

Yes, it's approaching something a moderator need cautioning about ...it's the usual urge to keep things unnessersary abstract, we usually endure from people who doesn't wan't answers, but instead accolades for getting into the deep end of the pool, totally ignoring that scripting or CF'ing isn't all there is to a solution, if it just remidies fixed assumtions.

--sd