|
»
»
»
Aggregating numbers from different tables
|
View:
New views
20 Messages
—
Rating Filter:
Alert me
|
| < Prev | 1 - 2 | Next > |
 |
Aggregating numbers from different tables
by peleve
::
Rate this Message:
I have several tables that create cost($) related numbers and which include the following fields: dollar amount, cost category, number of months from the beginning of the job
I would like to aggregate this information (the three fields) into a single table then do a find for a specific cost category and export or graph the resulting $ vs. Time for that category. Note that I need to be able to aggregate for a particular month and category costs that may come from different tables. In other words the cost for a month may consist of the sum of several values from different tables. I'm struggling with a method for how to do that. Can anyone point me towards an approach? Thanks. |
|
|
Re: Aggregating numbers from different tables
by Lorne & Joan Walton
::
Rate this Message:
Why are these figures coming from different tables? Have you
considered merging all of your dollar data into a single table? It would make your life much easier... please tell us why you can't. On Jul 5, 2008, at 9:03 PM, peleve wrote: > Note that I need to be able to aggregate for a particular month and > category > costs that may come from different tables. In other words the cost > for a > month may consist of the sum of several values from different tables. -- Some day your ship will come in, but you'll be at the airport. Lorne Walton, Maple Ridge, BC, Canada _______________________________________________ FMPexperts mailing list FMPexperts@... http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au |
|
|
Re: Aggregating numbers from different tables
by peleve
::
Rate this Message:
The dollar data are generated in different ways. In one table they
are imported from a file, in another they are calculated based on various conditions. Some dollar data are expenses, other are income. It's more for the convenience of keeping various types of data separate. Peter Versteegen pversteegen@... On Jul 6, 2008, at 1:05 AM, Lorne & Joan Walton wrote: > Why are these figures coming from different tables? Have you > considered merging all of your dollar data into a single table? It > would make your life much easier... please tell us why you can't. > > On Jul 5, 2008, at 9:03 PM, peleve wrote: > >> Note that I need to be able to aggregate for a particular month and >> category >> costs that may come from different tables. In other words the cost >> for a >> month may consist of the sum of several values from different tables. > > -- > Some day your ship will come in, but you'll be at the airport. > Lorne Walton, Maple Ridge, BC, Canada > > _______________________________________________ > FMPexperts mailing list > FMPexperts@... > http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au > _______________________________________________ FMPexperts mailing list FMPexperts@... http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au |
|
|
Re: Aggregating numbers from different tables
by Ernest Koe
::
Rate this Message:
In general, you can use variables in scripts to store data
temporarily. Typically, with this sort of problem, I store gather all my separate bits of data in various variables and then write them back out at the end of the process. One tip: you can store data in 'indexed' variables, that is using another variable to indicate which repetition of the variable in which you'd like your data to be stored. For month based operations, it is often convenient to store data in variables indexed to the month, for example: $category[$n] where $n = {1,2,3,4,5,6,7,8,9,10,11,12} such that $category[1] = "20" $category[2] = "34" ... $category[12] ="4" Hope this helps. On Jul 6, 2008, at 12:03 AM, peleve wrote: > > I have several tables that create cost($) related numbers and which > include > the following fields: dollar amount, cost category, number of months > from > the beginning of the job > > I would like to aggregate this information (the three fields) into a > single > table then do a find for a specific cost category and export or > graph the > resulting $ vs. Time for that category. > > Note that I need to be able to aggregate for a particular month and > category > costs that may come from different tables. In other words the cost > for a > month may consist of the sum of several values from different tables. > > I'm struggling with a method for how to do that. Can anyone point me > towards > an approach? > > Thanks. > -- > View this message in context: http://www.nabble.com/Aggregating-numbers-from-different-tables-tp18298654p18298654.html > Sent from the FMPExperts mailing list archive at Nabble.com. > > _______________________________________________ > FMPexperts mailing list > FMPexperts@... > http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au _______________________________________________ FMPexperts mailing list FMPexperts@... http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au |
|
|
Re: Aggregating numbers from different tables
by Lorne & Joan Walton
::
Rate this Message:
I understand. But in another sense, they are all the same kind of data
- at least in my mind - or else you wouldn't have the need to summarize them in a single table...? On Jul 6, 2008, at 5:11 AM, Peter L Versteegen wrote: > The dollar data are generated in different ways. In one table they > are imported from a file, in another they are calculated based on > various conditions. Some dollar data are expenses, other are > income. It's more for the convenience of keeping various types of > data separate. -- Why should I care about posterity? What's posterity ever done for me? [Groucho Marx] Lorne Walton, Maple Ridge, BC, Canada _______________________________________________ FMPexperts mailing list FMPexperts@... http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au |
|
|
RE: Aggregating numbers from different tables
by John Weinshel
::
Rate this Message:
The repeaters part is really sweet, Ernest.
John Weinshel Datagrace Vashon Island, WA (206) 463-1634 Member, FileMaker Business Alliance Certified For FileMaker 8 Certified For FileMaker 7 -----Original Message----- From: fmpexperts-bounces@... [mailto:fmpexperts-bounces@...] On Behalf Of Ernest Koe Sent: Sunday, July 06, 2008 5:16 AM To: fmpexperts@... Subject: Re: Aggregating numbers from different tables In general, you can use variables in scripts to store data temporarily. Typically, with this sort of problem, I store gather all my separate bits of data in various variables and then write them back out at the end of the process. One tip: you can store data in 'indexed' variables, that is using another variable to indicate which repetition of the variable in which you'd like your data to be stored. For month based operations, it is often convenient to store data in variables indexed to the month, for example: $category[$n] where $n = {1,2,3,4,5,6,7,8,9,10,11,12} such that $category[1] = "20" $category[2] = "34" ... $category[12] ="4" Hope this helps. On Jul 6, 2008, at 12:03 AM, peleve wrote: > > I have several tables that create cost($) related numbers and which > include > the following fields: dollar amount, cost category, number of months > from > the beginning of the job > > I would like to aggregate this information (the three fields) into a > single > table then do a find for a specific cost category and export or > graph the > resulting $ vs. Time for that category. > > Note that I need to be able to aggregate for a particular month and > category > costs that may come from different tables. In other words the cost > for a > month may consist of the sum of several values from different tables. > > I'm struggling with a method for how to do that. Can anyone point me > towards > an approach? > > Thanks. > -- > View this message in context: 8298654.html > Sent from the FMPExperts mailing list archive at Nabble.com. > > _______________________________________________ > FMPexperts mailing list > FMPexperts@... > http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au _______________________________________________ FMPexperts mailing list FMPexperts@... http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au _______________________________________________ FMPexperts mailing list FMPexperts@... http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au |
|
|
Re: Aggregating numbers from different tables
by peleve
::
Rate this Message:
That's true. But in one database I have a whole set of different
fields that calculate the dollar data, and in another table again with another completely different set of fields to compute the same type of dollar data. Putting both in the same table would be possible but is not natural. I'll have to manage several disjointed data sets. Peter Versteegen pversteegen@... On Jul 6, 2008, at 11:26 AM, Lorne & Joan Walton wrote: > I understand. But in another sense, they are all the same kind of > data - at least in my mind - or else you wouldn't have the need to > summarize them in a single table...? > > On Jul 6, 2008, at 5:11 AM, Peter L Versteegen wrote: > >> The dollar data are generated in different ways. In one table they >> are imported from a file, in another they are calculated based on >> various conditions. Some dollar data are expenses, other are >> income. It's more for the convenience of keeping various types of >> data separate. > > -- > Why should I care about posterity? What's posterity ever done for > me? [Groucho Marx] > Lorne Walton, Maple Ridge, BC, Canada > > _______________________________________________ > FMPexperts mailing list > FMPexperts@... > http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au > _______________________________________________ FMPexperts mailing list FMPexperts@... http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au |
|
|
Re: Aggregating numbers from different tables
by peleve
::
Rate this Message:
I see your plan. I'll have to try this out. I haven't worked
variables much. Thanks, Pete On Jul 6, 2008, at 8:16 AM, Ernest Koe wrote: > In general, you can use variables in scripts to store data > temporarily. Typically, with this sort of problem, I store gather > all my separate bits of data in various variables and then write > them back out at the end of the process. > > One tip: you can store data in 'indexed' variables, that is using > another variable to indicate which repetition of the variable in > which you'd like your data to be stored. For month based operations, > it is often convenient to store data in variables indexed to the > month, for example: > > $category[$n] > > where $n = {1,2,3,4,5,6,7,8,9,10,11,12} > > such that > $category[1] = "20" > $category[2] = "34" > ... > $category[12] ="4" > > Hope this helps. > > On Jul 6, 2008, at 12:03 AM, peleve wrote: > >> >> I have several tables that create cost($) related numbers and which >> include >> the following fields: dollar amount, cost category, number of >> months from >> the beginning of the job >> >> I would like to aggregate this information (the three fields) into >> a single >> table then do a find for a specific cost category and export or >> graph the >> resulting $ vs. Time for that category. >> >> Note that I need to be able to aggregate for a particular month and >> category >> costs that may come from different tables. In other words the cost >> for a >> month may consist of the sum of several values from different tables. >> >> I'm struggling with a method for how to do that. Can anyone point >> me towards >> an approach? >> >> Thanks. >> -- >> View this message in context: http://www.nabble.com/Aggregating-numbers-from-different-tables-tp18298654p18298654.html >> Sent from the FMPExperts mailing list archive at Nabble.com. >> >> _______________________________________________ >> FMPexperts mailing list >> FMPexperts@... >> http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au > > _______________________________________________ > FMPexperts mailing list > FMPexperts@... > http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au > _______________________________________________ FMPexperts mailing list FMPexperts@... http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au |
|
|
Re: Aggregating numbers from different tables
by Bart Bartholomay
::
Rate this Message:
Careful using this approach. It's one thing to temporarily store a
variable and totally another to use it in a more permanent way. Bart On Jul 6, 2008, at 4:06 PM, Peter L Versteegen wrote: > I see your plan. I'll have to try this out. I haven't worked > variables much. > > Thanks, > > Pete > > > On Jul 6, 2008, at 8:16 AM, Ernest Koe wrote: > >> In general, you can use variables in scripts to store data >> temporarily. Typically, with this sort of problem, I store gather >> all my separate bits of data in various variables and then write >> them back out at the end of the process. >> >> One tip: you can store data in 'indexed' variables, that is using >> another variable to indicate which repetition of the variable in >> which you'd like your data to be stored. For month based >> operations, it is often convenient to store data in variables >> indexed to the month, for example: >> >> $category[$n] >> >> where $n = {1,2,3,4,5,6,7,8,9,10,11,12} >> >> such that >> $category[1] = "20" >> $category[2] = "34" >> ... >> $category[12] ="4" >> >> Hope this helps. >> >> On Jul 6, 2008, at 12:03 AM, peleve wrote: >> >>> >>> I have several tables that create cost($) related numbers and >>> which include >>> the following fields: dollar amount, cost category, number of >>> months from >>> the beginning of the job >>> >>> I would like to aggregate this information (the three fields) into >>> a single >>> table then do a find for a specific cost category and export or >>> graph the >>> resulting $ vs. Time for that category. >>> >>> Note that I need to be able to aggregate for a particular month >>> and category >>> costs that may come from different tables. In other words the >>> cost for a >>> month may consist of the sum of several values from different >>> tables. >>> >>> I'm struggling with a method for how to do that. Can anyone point >>> me towards >>> an approach? >>> >>> Thanks. >>> -- >>> View this message in context: http://www.nabble.com/Aggregating-numbers-from-different-tables-tp18298654p18298654.html >>> Sent from the FMPExperts mailing list archive at Nabble.com. >>> >>> _______________________________________________ >>> FMPexperts mailing list >>> FMPexperts@... >>> http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au >> >> _______________________________________________ >> FMPexperts mailing list >> FMPexperts@... >> http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au >> > > _______________________________________________ > FMPexperts mailing list > FMPexperts@... > http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au _______________________________________________ FMPexperts mailing list FMPexperts@... http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au |
|
|
Re: Aggregating numbers from different tables
by Bruce Herbach
::
Rate this Message:
Hi Pete,
I didn't see which version of FM you are using, but in 8.5 and 9.x there are a couple of things you might find helpful. This may be true for earlier versions, but I haven't use the earlier versions much so can't say for sure. A variable starting with a single $ such as $cat has a scope of the local script. When the script ends the variable and it's value are gone. If you need to use the value in a sub script you have to pass it to the script as a parameter. A variable starting with two $ is global such as $$dog. A global variable is accessible and changeable by any script after it has been created. It will stay in existence until you close the database. This can be useful and possibly dangerous if modified by a subscript at the wrong time. There are many uses for global variables, one of these is tab control. I have used them in a multi-tab/level interface to have the navigation from a button/script return to the main screen and appropriate tab. They can be useful to pass information to sub scripts, but I prefer to pass the information explicitly. I hope this is helpful. Best regards Bruce Herbach
|
|
|
Re: Aggregating numbers from different tables
by James David Ramsey
::
Rate this Message:
Don't forget that "global" variablles (with "$$" at the beginning) are limited to the *file* that created them.
If you need to pass a value to a script in a different file, you'll have to use a script parameter or global field(s)... Dave Ramsey -----Original Message----- From: Bruce Herbach <sculler.b21@...> Date: Sun, 6 Jul 2008 14:41:36 To: <fmpexperts@...> Subject: Re: Aggregating numbers from different tables Hi Pete, I didn't see which version of FM you are using, but in 8.5 and 9.x there are a couple of things you might find helpful. This may be true for earlier versions, but I haven't use the earlier versions much so can't say for sure. A variable starting with a single $ such as $cat has a scope of the local script. When the script ends the variable and it's value are gone. If you need to use the value in a sub script you have to pass it to the script as a parameter. A variable starting with two $ is global such as $$dog. A global variable is accessible and changeable by any script after it has been created. It will stay in existence until you close the database. This can be useful and possibly dangerous if modified by a subscript at the wrong time. There are many uses for global variables, one of these is tab control. I have used them in a multi-tab/level interface to have the navigation from a button/script return to the main screen and appropriate tab. They can be useful to pass information to sub scripts, but I prefer to pass the information explicitly. I hope this is helpful. Best regards Bruce Herbach Bart Bartholomay wrote: > > Careful using this approach. It's one thing to temporarily store a > variable and totally another to use it in a more permanent way. > > Bart > > On Jul 6, 2008, at 4:06 PM, Peter L Versteegen wrote: > >> I see your plan. I'll have to try this out. I haven't worked >> variables much. >> >> Thanks, >> >> Pete >> >> >> On Jul 6, 2008, at 8:16 AM, Ernest Koe wrote: >> >>> In general, you can use variables in scripts to store data >>> temporarily. Typically, with this sort of problem, I store gather >>> all my separate bits of data in various variables and then write >>> them back out at the end of the process. >>> >>> One tip: you can store data in 'indexed' variables, that is using >>> another variable to indicate which repetition of the variable in >>> which you'd like your data to be stored. For month based >>> operations, it is often convenient to store data in variables >>> indexed to the month, for example: >>> >>> $category[$n] >>> >>> where $n = {1,2,3,4,5,6,7,8,9,10,11,12} >>> >>> such that >>> $category[1] = "20" >>> $category[2] = "34" >>> ... >>> $category[12] ="4" >>> >>> Hope this helps. >>> >>> On Jul 6, 2008, at 12:03 AM, peleve wrote: >>> >>>> >>>> I have several tables that create cost($) related numbers and >>>> which include >>>> the following fields: dollar amount, cost category, number of >>>> months from >>>> the beginning of the job >>>> >>>> I would like to aggregate this information (the three fields) into >>>> a single >>>> table then do a find for a specific cost category and export or >>>> graph the >>>> resulting $ vs. Time for that category. >>>> >>>> Note that I need to be able to aggregate for a particular month >>>> and category >>>> costs that may come from different tables. In other words the >>>> cost for a >>>> month may consist of the sum of several values from different >>>> tables. >>>> >>>> I'm struggling with a method for how to do that. Can anyone point >>>> me towards >>>> an approach? >>>> >>>> Thanks. >>>> -- >>>> View this message in context: >>>> http://www.nabble.com/Aggregating-numbers-from-different-tables-tp18298654p18298654.html >>>> Sent from the FMPExperts mailing list archive at Nabble.com. >>>> >>>> _______________________________________________ >>>> FMPexperts mailing list >>>> FMPexperts@... >>>> http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au >>> >>> _______________________________________________ >>> FMPexperts mailing list >>> FMPexperts@... >>> http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au >>> >> >> _______________________________________________ >> FMPexperts mailing list >> FMPexperts@... >> http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au > > _______________________________________________ > FMPexperts mailing list > FMPexperts@... > http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au > > -- View this message in context: http://www.nabble.com/Aggregating-numbers-from-different-tables-tp18298654p18306958.html Sent from the FMPExperts mailing list archive at Nabble.com. _______________________________________________ FMPexperts mailing list FMPexperts@... http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au _______________________________________________ FMPexperts mailing list FMPexperts@... http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au |
|
|
Re: Aggregating numbers from different tables
by Ernest Koe
::
Rate this Message:
Hi Peter,
To followup, I'd agree with you. I don't think what you are doing is particularly abnormal. It is possible that your data model isn't optimal but in general, FileMaker 9's native reporting abilities are limited to what you can do within the scope summary fields and summary parts. Stuff like cross-tabulation or pivot tables, aggregation of different data sets, taking 'snap-shots' of data and what-not require a bit of additional filemakery. One the things I do all the time is to create tables to represent reports (and charts) I want to display. That is to say, it is perfectly natural to use FileMaker tables to drive VIEWS of data in addition to STORING data. my 2 cents - Ernest Koe Proof Developers of fmSpark, a totally open, bolt-on mail-merge FileMaker application for your FileMaker databases. On Jul 6, 2008, at 4:04 PM, Peter L Versteegen wrote: > That's true. But in one database I have a whole set of different > fields that calculate the dollar data, and in another table again > with another completely different set of fields to compute the same > type of dollar data. Putting both in the same table would be > possible but is not natural. I'll have to manage several disjointed > data sets. > > > Peter Versteegen > pversteegen@... > > > > On Jul 6, 2008, at 11:26 AM, Lorne & Joan Walton wrote: > >> I understand. But in another sense, they are all the same kind of >> data - at least in my mind - or else you wouldn't have the need to >> summarize them in a single table...? >> >> On Jul 6, 2008, at 5:11 AM, Peter L Versteegen wrote: >> >>> The dollar data are generated in different ways. In one table >>> they are imported from a file, in another they are calculated >>> based on various conditions. Some dollar data are expenses, other >>> are income. It's more for the convenience of keeping various >>> types of data separate. >> >> -- >> Why should I care about posterity? What's posterity ever done for >> me? [Groucho Marx] >> Lorne Walton, Maple Ridge, BC, Canada >> >> _______________________________________________ >> FMPexperts mailing list >> FMPexperts@... >> http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au >> > > _______________________________________________ > FMPexperts mailing list > FMPexperts@... > http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au _______________________________________________ FMPexperts mailing list FMPexperts@... http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au |
|
|
Re: Aggregating numbers from different tables
by Bart Bartholomay
::
Rate this Message:
Yup. That's essentially where I was going. The key word is VIEW or
perhaps SNAPSHOT. And these can fairly easily be arranged by using concatenations, but each time one is changed somewhat, then more than likely you have to reset the variables. Without a lot more information it's pretty hard to tell how the use of variables in your scenario would benefit. I suspect, though, that your data structure could use some streamlining and, once done, would make it very easy to view what you wanted (including all importing as well). Bart On Jul 6, 2008, at 6:13 PM, Ernest Koe wrote: > Hi Peter, > To followup, I'd agree with you. I don't think what you are doing > is particularly abnormal. It is possible that your data model isn't > optimal but in general, FileMaker 9's native reporting abilities are > limited to what you can do within the scope summary fields and > summary parts. Stuff like cross-tabulation or pivot tables, > aggregation of different data sets, taking 'snap-shots' of data and > what-not require a bit of additional filemakery. One the things I do > all the time is to create tables to represent reports (and charts) I > want to display. That is to say, it is perfectly natural to use > FileMaker tables to drive VIEWS of data in addition to STORING data. > > my 2 cents > > - > Ernest Koe > Proof > Developers of fmSpark, a totally open, bolt-on mail-merge FileMaker > application for your FileMaker databases. > > > On Jul 6, 2008, at 4:04 PM, Peter L Versteegen wrote: > >> That's true. But in one database I have a whole set of different >> fields that calculate the dollar data, and in another table again >> with another completely different set of fields to compute the same >> type of dollar data. Putting both in the same table would be >> possible but is not natural. I'll have to manage several >> disjointed data sets. >> >> >> Peter Versteegen >> pversteegen@... >> >> >> >> On Jul 6, 2008, at 11:26 AM, Lorne & Joan Walton wrote: >> >>> I understand. But in another sense, they are all the same kind of >>> data - at least in my mind - or else you wouldn't have the need to >>> summarize them in a single table...? >>> >>> On Jul 6, 2008, at 5:11 AM, Peter L Versteegen wrote: >>> >>>> The dollar data are generated in different ways. In one table >>>> they are imported from a file, in another they are calculated >>>> based on various conditions. Some dollar data are expenses, other >>>> are income. It's more for the convenience of keeping various >>>> types of data separate. >>> >>> -- >>> Why should I care about posterity? What's posterity ever done for >>> me? [Groucho Marx] >>> Lorne Walton, Maple Ridge, BC, Canada >>> >>> _______________________________________________ >>> FMPexperts mailing list >>> FMPexperts@... >>> http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au >>> >> >> _______________________________________________ >> FMPexperts mailing list >> FMPexperts@... >> http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au > > _______________________________________________ > FMPexperts mailing list > FMPexperts@... > http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au _______________________________________________ FMPexperts mailing list FMPexperts@... http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au |
|
|
Re: Aggregating numbers from different tables
by peleve
::
Rate this Message:
I apologize for the length of time between posts on this subject, but
I finally found a solution to this problem and thought you might be interested. It's derived from a post by Graham Lauren (http://syslance.wordpress.com/2007/10/21/filemaker-multi-table-search/ ). His explanation is lengthy, but excellent, and the process works flawlessly. For those who want a copy of how I implemented it i an example send me an e-mail. Thanks for the help. Peter Versteegen pversteegen@... On Jul 6, 2008, at 6:52 PM, Bart Bartholomay wrote: > Yup. That's essentially where I was going. The key word is VIEW or > perhaps SNAPSHOT. And these can fairly easily be arranged by using > concatenations, but each time one is changed somewhat, then more > than likely you have to reset the variables. Without a lot more > information it's pretty hard to tell how the use of variables in > your scenario would benefit. I suspect, though, that your data > structure could use some streamlining and, once done, would make it > very easy to view what you wanted (including all importing as well). > > Bart > > On Jul 6, 2008, at 6:13 PM, Ernest Koe wrote: > >> Hi Peter, >> To followup, I'd agree with you. I don't think what you are doing >> is particularly abnormal. It is possible that your data model isn't >> optimal but in general, FileMaker 9's native reporting abilities >> are limited to what you can do within the scope summary fields and >> summary parts. Stuff like cross-tabulation or pivot tables, >> aggregation of different data sets, taking 'snap-shots' of data and >> what-not require a bit of additional filemakery. One the things I >> do all the time is to create tables to represent reports (and >> charts) I want to display. That is to say, it is perfectly natural >> to use FileMaker tables to drive VIEWS of data in addition to >> STORING data. >> >> my 2 cents >> >> - >> Ernest Koe >> Proof >> Developers of fmSpark, a totally open, bolt-on mail-merge FileMaker >> application for your FileMaker databases. >> >> >> On Jul 6, 2008, at 4:04 PM, Peter L Versteegen wrote: >> >>> That's true. But in one database I have a whole set of different >>> fields that calculate the dollar data, and in another table again >>> with another completely different set of fields to compute the >>> same type of dollar data. Putting both in the same table would be >>> possible but is not natural. I'll have to manage several >>> disjointed data sets. >>> >>> >>> Peter Versteegen >>> pversteegen@... >>> >>> >>> >>> On Jul 6, 2008, at 11:26 AM, Lorne & Joan Walton wrote: >>> >>>> I understand. But in another sense, they are all the same kind of >>>> data - at least in my mind - or else you wouldn't have the need >>>> to summarize them in a single table...? >>>> >>>> |
