In the case of total different things, i don't think you can generalize it.
But probably you could use parts of code more then once.
I don't know what all the different things are that you want to know but if you need both sales per month and sum(sales) per month you could use the same base SQL strings for selection.
In this case i think you have to write several subprograms to get all the different results.
It depends on what the user needs before you can say what has to be generalized.
And if you totally don't know, you could start with creating different functions for all the statisctics the user wants and then look what's used twice.

I myself have also something alike i an orders table where at more then 10 ways a price ban be created, with several other things that need to be stored in the table.
I've created an custom class for this with all the different code in it. Then the shared vars could be simply properties.

HTH, KW

---

>Hi Ko,
>
>I will try to explain the difference, hoping, I can understand the problem better by myself. Suppose you have an Input table and you want to create an output table with the same number of records, but different structure. We have two separate applications: First to select raw data from our database by user's specified criteria (actually, there are even two applications involved, one of them is mine). This is a first step. The second step is to create an output dbf file, using descriptions, rather than code values, etc. For this purpose we have another application called XForm. And finally we want to produce file in a format choosen by customer - printed output or PDF or comma-delimited, or Excel, or whatever - this is yet another application called Reporter. BTW, all three of them (except part of the first) are written by the same programmer in quite complicated fashion.
>
> Statistics module is a different animal (at least, I think so). The number of records in input table is greater than number of records in output table; the result is better to achieve by several SQLs instead of field by field transformation, etc. IOW, using the input table you have to produce different kind of statistics. I considered the simplest one for the start - called Standard Transaction Sales Statistics. Basically I selected some time period and few counties, and then I want to calculate Number of Sales, Volume of Sales and Meidan price, also the same values for Year to Date.
>
> You see, we know in advance the output table structure and we hardcoded field names, etc. My problem is, what I can not find a way to generalize this, IOW, I have to program separately each new statistics...
>
>>>Hi Ko,
>>>
>>> We have an already written by my colleague application, called XForm, which can convert one input structure to another. Each field has its own converting algorithm (or function), and each configuration is stored in so-called 'MetaFile'. My colleague invented this tecnique and originally I planned to implement something similar, but then I gave up this idea. The problem with this technique is that is too much complicated in its current implementation and noone except him can deal with it... Therefore I took a different road: I created parent-child scheme for each configuration: in parent table I store GroupBy, OrderBy, Description, etc. fields and in child - each field in output table. But my problem is deeper than that. As you can see from the example you helped me with, we didn't run field by field transformation. We ran 2 or 3 SQLs instead and called function GetMedianValue (BTW, I created a FAQ here GetMedian). So the question is: how can I generalize this approach? Do I have to
>>>create independant program (or part of the program) for each configuration and when just reference it somehow?
>>

---

>>Nadya,
>>
>>Sorry for not understanding.
>>The problem is not in the conversion to another table?
>>Can you please explain the problem where the problem lies then?
>>
>>TOA, KW