Solved

FM - Advice on Reporting vs. Using Lists

Posted on 2011-03-09
5
468 Views
Last Modified: 2012-06-21
I am trying to get my boss off of lists and onto reporting as reporting seems to save fields.  In the lists that currently exist, for example, you can have 80 count fields and 80 summary fields, and 80 calc fields (e.g., % change from one total to another).  However, am I right in doing this.  What is the best practice?  Is it preferred to create a report rather than creating all these extra fields?  Also, I am having a hard time making calcs work in report (amount, count, and summary fields are easy).  Any general tips with that or should I provide an example?  (Or is this a different question)?
0
Comment
Question by:rvfowler2
[X]
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 3
5 Comments
 
LVL 25

Accepted Solution

by:
Will Loving earned 334 total points
ID: 35083535
I think the general answer is that yes, reporting is better than ever increasing number of fields and lists, that and proper structuring (or re-structuring) of the data so that it's more normalized and you are not constantly creating new fields in the same table for the different instances of the same data when that should properly be put into a related table (aka normalization). It can be tricky sometimes to figure out how to re-create your list once the data has been moved to a separate table but it's all doable.

If you are having problems with calculations, the quickest way to get help is to post an example file. It may take you a few minutes to setup, but it will save time in the long run for both you and whoever is trying to help you.
0
 
LVL 12

Assisted Solution

by:North2Alaska
North2Alaska earned 166 total points
ID: 35083608
I agree with willmcn.  NOTHING can overcome a bad design.  I find I spend a good amount of my time with the design.  More than once I've been involved with trying to work around a poor design only to either take more time with work arounds, etc or simple just failing and having to redesign the whole project.  Put the effort upfront and you will be rewarded in the long run.
0
 
LVL 25

Assisted Solution

by:Will Loving
Will Loving earned 334 total points
ID: 35083946
I heartily second what North2Alaska said. I regularly do conversions from FileMaker Pro 6 where every table is a separate file. In most instances, I convert these systems to a one or two file system which involves a lot of work for no immediate obvious gain to the end user other than that it opens faster. However, the "re-design" of merging all the tables, scripts, value lists, users and file references together makes any future work so much easier. Any design decision must be based on asking yourself and the end-users a series of questions to elicit how they think about and use the data and to anticipate how things might be better managed. I often find myself saying, "well, we could do it that way (the old way), but how about if we did it THIS way which might make things easier for everyone in the long run..." It's those questions about workflow and what someone really needs/wants to see (rather than what they are currently accustomed to doing) that will help answer your design questions (and sometimes make people want to kiss your feet when you're done because you've made things so much easier...)
0
 
LVL 2

Author Closing Comment

by:rvfowler2
ID: 35084719
Thanks, that's what I thought.  Unfortunately, I walked into a situation that was first designed in FM 7 years ago.  We have about 12 databases and since I wasn't allowed training until October, that was when I first discovered that seperate db files was not standard.  Just this next week I'll be trying my first merging of 2 db files.  I can see one other pair that will be easy, but after that, it will be a nightmare.  Each db has about 15-20 layouts, 100 scripts, and 200 fields.
0
 
LVL 25

Expert Comment

by:Will Loving
ID: 35084885
If you want to ask it as a separate question, I can give you some very explicit steps for merging separate files. It was one of the major issues after FM7 came out and we worked out a reliable series of steps that generally keeps breakage at a minimum.
0

Featured Post

[Webinar] How Hackers Steal Your Credentials

Do You Know How Hackers Steal Your Credentials? Join us and Skyport Systems to learn how hackers steal your credentials and why Active Directory must be secure to stop them. Thursday, July 13, 2017 10:00 A.M. PDT

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Conversion Steps for merging and consolidating separate Filemaker files The following is a step-by-step guide for the process of consolidating two or more FileMaker files (version 7 and later) into a single file with multiple tables. Sometimes th…
Having just upgraded from Filemaker 11 to Filemaker 12 over the weekend, we thought we would add some tips for others making the same move.  In general, our installation went without incident. Please note that this is not a replacement for Chapter 5…
Add bar graphs to Access queries using Unicode block characters. Graphs appear on every record in the color you want. Give life to numbers. Hopes this gives you ideas on visualizing your data in new ways ~ Create a calculated field in a query: …
Visualize your data even better in Access queries. Given a date and a value, this lesson shows how to compare that value with the previous value, calculate the difference, and display a circle if the value is the same, an up triangle if it increased…

623 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question