newsgrps
newsgrps at dalyn.co.nz
Thu Jun 2 17:31:34 CDT 2011
I will chip in because I have a client that is wanting to be able to archive data on stock specifications that change. For those wider tables (ie those with lots of fields) an alternative I have heard of is to have an "Archive" table with fields for ChangeDate, FieldName, OldValue. Then only changed fields need to be stored. The big problem I see with this is that for queries you would need to run a function for every field to get the relevant data. This might be better for mid sized tables with not to few, not to many fields but still seems a clumsy way of doing things. How does SQL do its transaction rollback thingy? David Emerson Dalyn Software Ltd New Zealand At 3/06/2011, Arthur Fuller wrote: >You got that part right. Agree 100%. It can become difficult, as in a couple >of dbs I have built in which 500+ tables were involved. I made no claim that >my solution was perfect. I just had to deal with a specific problem >regarding a specific period in time, and that's what I came up with. Anyone >with a better solution is most welcome to contribute to this thread. I am >always eager to learn from the experts on this forum. > >A. > >On Thu, Jun 2, 2011 at 5:31 PM, jwcolby <jwcolby at colbyconsulting.com> wrote: > > > I like the concept of PITA. The implementation could range from works fine > > to massive database bloat. I think for narrow tables that change > > occasionally it would work great. For wide tables that change a lot it > > would be problematic. > > > > > > John W. Colby > > www.ColbyConsulting.com > > > > > > >-- >AccessD mailing list >AccessD at databaseadvisors.com >http://databaseadvisors.com/mailman/listinfo/accessd >Website: http://www.databaseadvisors.com