One object to handle all my database manipulation needs I have created an object to handle all my database manipulation needs. Here is my object constructor and one of its functions:

class dataMonster{
    var $sn = '';
    var $un = '';
    var $pw = '';
    var $dn = "";


    function update($table, $records, $set_value, $compare, $compare_value){

        $table=preg_replace('/[^0-9a-zA-Z_]/', '', $table);
        $records=preg_replace('/[^0-9a-zA-Z_,]/', '', $records);
        $compare=preg_replace('/[^0-9a-zA-Z_,]/', '', $compare);

        $dsn = "mysql:host=".$this-&gt;sn.";dbname=".$this-&gt;dn.";charset=utf8";
        $opt = array(
            PDO::ATTR_ERRMODE            =&gt; PDO::ERRMODE_EXCEPTION,
            PDO::ATTR_DEFAULT_FETCH_MODE =&gt; PDO::FETCH_ASSOC
        );
        ini_set('display_errors', 'On');

        $return_check = $pdo = new PDO($dsn, $this-&gt;un, $this-&gt;pw, $opt);
        if($return_check === false){
            echo 'PDO failed';
        }
        $return_check = $stm = $pdo-&gt;prepare("UPDATE $table SET $records = ? WHERE $compare = ?");
        if($return_check === false){
            echo 'prepare failed';
        }
        $return_check = $stm-&gt;execute(array($set_value, $compare_value));
        if($return_check === false){
            echo 'execute failed';
        }
    }
}


It is then instantiated and called as such:

$dm = new dataMonster();
$dm-&gt;sn = 'localhost';
$dm-&gt;un = 'xtremeco_admin';
$dm-&gt;pw = 'fMMA1EJJuz8I';
$dm-&gt;dn = 'xtremeco_users';

$dm-&gt;update('users', 'sessionid', $session_id, 'username', $user_name);


The class constructor is held in a separate file and imported into the project I'm working on. I know the standard is to code in a whitelist of acceptable tables and columns to prevent injection but I think I have successfully safe guarded against it. No user input makes it into the statement itself. My goal is to create a file that can just be imported and run with no editing. But in doing so, am I leaving myself open to attack?
No user input makes it into the statement itself. 


You should write a PHPDoc style comment which explicitely states that specific parameters should not contain user input. 

This would of course also be the case if you used a whitelist to check against existing table and column names, as no user should have the ability to change arbitrary tables or columns.


  I have successfully safe guarded against it.


Pretty much. It's not clear to me why you accept , though. Without =, you can't add a second value anyways, so , should not be necessary.

Method Signature


  $dm->update('users', 'sessionid', $session_id, 'username', $user_name);


This isn't very easily understandable. Sure, it updates some table, but a reader has no idea what exactly is happening without looking at the update code itself. 

If you go with something like a query builder, you might get code like this:

$dm-&gt;update('users')
    -&gt;set('sessionid', $session_id)
    -&gt;set([something else])
    -&gt;where('username', $user_name)
    -&gt;exec();


This would be a lot easier to read as it is clear what each argument actually does.

Functionality

Your method should be able to deal with setting multiple fields at once. For example by accepting an array of records and set_values.

Structure

Your update method shouldn't create a new pdo object on each call. Instead, reuse the same connection for all queries.

Your method should also not echo. It makes it very difficult to recover from errors, or to control what a user sees. Throw exceptions instead (pdo can actually do this for you with ERRMODE_EXCEPTION so there is no need to check here).

Your method should also not change ini settings. These should be set in some configuration class.

With this, your method may look like this:

function update($pdo, $table, $records, $set_value, $compare, $compare_value){

    $table=preg_replace('/[^0-9a-zA-Z_]/', '', $table);
    $records=preg_replace('/[^0-9a-zA-Z_,]/', '', $records);
    $compare=preg_replace('/[^0-9a-zA-Z_,]/', '', $compare);

    $stm = $pdo-&gt;prepare("UPDATE $table SET $records = ? WHERE $compare = ?");
    $stm-&gt;execute(array($set_value, $compare_value));
}


The PDO exceptions would be handled by your calling code. Depending on what is updated, you may want to log the error, inform the user, ignore the error, perform a different action, and so on.

Of course now the question is if this method is actually needed. Is this:

try {
    $dm-&gt;update($pdo, 'users', 'sessionid', $session_id, 'username', $user_name); 
} catch ($pdoException) {
    // handle error
}     


Really better than this:

try {
    $stm = $pdo-&gt;prepare("UPDATE users SET sessionid = ? WHERE username = ?");
    $stm-&gt;execute(array($session_id, $user_name));
} catch ($pdoException) {
    // handle error
}  


? I don't really think so. The second is clearer, provides less room for error, isn't really longer, and is more flexible. 

Misc


only display errors in development. It has a negative effect on security if they are enabled in production. This makes it especially important to only change the setting in some configuration file and not all over the place.
Your password is above average, but you should probably change it now :)
sn, un, pw, dn, opt are all bad names. If you write them out your code will be more readable.