Gary Kjos
garykjos at gmail.com
Mon Mar 12 15:19:56 CDT 2012
There is a lot of housekeeping and logging of changes that would be happening. Appending rows to a brand new table with NOLOGGING option set and then renaming the table and re-establishing the indexes afterward could make sense. You save all the overhead of the logging and maintaining of the indexes while the updates are happening. If you are dealing with 100 million row tables in an Access database you might very well experience the same issue. GK On Mon, Mar 12, 2012 at 2:54 PM, Benson, William (GE Global Research, consultant) <Benson at ge.com> wrote: > Long time, no post, didn't want people to think I have stopped thinking about databases entirely. > > So here is a question, I was reading this thread (which related to Oracle of course, not Access) and wondering if the "truths" in this post are relative to Oracle only. > > It struck me as odd that the recommendation was to create a new table from a multi-million record table, with whatever updated values certain fields required - rather than update the fields directly when the table was indexed. Even though it meant duplicating the table, building all the indexes in the successor table, and sunsetting dropping the predecessor table. > > It just boggles my mind that this is so - and I wondered if it is regardless of platform. > > http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:6407993912330 > > > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com -- Gary Kjos garykjos at gmail.com