## Proper logic for a stored procedure

 Author Message Shadow.2802 SSC Rookie Group: General Forum Members Points: 38 Visits: 38 Experts:I have a report that I need to generate through multiple queries.Basically, I am using three tables pulling the same fields:Table #1- cb_nd_daily, Table #2 cc-sv_daily, Table#3-CD_daily.From these tables, I need to pull the br---->branchtype----->product typebibal----->acct balanceacct count----->number of acctsWhat I am doing is I am getting the total dollar amount of checking, savings, and cds for this institution. Once I get the total, I need to run another query that would break down the product type(checking,savings,CD) by different branches. So I wrote 22 queries and here is just an example of them:1) Here I am getting the total amount of checking deposits this bank has and total number of checking accountsSelect sum(bibal),count(acct) from cb_nd_daily---- I would then do the same for savings accounts pulling from SV(cb_sv_daily) and CD from (cb_cd_daily) The next set of queries I have to filter out by either br # or type.2) select sum(bibal),count(acct) from cb_nd_daily where br = 291----here I am getting the toal of checking accounts and amount for branch 291. I would then apply the same filter for savings and cd3) Select sum(bibal),count(acct) from cb_nd_dailywhere br= 291and type in (52,77)-----Here I want to pull all accts that are type 52 & 77)How do I begin to create a stored procedure where the information would populate for the entire institution and then run subquent queries to populate information based on those filters. I was thinking of creating a table first, do an insert, and summary but kind of lost on how this logic would work. Any assistance will be appreciated. Thanks Douglas Hudson Grasshopper Group: General Forum Members Points: 24 Visits: 12 I'm not clear on why you have three tables with what appears to be the same data, but it sounds to me as though it would make sense to create a table of summarized data, then use that for various reporting purposes. Periodically you would delete (or truncate) the table and re-populate it. You would want to populate it with something like this:select type, br, sum(bibal), count(*)from group by type, brThat would give you balance totals and counts by branch and type. You could either use the summary table directly for reporting, or summarize it further for totals by branch (across all types) or type (across all branches). This type of approach is commonly used in financial reporting applications -- the data might be refreshed monthly. For a financial institution, you might want to refresh the data daily (overnight). This approach makes sense if the volume of data is very large (so you don't want to be re-querying the raw data many times) and it's OK if the data is as of a particular point in time (like last night, or last month). If the volume of data isn't too large, or you need to have current, real-time results, then the summary-table approach would not make sense. In that case, you probably want to create a couple of stored procedures with parameters for the branch or type, so they are not hard-coded. Two or three stored procs would probably cover most of it -- no way you should need twenty of them.Doug