set field is 'weirder than weird'?

[ron G]

I have a portal in Members. The portal field contents are the object of several scripts for error checking, input etc...

One script issues a command: Set Field[Dues::Status; "Late".

The problem is (and I can watch it happen in the debugger) when this line is executed, not only is Dues::Status assigned a value of "Late" but the Dues::Date field is assigned a value of 02/09/2012 (Or whatever todays' date is)

Huh?

Help is greatly appreciated. I have never run across anything as weird as this....

Thanks

Ron

[comment]

Hint:

Set Field [ Dues::Status; "Late" ]

does NOT modify the Dues::Date field. Look for other causes, such as auto-entry options.

[LaRetta]

Besides checking the auto-enter options on Dues::Date, also take a look at the field itself (double-click it) and make sure it isn't the creation date field instead. Sometimes I copy/paste fields and then re-specify ... it is easier than creating new field and setting its date formatting. But then I forget to re-point to the different field.

[ron G]

Besides checking the auto-enter options on Dues::Date, also take a look at the field itself (double-click it) and make sure it isn't the creation date field instead. Sometimes I copy/paste fields and then re-specify ... it is easier than creating new field and setting its date formatting. But then I forget to re-point to the different field.

Great observation. I DID have an auto-enter in the dues::date field.

But, even when the auto-enter was removed, the set field command leaves an unnecssary blank row in the portal.

I have written a one line script that did a set field to an adjacent field and it too left a unnecessary blank row in the portal (no less than 2 blank rows) I can't delete the final row.?

Ultimately, I rewrote the script and the problem went away. But, it is certainly a curiocity and an opporotunity to increase my understanding.

Any additional thoughts are appreciated.

Ron

[LaRetta]

Dang ... it is too bad you rewrote it, Ron, because these things are premium material from which to learn. Next time it happens you will now have to go through this again.

If you have 'Allow creation of related' turned on to the portal, there will always be a blank 'final' row. And we can't tell you what might have been wrong with your script without seeing the script, LOL. It sounds like your one-line script is not setting an adjacent field but rather jumping to your blank 'final' row and then, by setting a field, creates a new record. Another gotcha is the right field from wrong table occurrence.

When this happens to me, I usually find some simple thing I missed and it helps reinforce that I remember to check those things next time. :^)

ADDED: And sometimes I discover wonderful things I did not know ... the jewels hidden amongst the fodder. :yep:

Edited February 10, 2012 by LaRetta

[ron G]

LaRetta. RE: One line script.

The poral fields are:

Dues::Date

The Layout is based on Members and the fields out of the portal are:

Members::Status

Dues::Status

My one line script was: set field:Dues::Status; "Late"

When the script was run, it put "Late" in Dues::Status but also added an additonal portal row???

I stepped through in debug and there really wasn't anything else going on. I just don't get it. But, I won't loose too much sleep over it. My hope was that someone else would respond with ...."Oh yeah, that happned to me it's cause was..."

It looks like if/when it happens again I will get to figure it out and be the 'other person' for someone else...

Oh well, onward through the fog.

Thanks for your ideas...

[LaRetta]

Why are you setting a related (many-side) table's field (Dues::Status) outside of the portal? You DO realize that it can create a related record also, right, if Allow Creation is on to that relationship? And, depending upon how they are related (which you haven't explained), it could be over-writing another value instead of creating a new child record. I would make an assumption that there are many dues for one Member otherwise you would probably not need the portal.

I stepped through in debug and there really wasn't anything else going on.

If a related table is acquiring a new record and fields are acquiring dates and you are not doing it, then I assure you that something IS going on.

I am sure we have all experienced whatever it is you are doing but we will never know since we still do not know what you have and you don't seem keen on sharing your file to let us figure it out. And that is fine ... it is your fog to merge through as you wish so please carry on ... :)

[ron G]

I 'get' what you are saying about set field creating a new row in a portal. And, I have (through a lot of tweaking) confirmed that is exactly what is happening.

Here is the 'real' problem.

Dues::Status should get a value of 'Late' or 'Current' depending on the DUES::PAIDYEAR value. (IF PAIDYEAR<year(get(CurrentDate)) then Dues::Status="Late".

I am doing a report to show all the "Late" and "Current" members.

Also, I need the ability to glance at a Member record and see in the 'summary' section their name, address...etc. along with their Members::Status (Deceased, Suspended ...etc) and their Dues::Status("Late" or "Current).

One weird thing is that I can watch a script that works as expected but as soon as I click out of the portal ... ba boom... new portal row?????

[ron G]

LaRetta,

Am I correct in thinking that the solution to the problem is to create a field in Members::DuesStatus which could then be put in place of Dues::Status?

Thank you

[LaRetta]

One weird thing is that I can watch a script that works as expected but as soon as I click out of the portal ... ba boom... new portal row? ? ???

If you have Allow creation set to on for that portal, you will always get a new row - that is standard behavior - but you haven't even said whether Allow Creation is on!? There is no ba boom script-step and things don't 'just happen.' You are not providing enough information for me to help you, Ron.

Would you be willing to zip and attach your file? If not here then in a private message to me? I simply can't continue a conversation based only upon speculation; that is not how my mind even works. Produce the file or produce a demo re-creating the issue, okay? :yep:

[ron G]

Hi LaRetta,

When you said: "If you have Allow creation set to on for that portal, you will always get a new row - that is standard behavior"... I came to the realization that just because I was setting the Dues (The 'many' table) field that was NOT on the portal didn't mean that would not trigger a new Dues record.

I ASSUMED (oops...we know where that goes) that if the target field was NOT on the portal it would not trigger a record CREATION.

I tweaked the system and it looks like that is exactly what is happening.

So, I just added a Members::DuesStatus field to collect the Dues Status (Current or Late) and everything is working wonderfully.

In the best of all worlds, I would have kept DUES::DuesStatus in the Dues table. And I suspect that it is the best Relational Design if I could do that. (Keeping Dues AND their STATUS in the same table).

It seems that FM could tweak the "Allow Creation" feature to either ALWAYS create or create only when a field in the portal is updated. What do you think?

Anway, after many days of trying to figure this thing out, it was YOU who turned on the light for me so that I could find my way to a solution. THANK YOU VERRRRRY MUCH!!!

Much appreciation

Ron

[LaRetta]

Hi LaRetta,

... I came to the realization that just because I was setting the Dues (The 'many' table) field that was NOT on the portal didn't mean that would not trigger a new Dues record.

I ASSUMED (oops...we know where that goes) that if the target field was NOT on the portal it would not trigger a record CREATION.

Hi Ron,

Just to clarify, if you set a related field (any related field) outside of a portal while on a Parent, and if Allow Creation is on, then one of two things will happen:

• If there is a related record (or ANY related records) already, it will simply change the value on the first related record (according to the relationship sort order). A parent can only *see* the first related record unless a portal is used.
  
• If there is NO related record, setting the related value will create a new record.
  

But of course, why would you set a field in the related table unless you expected there to be a record already ... or unless you wanted to create a new record to then hold the value you are setting?

As for whether to use a Members::Status, I still do not have enough information to recommend. However, if all Dues must have a certain status before the Member Status can be 'current' then you can use a calculation in Members. This would not work if the Member can have different Status' which are assigned by Users. Not enough info to say more there. :)