Go Premium for a chance to win a PS4. Enter to Win

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 477
  • Last Modified:

FM - Advice on Reporting vs. Using Lists

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
rvfowler2
Asked:
rvfowler2
  • 3
3 Solutions
 
Will LovingPresidentCommented:
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
 
North2AlaskaCommented:
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
 
Will LovingPresidentCommented:
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
 
rvfowler2Author Commented:
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
 
Will LovingPresidentCommented:
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

Keep up with what's happening at Experts Exchange!

Sign up to receive Decoded, a new monthly digest with product updates, feature release info, continuing education opportunities, and more.

  • 3
Tackle projects and never again get stuck behind a technical roadblock.
Join Now