Is it generally desirable that contributed modules use the Drupal database abstraction whenever possible when accessing external databases? That is, is it generally preferable to use db_query() and friends, instead of mysql_connect(), mysql_query(), etc. whenever possible? I personally think so at the moment, but would certainly like to hear any arguments to the contrary. An argument that it doesn't really matter is an argument against generally using Drupal's DB layer. If one agrees it is generally better to use the Drupal DB layer, there is a significant problem to doing so. The code which supports multiple databases (of which I admit to being partially the author), such as db_set_active(), requires the additional databases to be listed in an array version of the global $db_url variable (up to and including Drupal 6) and $databases (Drupal 7). This array is set in the settings.php file. When using the Drupal 6 installer, this file can be written for the user doing the install. One can assume that most installations will thus likely not involve someone hand editing that file. Yet, except for some ugly kludges involving overwriting the $db_url or $databases variable (a scalar by default) with an array form including the extra external database(s), the only way to add an external database is to hand edit that file. If one wants to write a contrib module which has all the ease of installation which D6 and D7 core have, and which uses an external database, one is rather stuck. One can either (1) kludge up the $db_url or $databases variable by overwriting it, (2) require the user to expertly hand-edit the settings.php file or (3) not use the Drupal DB abstraction layer. Or so it seems. The contrib modules I've looked at so far mostly resort to #3, not using the DB abstraction. I'd especially like to chat with the folks working on the DB layer for D7. It would be nice to provide an interface to allow adding an additional DB programmatically from the contrib module. ..chris