### Our DBI parameters are:
$dsn="dbi:Sybase:server=$DB_SERVER";
### Connect DB
$dbh = DBI->connect ($dsn, $DB_USER, $DB_PWD) ;
[download]

sub process_database {

for ($i=0;$i<$#databases+1;$i++) {
    $database = $databases[$i] ;

    ### Use DB
    $dbh->do("USE $database") || log_message ("SERI","Database error $
+dbh->errstr") ;
get_db_name(); ## output here is okay 

    ### Get details from sysobjects
    $sql = "";
    $sql = "SELECT 1 " ;
    $sth = $dbh->prepare($sql);
    $sth->execute();
get_db_name(); ## output here is master
    $objcount =0;
    while (@row = $sth->fetchrow_array) { ## might give an error as th
+ere wasn't any execute statement before this 
        ($object = $row[0]) =~ s/\s//g ;
        $sql = "";
        $sql = "GRANT ALL ON $object TO PUBLIC" ;
#       $dbh->do($sql) || log_message ("SERI","Database error $dbh->er
+rstr");
        $objcount ++;
    } ## end of while

get_db_name(); ## output here is okay
    log_message("INFO","$objcount objects affected in $database");
} ## end of for
} ## end of subroutine

############################ GET DB NAME() ###########################
+#########
sub get_db_name {
    $sql_dbname = "select db_name()  ";
    $sth = $dbh->prepare($sql_dbname);
    $sth->execute() || die "ERROR : Database error $sth->errstr\n" ;
    while (@row = $sth->fetchrow_array) {
         $_ = $row[0];
         s/\s//g;
         print "IN DATABASE $_ \n";
    } ## end of while
}
[download]

Ok, not that this explains it, but it appears that after a call to prepare() is made, the database reported by select db_name() is the current users default database . The database remains as your default database until the excution has completed.
     To show this, i added calls to get_db_name() before the prepare() and also between prepare() and execute(). Keep in mind, that the prepare(),execute() and fetch() modle is lower level than isql, and therefore does cause some odd behaviour when other database work is done between prepare() and the sth finish.
    So, in short, it appears to be to be an issue with how Sybase (or ct-lib) handles the excution. I would not imagine there is a fix, because it is a question of architecture. But, you could submit a bug to MPeppler (DBD::Sybase author) and see what he has to say.

---

Thus spake the Master Programmer:
"When you have learned to snatch the error code from the trap frame, it will be time for you to leave."
-- The Tao of Programming