As a general rule, keep your GUI construction code lexically separated from your GUI processing. This will (usually) prevent you from running into these sorts of problems. It will also help in avoiding monolithic GUI scripts where global variables and action-at-a-distance become the bane of your existence: you could, for instance, put your subroutines in modules where they were tested independently and perhaps reused by any number of other scripts.

Both ++AnomalousMonk and ++Marshall have made excellent points^{[1, 2]} regarding the use of references. As a guiding principle, whenever you use the -command option with a function that requires arguments, pass those arguments as references.

In the code below, I've reduced your "simple script" to a very bare-bones version. Notice the anonymous block that lexically isolates %db_data from the subroutines: they have no knowledge of it; can't directly access it; and wouldn't know the difference if you passed \%a_different_set_of_db_data as an argument.

#!/usr/bin/env perl -l

use strict;
use warnings;

use Tk;

{
    my %db_data = qw{1 term1 2 term2 3 term3};

    my $mw = MainWindow::->new;

    $mw->Entry(-textvariable => \$db_data{$_})->pack for sort keys %db
+_data;
    $mw->Button(-text => 'Print', -command => [\&print_vals, \%db_data
+])->pack;
    $mw->Button(-text => 'Load',  -command => [\&load_vals,  \%db_data
+])->pack;
}

MainLoop;

sub print_vals { print "@{$_[0]}{1..3}" }

sub load_vals { @{$_[0]}{1..3} = qw{X Y Z} }
[download]

I tested by: printing the initial values; changing the values of 1 then 3 then 2 (intentionally out of order) and printing after each individual change; loading new values and printing; and, finally, changing all values first and then printing once. Here's the output:

term1 term2 term3
A term2 term3
A term2 C
A B C
X Y Z
D E F
[download]