Layout sub-summary totals disappear in table view

August 23, 200916 yr

The following article describes a similar problem when trying to add fields to the table view of a layout:

http://forum-en.filemaker.com/fm/board/message?board.id=aut&thread.id=3084

(see posts toward the bottom of the article)

There appears to be a limit on the number of fields that can be displayed in table view. My problem is that I am trying to add some sub-summary fields to a layout that disappear when I add additional fields to my layout.

For instance I added the sub-summary fields and noticed that they would not show up in table view. I read the above article, which addresses the limitation, and by their example, deleted (temporarily) a good number of fields from my layout. Then the sub-summary appear and it appears to solve my problem.

However, when I add back the deleted fields to my layout - the sub-summary fields no longer appear.

Any ideas?

August 24, 200916 yr

Why not use list view?

August 24, 200916 yr

Author

There are various reasons that I am looking at switching from list view to table view (among them is that you have to maintain an additional layout for list view). Also see article: http://tokerud.typepad.com/filemaker/2009/02/filemaker-10-subsummaries-in-table-view-part-2.html

Any ideas on a table view solution?

August 24, 200916 yr

among them is that you have to maintain an additional layout for list view

As I told you yesterday is it just about the worst argument for it, only fools put an abundance of summary fields on a layout dedicated for data entry. Janets point is much better, you can effordless change groupings of data dynamicly....

One of my practices in building FileMaker systems is to have a list screen for every table in the database. I've used the List View for these so that I could label my columns the way I wanted. However, I may be replacing the list screens with my new Table Views because they are so much more dynamic and useful for quick analysis and reporting

--sd

August 24, 200916 yr

Author

I don't think I understand what you are saying. I hope you are not saying that I am a fool.

In any event, if you have an answer pertaining to a Table view solution, please respond. If not, start your own thread.

August 24, 200916 yr

We're not given all the fatcts to establish if you really should be a fool, but I find it hard to imagine a view with more than the 66 fields.

http://www.smallco.net/RestrainYourself.pdf

You have started this thread wrongly by assuming abstract generalised questions would get you anywhere, we have all from time to time been stumbling over cool techniques we then utilize until the threshold of wommiting.

Anyone would beat around the bush, making sporadic attempts to help you, but without a concise description of context and purpose is this thread pure entertainment!

Why is the number of fields so high and have you chosen the right tool at all?

Has this anything to do with eyeballing a pattern by making columns single pixel wide, to make them invisible for a short while?

--sd

August 24, 200916 yr

Author

Some of the fields are buttons used to control the user's access to certain functions. But it doesn't matter what is my motivation or my sanity - does anyone have have a solution to the table view problem?

August 24, 200916 yr

Well I have ... before fm10 did dynamic reporting rely on:

http://fmhelp.filemaker.com/fmphelp_10/en/html/func_ref3.33.7.html

...and a handfull of global fields as argument for the functions used. Hovering above in the header of an ordinary Listview as Vaughan suggested. Even the breaker field is derived by either GetField( or Evaluate(

But it takes some tinkering to get it working, but say you wish to dynamic report upon 6 arbitrary chosen fields then do you need 6 globals and a squid of relations from each of these global fields .... but why not read about it in:

http://books.google.com/books?id=L3qfayrqJ1oC&pg=PA398&lpg=PA398&dq=filemaker+customize+list+report&source=bl&ots=ufwLRsXYIK&sig=0uFUSe4wGZqK1p1rkHCS5pH_JcI&hl=da&ei=zqGSSrHnBs7b-Qae7_TyDQ&sa=X&oi=book_result&ct=result&resnum=1#v=onepage&q=filemaker%20customize%20list%20report&f=false

--sd

August 24, 200916 yr

you do not know whether table view is unacceptable in his (or anyone elses) situation. Your wording is borderline rude.

I would start to appologize if it came out as more than banter! But I know that an abundance of summary fields on a layout not are in the book of best practices of filemakery. Similar do I know that expressing a wish like this:

But it doesn't matter what is my motivation or my sanity

...largely are contradicted by this:

Answering the question as asked is often not providing a solution to the real problem behind the question

--sd

August 24, 200916 yr

Dynamic reporting? Then maybe I'm confused ... who says a summary field has to mean complexity? A summary field placed in a table view can total the current record set, count them and may things!

Neither did I know this ...until a week ago, but yes grouping takes place as well if part definitions exists on a layout dedicated for table view. Look at Janets blog!

But there is at least not in her text catered for merging layouts for input and layouts made for reporting. The problem here is a slight double posting:

http://fmforums.com/forum/showtopic.php?tid/210787/post/339027/#339027

--sd

August 24, 200916 yr

Author

I very much appreciate LaRetta's input.

1. Regarding: Tom, are you then taking a form view and turning it into table?

Yes.

2. Regarding: Because fields can't be buttons in table view.

It appears that the buttons can't be used in the body of table view but they do show up in the body table view and take up enough space to make the sub-summary fields disappear. It looks like when I paste back the deleted fields (many are buttons) they bump the sub-summary fields off of the table view. Even if I uncheck the unwanted fields using the modify button - the sub-summary fields do not reappear. If I delete the unwanted fields again, the sub-summary fields reappear.

3. Regarding: Are you building in vs. 10 now?

Yes.

4. Regarding: Is there any way you can attach a file?

Let me see if I can duplicate it outside my app. I thought I would get the rest of the information to you first.

5. Regarding: I wondered if stacking order or changing the column order would make a difference.

See item 2.

Again, thanks for your help.

August 24, 200916 yr

who said there was an 'abundance' of summary fields? Again, you know nothing of the situation!!!

If there is intensive use of Janets approach will there be three appearances for each field (well two and the occational summaryfield), hogging the maximal number of fields visible in tableview pretty fast, if 66 is the upper limit would that give a max of 22 fields and similar occurences of the summary field and what if both counts and summings takes place?

The phenomena experienced is that these 66 are reached somehow... making the latest incarnations of the summary field be left out.

--sd

August 24, 200916 yr

But have somewhere in the two threads seen Tom declare context and purpose, this is what bores me - to drag it out of the OP!

All tools have thier week spots, and David Kachel warns us about the cute and clever, because it oftentimes pulls the tool out of it realm and does something remarkable else.

The question is why Tom have thrown his love on this particualr feauture, is his data monging scientific or is it data mining for a warehouse. Databases are vessels of meaning but rearranging data until a pattern occures when eyeballing say around a pencil or spotting something interesting in the remains of a türkish coffee, could be that the requester of the pattern leans over until it fits. Are we fortune telling here?

--sd