I think your solution depends on your resources. If you have a fast database and a fast connection to it, then you can get away with one search and manipulate the resultset with WiTango. If your database is slow with a fast connection, many small searches will keep the customer wait time down. If your connection to the database is slow, it may not matter. If the customer wants 400 rows in an itemized report, that is what you give them. But it could be that once they see what they are asking for they will decide a more condensed report will work. The time spent on planning the report display will pay off in reduced code changes. Maybe have the user select one of several reports to display, then do your search based on the customer request? I don't like retrieving excess data from the database. Mark Bushaw
On 11 Jul 2002 at 12:01, Jose Kuhn wrote: > Here is how the reports supposed to work. There are nine (I lied) Repair > Categories and 3 Repair Tracks (OEM, Broker, Direct). For each of the 27 > items I need # of repairs and the total cost. I also want to total the > columns and the rows as well as the grand totals. Our customers just want a > general monthly report on how much they have spent, And they want it > itemized. If I were to do a search for one month of repairs it could easily > be 300-400 rows in my array!! > > I just want to do the most efficient search That does not task the server > while not taking a lot of time to post the result. ( I can dream can't I ;) > ) > > I hear what you are saying but our customers are not going to spend the time > doing 9 separate searches they just want to know what they spent last month > and where. As usual in order to make it simple for the end user there is > going to be a lot of coding. > > > Thanks for the input thus far!!!! > > Jose > > on 7/11/2002 11:19 AM, Len Wright at [EMAIL PROTECTED] wrote: > > > I have written several reports that sound similar in scope to what you > > are doing. My strategy is to provide the user with several selection > > fields to build the query based in the user's input, and then bring back > > a resultset that matches the selection fields. > > > > if your categories and subcategories fields are indexed, then this > > approach is very quick and you don't bring back a bunch data that > > doesn't get used. > > > > > > > > Regards, > > > > Len Wright > > Plus International Corp > > www.plusinternational.com > > > > Direct: 604-415-2384 > > Fax:604-415-0830 > > > > > >>>> [EMAIL PROTECTED] 07/11/02 08:20AM >>> > > Before, I waste a lot of time going down the wrong path I would like to > > know > > the most efficient way to handle generating reports from a huge array. > > > > Here is the deal. I need to generate a cost report of repair orders > > that has > > 7 categories and three sub categories. Is it better for me to do one > > search > > and generate a huge array to manipulate through filters, do a bunch of > > little searches or put the Results array into a JavaScript array and > > let > > JavaScript handle the gory details? > > > > Thanks in advanced, > > > > Jose > > -- > Webologies > 150 Robinette Drive > Waynesville, NC 28786 > 828.627.1994 > > http://www.webologies.com > > ---------------------------------------------------------------------------- > "You can't make an omelet without breaking eggs" Boris Badenov > ---------------------------------------------------------------------------- > > ________________________________________________________________________ TO UNSUBSCRIBE: send a plain text/US ASCII email to [EMAIL PROTECTED] with unsubscribe witango-talk in the message body
