> 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"