If you want to be able to run multiple queries in a single function call, for example doing the classic drop table blah; create table blah; then you might like this function.

The use case is for things like database migration systems which you might copy and paste chunks of SQL including multiple queries from things like phpMyAdmin

/**
 * Run multiple queries passed in as a single string
 * This is optimised for copying and pasting from phpMyAdmin
 * 
 * Handy for things like database migration systems
 * 
 * @param string $sql  multiple queries terminated with ; and a new line
 */
function multiQuery($sql)
{
    $sqls = preg_split('%;$%m', trim($sql));
    foreach ($sqls as $q) {
        if (empty($q)) {
            continue;
        }
        mysql_query($q); //suggest you replace this with your custom query function or if not throw in some extra error checking at least
    }
}

Wondering why your Magento admin menu is not showing up after upgrading your live Magento store?

If all attempts to get to a particular admin page with the exception of the dashboard proved abortive, this could be because there is a conflict between the Magento function that merges all Javascript files and the Apache URL rewrite. This could be fixed by turning off this Magento function, and your can run the script below to do this.

UPDATE  <code>[your_magento_database_name]</code>.<code>core_config_data</code> SET  <code>value</code> =  '0' WHERE  <code>core_config_data</code>.<code>path</code> =<code>dev/js/merge_files</code>;

These two Magento functions looks more like there is no obvious difference between them, but there is.

addAttributeToFilter(‘some_attribute1′,’attribute_value’) filters a Magento entity collection (e.g Products, categories) by only selecting entities that has ‘some_attribute’ equal to ‘attribute_value’ while

addAttributeToSelect(‘some_attribute2′) tells Magento to return add ‘some_attributes’ to the set of properties that would be returned for a collection of entities.

A combination of these two functions could be likened to

SELECT 'some_attribute2' FROM Table WHERE 'some_attribute1'='attribute_value'

If you are working with collections and would like to verify that the actual SQL being used is what you expect it to be then this little tip might prove really handy.

For any collection you can call the method getSelect(). This retrieves the actual Select object that handles the query.

If you cast this select object to a string, you get the raw SQL query, so for example the following is pretty handy:

die(var_dump((string)$collection->getSelect()));

This way you can tweak your collection filters etc and check that its doing what you expect it to be doing

If your osCommerce checkout starts behaving badly and bits of info seem to go missing eg billing address then you should definitely try this fix before you tear your hair out completely.

Most osCommerce installs store session information to a MySQL table called (suprisingly) sessions.

Sometimes (I have only seen this twice on umpteen osCommerce sites) the sessions table will become corrupted. The irritating thing is that if this happens it seems that the site will not stop working completely with a useful error message, but instead will continue to work but will behave very strangely.

If your osCommerce site is behaving strangely then try this fix.

Open phpMyAdmin and select your SQL database and then copy and paste the following into the SQL section and hit run:

REPAIR TABLE <code>sessions</code>;

If you develop using Zend Framework you will know that it is sometimes tricky to see exactly whats going on in terms of SQL queries. After trying a few different ideas including subclassing the database classes or other complex systems, the easiest I have found is this:

1. Edit your app.ini config file and add a line:

db_profiling_enabled = false

Then in your development section in your ini file, set the same value to true

2. Add the following lines to your bootstrap.php after the database adapter setup.

// DATABASE ADAPTER - Setup the database adapter
// Zend_Db implements a factory interface that allows developers to pass in an 
// adapter name and some parameters that will create an appropriate database 
// adapter object.  In this instance, we will be using the values found in the 
// "database" section of the configuration obj.
$dbAdapter = Zend_Db::factory($configuration->database);
//$dbAdapter = new EC_Db_Mysqli($configuration->database->params);


if($configuration->db_profiling_enabled){
    // create a new profiler
    $profiler = new Zend_Db_Profiler_Firebug('EdmondsCommerce DB Queries Debug');
    // enable profiling (this is only recommended in development mode, disable this in production mode)
    $profiler->setEnabled(true);
    // add the profiler to the database object
    $dbAdapter->setProfiler($profiler);
}

Note you may need to move this chunk above the database adapter section:

// CONFIGURATION - Setup the configuration object
// The Zend_Config_Ini component will parse the ini file, and resolve all of
// the values for the given section.  Here we will be using the section name
// that corresponds to the APP's Environment
$configuration = new Zend_Config_Ini(
    APPLICATION_PATH . '/config/app.ini', 
    APPLICATION_ENVIRONMENT
);

This is based on a modified quickstart layout for a project. If you have decided to use an alternative layout, you should be able to tell where the relevant code should be.

You will need to have the Firebug firefox extension to view this output. If you also install the FirePHP extension for firebug then there are even more cool things that you can do.