> when you drop a column). This is NOT "on the same level as a quick > DROP/CREATE".
Hi Reece, My apologies to Tom - I certainly was not trying to disreguard or "blow off" his advice. I think my lack of understanding may have manifested itself as dismissal. I'm a systems/network guy, not a DBA by any stretch of the word, and most of this is a real learning experience for me. :/ > Here's a proposal to get what you want: Create a super table bob_def and > two sub tables bob and bob_test. Changes to the definition of bob_def > (e.g., alter table add column...) will get immediately reflected in both > children. You'll insert data into bob and bob_test; bob_def contains no > rows. Selects on bob and bob_test are independent. In short, the > definitions will always be consistent and the data will be completely > independent. You could periodically truncate bob_test and insert ... > select to mirror the data too. > > A lesser option is to have bob_test inherit from bob, then use rules to > enforce the ONLY keyword for select/insert/update on bob. The > implementation of this option is less clear to me and there are a few > likely gotchas. I am loath to ask for a hand-hold here, but could you explain a little more about how to do such a thing? >> CREATE TABLE test_bob AS ( SELECT * FROM bob WHERE '1' = '2' ); > > > I don't understand why this does what you want... it requires explicit > intervention (meaning not "real time") to mirror the table definition. This is just an example of what I need to do - just duplicate the table structure exactly, and never mind the data. I know it isn't the solution. I just wanted folks to understand what I'd like to do. :) Thanks much for your help, Reece, it is greatly appreciated. :) Benny -- "Have you ever tried simply turning off the TV, sitting down with your children, and hitting them?" -- Bender, "Futurama" ---------------------------(end of broadcast)--------------------------- TIP 8: explain analyze is your friend