Viewer Table

[Jorgitopeter]

Hi everyone. I write to ask you if you know any 'Viewer Table' tutorial... Because I found this kind of solution here

http://www.fmpro.org/news/246222632773/free-viewer-table-demo.html

and it seems to be pretty interesting, but I don't really undestand exactly how it is built.

So if you know any tutorial, please let me know!

Thanks for everything guys and girls.

[Fitch]

For anyone interested, the actual URL is:

http://www.foundationdbs.com/downloads.html

The file is unlocked, so you can see how it's built:

1. You click a contact name

2. The contact's ID is loaded into the "Edit ID" field

3. The fields on the layout lookup data from the contact table

After you edit the fields, the "Commit" button does the same thing in reverse (fields in Contacts do a Lookup from the Prefs table).

Seems like a lot of trouble to go through when you could just edit the related data directly (e.g. using a global field to drive the relationship), and then decide whether to commit it or not.

And by the way Jorgitopeter, did you click the "Annoted" tab? The tutorial you asked for is built right into the file!

[comment]

It's not just a lot of trouble to go through - it may not be such a good idea overall, as Ray explained here:

http://www.fmforums.com/forum/showtopic.php?tid/181617/post/227590/#227590

[Fitch]

Once again Ray focuses the issue like a laser beam. I especially enjoyed his series of causes/effects, it reminds me of the bit they do at the end of Lewis Blacks's Root of All Evil show where the comedians predict the future, but in Ray's scenario the outcome is more plausible and not so humorous:

8. On receiving the consultant's report, the company concludes that the system is flawed and terminates their relationship with the programmer who created their contacts database.

Edited May 9, 2008 by Guest
forgot to say thanks for the link, Michael.

[Jorgitopeter]

Hi, thanks for your answers... Yes, I click in the annoted layout, but I didn't get the 'table of preference' concept... anyway, Cologon's words persuaded me

Thanks for everything guys!

[jstaphse]

Now you guys got me curious.

I have attached a sample of what I'm in the process of using in a solution. Aside from the temporary ItemID not getting cleared when changing records, does this look like a viable way to edit data?

Sorry for the hijack and thanks for the help.

TestNavigation.zip

[comment]

does this look like a viable way to edit data?

Yes, if the question is in the context of the previous discussion. This is no different than editing the line items directly in the portal - both the parent invoice and the edited line item are locked. What is the problem that is being solved here?

BTW, by using another table with only a global to hold the LineItemID, you could edit the selected line item WITHOUT locking the parent invoice (essentially the same as going to the LineItems table and editing the record there). So two users could be editing two line items of the same invoice simultaneously. Whether this is a desirable feature or not remains debatable.

[jstaphse]

This was actually requested by the users to emulate the interface that the old software used.

In my opinion my sample is more about screen real estate than locking issues. The specifications in our records are numerous. Each portal row has a lot of fields from different tables. Using this technique it seems somewhat cleaner.

Thanks for the evaluation.