2 Portal Bugs... is there something wrong?

[netcode]

I have noticed 2 things with a portal that seem to be acting as if there is a bug, however I could be doing something wrong. So I am looking for input. The following is my situation.

I have two tables that are related through a field called "ActiveContractID". In the first table (the table being browsed) the field is a calculation as follows:

Case (

ActiveContractName = "AFF" ; AFF_ContractID;

ActiveContractName = "VF" ; VF_ContractID;

ActiveContractName = "SP" ; SP_ContractID;

ActiveContractName = "FIAV" ; FIAV_ContractID;

ActiveContractName = "alFresco" ; AlFresco_ContractID;

ActiveContractName = "Inspired Doc" ; ID_ContractID;

ActiveContractName = "Inspired Music" ; IM_ContractID;

ActiveContractName = "Inspired Script" ; IS_ContractID;

ActiveContractName = "Short Film Face Off" ; SFFO_ContractID;

)

Each of those ContractID fields holds the appropriate ID of the contract.

Then I have a radio button field on my layout that displays data from "ActiveContractName".

Essentially when you click on the radio button it will change the contract (change the info in the portal).

HOWEVER, if I change the active contract, edit some information in the portal and then change back to a different contract the information from the previous contract stays in the portal.... UNTIL you click the radio button again, then it changes.

EDIT** Noticed that this only happens if the portal is still selected. If you click on another object before clicking the radio button the portal will change like it should.

Thats the first bug I noticed. The second is as follows:

When using a pop-up menu in a portal if you choose an item in the pop-up menu in a new record in the portal that item seems to float above everything when you scroll up and down. So if you choose something in the pop-up menu and scroll back up the text of that item will float over all objects.

Let me know if you have experienced any of these or if you have any input.

Thanks :

Edited February 17, 2009 by Guest

[IdealData]

Try the Records > Refresh Window option.

[Søren Dyhr]

Thats the first bug I noticed.

It's not a bug, but expected behaviour only by applying event trigger plugins or an upgrade to fm10 will make this happen:

http://www.kevinfrank.com/download/2009/dwindling-value-lists.zip

But as such is your problem down to an inadquate normalization, the popup needs to be a genuine data field not a result of a calc and the relational linking should not be a humanreadable value, examine how valuelist can be build to show data from other tables instead. Alternatively to the popup could a portal where selections are made by clicking at the line:

http://fmforums.com/forum/showpost.php?post/265338/

--sd

[netcode]

But as such is your problem down to an inadquate normalization, the popup needs to be a genuine data field not a result of a calc and the relational linking should not be a humanreadable value, examine how valuelist can be build to show data from other tables instead. Alternatively to the popup could a portal where selections are made by clicking at the line

The popup already does use a value list that pulls its data from a field. Its just the relationship changes based on a calculation. The actual data is not the result of a calculation. And the relationship between the items in the portal and the contract is not human readable, its an ID #

I would like to continue working this out with you, your help is appreciated.

Anyone else ever experienced this problem with popups in portals?

The only data not being updated when the "ActiveContractID" changes (changing the relationship) is the data in the portal. And soon as I click outside of the portal it updates, it just acts so much like a bug

Edited February 25, 2009 by Guest

[netcode]

Concerning the 2nd bug that I was talking about (which really isn't the biggest concern for me) here are some screen shots.

The first screen shot

You see here that the first item in the portal has the category of web banner. This was selected from the popup menu.

The second screen shot

Now you see here when scrolling down through the portal the data from the category popup menu floats through the portal. I have circled it in red.

[Søren Dyhr]

I would like to continue working this out with you, your help is appreciated.

Do you use any calc'fields at all, on if .... what if you replace their values with Set Field[ will the bug prevail then??? The Case( statement looks as if!

Try to show me an image of your relational graph, my guess is that it might have something to do with it!

--sd

[netcode]

Thanks for the response!

I use a calc field to determine the relationship between "Sponsors" and "Contracts". Why I did this was because there are multiple contracts for each sponsor (one sponsor PER contract however) and I wanted the users to have control over what one they are viewing by using a radio button which controls the field "ActiveContractName" and you will see that in the Case function which changes the field "ActiveContractID" to the appropriate contract ID. The ID's are found in, for example, the field "AFF_ContractID".

Here I will add a screen shot of the relationship diagram.

The forums might resize it so here is the link:

http://www.atlanticfilm.com/filemaker/RelationshipDaigram.jpg

Hope this helps. I would love to get to the bottom of this because how I see it, it SHOULD work.

Again it only seems to do it if the portal is in focus.

Anyways take a look let me know what you find out :

[Søren Dyhr]

I managed to get it enlarged, but could I ask you a small favour? Could you colour code the TO's sharing same tables ... an explain why everything is interconnected, and not anchor buoyed/squitted?

_____________________________

I have meanwhile since I wrote the above tinkered with a file, showing how I would achieve the functionality you're wishing for....

--sd

sponsors.zip

[netcode]

an explain why everything is interconnected, and not anchor buoyed/squitted?

I do not know what you mean by anchor buoyed/squitted, sorry.

I have attached the file with color coded tables that share the same table. I also wrote a note below explaining the tables that are outlined by the purple line. Anyways hope this helps. Glad to be making progress on this :

http://www.atlanticfilm.com/filemaker/RD-Color.jpg

*Note the group of tables that are outlined by pink. That is basically the same set of tables. However note the multi criteria relationship with the field "archive". Basically this set of tables is used as an archive. When someone clicks (on the layout) a button called archive it sets the field "archive" in the contracts table to 1 and therefore creates a relationship with the sponsor, these contracts that are archived are shown in a tab called "history" and the active ones are not. Anyways that isn't the focus of this, just thought I would give you some background about that part of the database.

[Søren Dyhr]

When someone clicks (on the layout) a button called archive it sets the field "archive" in the contracts table to 1 and therefore creates a relationship with the sponsor

It was the part I allready have sussed the flow of tables in, and to what I've made another suggestion for - could I ask for universally colouring not just two brances.

Back to Anchor/Bouying the basic idea is only to include tables and relations belonging to one single layout at a time.

Try to read this to learn the distinction between TO's and TOG's, and first and foremost that the filemaker graph implementation isn't an entity relations diagram, there is absolutely no need to knit everything tightly to one single yarn to make a solution.

http://www.fmp.it/download/files/FM7_key_concepts.pdf

Take a look at my fast muckup of the template I just made you, here making yet another layout for showing a different aspect using exactly the same tables but a tad different, but again the double or selfjoin where the second steps records are tunneled.

--sd

[netcode]

I now see what you mean.

However even if I separate the two, and create two different TOG's it still does the same thing. The portal will not update the data when the relationship is changed until I click outside of the portal.

I think I have another solution.

That solution is to script a button that will change the ID # and then do a go to object script step so that the portal data will update. Simply just automating the action of someone clicking outside the portal.

**EDIT** Just implemented that go to object script step on the button... guess what, doesn't work! Ahhhhh!

Nothing will work unless you manually click on another object, once you click on another object the data will change in the portal. So strange... so so so strange.

Anyways here are some pictures that will explain better my situation I think.

Here is the relationship graph. I have removed everything else so we can focus on this relationship.

As you see "Contracts" and "Sponsors 2" are connected through the "ActiveContractID" in the sponsors table and "ContractID" in the contracts table.

Now the layout...

Ok this isn't a screenshot of the actual layout but it shows my layout. As you can see the portal is showing records from the "Benefits" table.

Now the buttons there labeled "Contract 1" and "Contract 2" will change the field "ActiveContractID" and change the relationship between sponsors 2 and contracts, hence changing the related benefits.

However the data in the portal will not change until you manually click on the layout somewhere. Thats where the problem is... once the data changes the data is correct. So everything is fine structurally.

Edited February 27, 2009 by Guest

[Søren Dyhr]

Have you investigated my template at all?

I will still maintain that it isn't a bug but what you need to instate is some trigging mechanism to deal with a calc'field which needs to act as relational key ... what I did was to move the global field as well as calc' to the table where the selection needs to be made, hence the use of a selfjoin here!

With fm10 can a script be trigged elsewhere this is why originally linked to Kevin Franks template which executes a Flush Cache To Disk ... it's not a bug but an expected behaviour, the reason why you expect otherwise must be a lent assumption from ar spreadsheet metaphor or such?

The reason why databases do not exhibit such behaviour is that it's deployable in a multiuser scenario as well, if such calc'ed changes should be in charge of dynamic linking, would it cause even more chatter over a networked solution ... where all attempted limitations to bandwith hogging are avoided if possible.

I might put things a bit in perspective, that filemaker is quite unique by providing calc'fields at all. Everywhere else are script trriggers loaded with scripts performing the needed calculations.

Please read Ilyse Kazars chapter on record ownership in a multi user scenario:

http://www.filemaker.com/downloads/pdf/techbrief_fm8_migrtn_found.pdf

BTW how do your fields here get their values:

AFF_ContractID;

VF_ContractID;

SP_ContractID;

FIAV_ContractID;

AlFresco_ContractID;

ID_ContractID;

IM_ContractID;

IS_ContractID;

SFFO_ContractID

If they're the result of calculations derived a relation or more away is it beginning to make sense why you find this buggy - it is unfortunately so that unstored calc'fields which are out of sight from a screen rendering ...perhaps surprisingly not holds any value at all until being brought to a surface/layout!

http://fmforums.com/forum/showpost.php?post/244114/

--sd

[netcode]

I did investigate it, implemented it, and the portal continued to do the same thing.

The reason why databases do not exhibit such behaviour is that it's deployable in a multiuser scenario as well, if such calc'ed changes should be in charge of dynamic linking, would it cause even more chatter over a networked solution ... where all attempted limitations to bandwith hogging are avoided if possible.

I even changed the field to a Number. used a button to change the number in the field. And the portal still showed the same issue.

Are dynamic relationships even possible without the use of plugins?

Maybe dynamic relationships are not the solution in the first place and maybe I should be thinking of another solution?

And all those ID fields get their value from a script triggered by a button called create new, then the user chooses the type of contract and the record is created in the contracts table and then that # is put into the appropriate field depending on which type of contract they have created.

Edited February 27, 2009 by Guest

[Søren Dyhr]

And all those ID fields get their value from a script triggered by a button called create new, then the user chooses the type of contract and the record is created in the contracts table and then that # is put into the appropriate field depending on which type of contract they have created.

So each contact is an either/or and not a "both" as I had in my template.

Are dynamic relationships even possible without the use of plugins?

Havn't I just showed you in my template how it could be done? If you should choose to set the cathegory by script or by a radio button can't really give diverse results? It's pretty dynamic, but what's really dynamic in your case?

Try to investigate the templates showing up when making a quicksearch here in this forum - puttin in:

"ugo's method"

Perhaps in particular this thread: http://fmforums.com/forum/showtopic.php?tid/189946/post/266228/#266228

--sd

[netcode]

A contract cannot be archived and be active at the same time.

However there are multiple active contracts. (ps we are talking contracts, not contacts)

Havn't I just showed you in my template how it could be done? If you should choose to set the cathegory by script or by a radio button can't really give diverse results? It's pretty dynamic, but what's really dynamic in your case?

Yes I see how yours is dynamic, so is mine. Creating a relationship that is dynamic is not the problem (ya I don't really know why I even asked that question in the first place, guess it was to get an official statement if it is supposed to be possible). The relationship is fine, its the data in the portal that doesn't update that is my problem. Any data that is NOT within the portal, yet still comes from the relationship WILL update, however data in the portal won't until I click somewhere else in the layout.

Maybe if I just send you the file, and you actually saw the problem you might have a better understanding. If you want to do this I would rather send you the file privately, just in case, these forums are open to the public.

Let me know and I can set you up with the file in the next few days. I am at home now and not at the office.

[Søren Dyhr]

Although we debate this in private as well might it be beneficial for others to understand the struggles involved here!

I have indeed been wondering what it was that bothered you, and have now learned that your otherwise fairly well normalised solution. That the expectations to behaviour fails by not really recognising the facts that this thread is about:

http://www.fmforums.com/forum/showtopic.php?tid/198567/

What we have in your solution is that changing a primary key makes the first link update or refresh but not the following relational step without issuing such as a "Flush Cache to Disk" ... but this is not a bug, because deep relational dependencies are skipped/shortcut deliberatly becasue other means exists!

... here is it just tying the join table to the changing key field instead and then have another TOG for making the creation of join table records. The above graph shows how it would make sense to decompose your graph from:

http://fmforums.com/forum/showpost.php?post/318677/

--sd