It has a long way to go before it becomes functional in the big picture. One of the primary purposes of OOP is to allow reusability, and a close second on that is to allow a great deal of abstraction. What you have is locked both into mysql and in both procedural and OO code.
MyTransaction should be an interface, and a potential abstract would be placed between the OOP driver and the interface. You then create factories to construct the necessary classes for you. I have chosen to un-name the createTransaction as it should be inferred from the type of driver in use for the Database::getInstance class. The MyTransaction implementation should also extend an interface for the Database, so that each transaction can be treated as a Database type.
The idea is to completely centralize the code, so that all of your second block would become this:
PHP Code:
$connection = Database::getInstance('MySQL');
$connection->open($dhost,$duser,$dpass, $dbname);
$new_entry = $connection->createTransaction();
$error = 0;
$new_entry->begin();
// query #1
if ($result = $new_entry->query(...)){
} else {
$error++;
}
// query #2
if ($result = $new_entry->query('insert....')){
} else {
$error++;
}
// query #3
if ($result = $new_entry->query('insert....')){
} else {
$error++;
}
if ($error){
$new_entry->rollback();
} else {
$new_entry->commit();
}
Keeping control at an aggregate level of the class will allow you to write transaction drivers for databases that do not support them (it just takes more work).
Now the only thing that needs to change to work on other databases is the use of the factory to get the instance type. Of course, you'd write the drivers to access sqlserver or oracle for example, but usage wise only the 'mySQL' would change to something like 'SQLServer' - no other usage code would need to change.
Proper OO development does take a lot of work, but the reward of re-usability and portability is well worth the effort.