So that would involve untieing the $self->{data} in the child class, but NOT untieing it in the parent class? That's the only way I imagine it would work, but I don't know how to do that (how to prevent calling the parent's DESTROY() method. If both parent's and child's DESTROY() methods are called, the parent's DESTROY() method still overwrited the tied data with its copy as opposed to updated child's data.

Maybe I'm just trying to do something that doesn't really have to be done. I just want to know if I'm going all wrong about the whole thing.

Since $self->{data} is just an attribute, you can set it to undef after the untie in the child method, and adding an if (defined $self->{data}) {...} around the untie in the parent's DESTROY.

Hope this helps, -gjb-

Thank you! This seems to work. Below is my test code.

use strict;
use warnings;
use Data::Dumper;

my $control = Control->new();
my $app = Control::Main->new( %{$control} );

package Control;
use Data::Dumper;

sub new {
    my $class = shift;
    my $self = bless {}, ref($class) || $class;

    #my $dbh = Area::DB::connect(\$_connected) if !$_connected;
    #tie %{$self->{data}}, "Tie::ODBCSession", $dbh, $session_id;
    $self->{data} = {};

    return $self;
}

sub DESTROY {
    my $self = shift;

    print "Destroying parent:\n";
    print Dumper ($self) . "\n";
}

package Control::Main;
@Control::Main::ISA = qw(Control);
use Data::Dumper;

sub new {
    my $class = shift;
    my %args = @_;
    my $self = {};

    bless $self, $class;

    # initialize with named parameters passed
    %{$self} = map { $_ => $args{$_} } keys(%args);
    
    # store action in the object
    $self->{data}->{action} = "test";
    
    return $self;
}

sub DESTROY {
    my $self = shift;

    $self->{data} = undef;
    print "Destroying child:\n";
    print Dumper ($self) . "\n";

}
[download]

I reckon you only need to untie and destroy the object once - if the data's shared then updating the child's data updates the parent's data automatically.

By the sounds of it, you don't need to worry about DESTROY in the child - just call the parent module's DESTROY and let it take care of the untieing of the object and the DB update.

Hope that helps ..
-- Foxcub

That assumes that the data IS shared, and I don't think it is... In this case parent's data is different from child's data.