This topic is locked

case where list detail records don't show (2)

9/1/2011 9:42:32 PM
PHPRunner General questions
E
electromotive author

Refer to http://www.asprunner.com/forums/topic/14926-case-where-list-detail-records-dont-show/
Just a followup. Did this get resolved or implemented in 7474?

Sergey Kornilov admin 9/2/2011

electro rick,
this weren't fixed in version 5.3. In fact this is a "feature" or rather a design limitation. To overcome this PHPRunner needs to create a different set of table session variables for each way you can access this table (directly or via master-details).
The solution is to prevent a direct access to details table (removing it from the menu will do the job). If you still need to do that - create a custom view on the top of details table and use it for direct access purposes.
Hope this makes sense.

E
electromotive author 9/6/2011



electro rick,
this weren't fixed in version 5.3. In fact this is a "feature" or rather a design limitation. To overcome this PHPRunner needs to create a different set of table session variables for each way you can access this table (directly or via master-details).
The solution is to prevent a direct access to details table (removing it from the menu will do the job). If you still need to do that - create a custom view on the top of details table and use it for direct access purposes.
Hope this makes sense.


I understand what you are saying. I guess this is (should be) a design rule.

I wish we had a simple two-tier schema. But in building moderately complex hierarchical or network relationships, we have relationships with 3 or more tiers.

.....->M2-D4

..........|

..........v

->M1-D1-D2-D3

..........^...^

..........|...|
Sorry about the gimpy drawing. Front office users might come via M1 or M2, back office users would come in via D1 or D2

Where the various types of users need to come in depends on what their job is. Some people do both front and back office jobs. I can see how to add views to D1 & D2 to prevent direct access. Getting to D3 would be a link from vD2.

I wish I fully understood this a year ago <img src='https://asprunner.com/forums/file.php?topicimage=1&fieldname=reply&id=60688&image=1&table=forumreplies' class='bbc_emoticon' alt=':)' /> It makes perfect sense.

I already have lots of views, the views will be outnumbering the tables. Some views are in the database and some are in PHPR.
There are only a few what you might call true masters. But dozens of details. A unique customer might be a true master. A job on the other hand is a pseudo master, as a job is always associated with a customer in our case. But for people working on the job, they don't care about the customer, or come in via customer, they just come in via queued and unfinished jobs. I'll create a view for the jobs, so if they also need to answer a customer inquiry, the filter they had on V_jobs won't apply when they look at jobs-details under a customer.
I guess it doesn't matter which gets the view? The detail or the pseudo master? As long as they have different session_variables..

Sergey Kornilov admin 9/7/2011

If I understand your question right - it doesn't matter. As long as they are different entities they have they own set of session variables and won't interfere.