From: esquel@sommarskog.se   
      
    (craig@listerhome.com) writes:   
   > That pages leads me to think that maybe a pre-filled table for payments   
   > isn't as bad as I thought. The only issues I have with this design, and   
   > hopefully you can assist with these, are, what if I generate a table   
   > until 2020.... and then in 2014, they decide to change the payment days   
   > to a Thursday, instead of a Wednesday. Do you recommend having a row in   
   > the table per payment date? Or a row per calendar day? I guess if it's   
   > per calendar day, then the table is generated once and that's it. But   
   > how do I work out where the fortnights are? Have a column added called   
   > 'IsPaymentDay' for example, and do an update and see if the day number   
   > is divisble by 14 (If they duration is 14)?   
      
   In the system I work with, there is a schedule for events for pension-   
   savings accounts. The assets are typically in funds and stocks. Once the   
   saver reaches retirement, he gets payments from the account. This is   
   arranged by selling off his assets, but only for a year or a month at a   
   time. There are three events each month: start of selling, selling close and   
   payment date. The users configures the days of the month for these events in   
   a table. There is another table that holds non-banking days.   
      
   From these tables, there is a job that every night computes the schedule,   
   leaving days in the past as they are, and up to 2150. (We need to be able   
   to show when the first payment is due, and for a person in this twenties,   
   that could be 40 years from now.)   
      
   And that is exactly the idea you should pursue. Somewhere you store the   
   definition of the fortnight and also days when there is a lock down. You   
   regenerate the table on nightly basis, or triggered by changes to the other   
   tables, but only from today and on. It would be a calendar on daily basis,   
   as it then can be used for other date calculations as well.   
      
   That job may not be too different from the .Net class you originally had   
   in mind. The point is that since it is the database, you can use it from   
   everywhee, including other stored procedures.   
      
   --   
   Erland Sommarskog, Stockholm, esquel@sommarskog.se   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)