8 database.inc db_create_table($name, $table)
6 database.inc db_create_table(&$ret, $name, $table)
7 database.inc db_create_table($name, $table)

Creates a new table from a Drupal table definition.


$name: The name of the table to create.

$table: A Schema API table definition array.

Related topics

36 calls to db_create_table()
block_update_7006 in modules/block/block.install
Recreates cache_block table.
DatabaseTestCase::installTables in modules/simpletest/tests/database_test.test
Set up several tables needed by a certain test.
DatabaseTransactionTestCase::executeDDLStatement in modules/simpletest/tests/database_test.test
Execute a DDL statement.
DatabaseTransactionTestCase::transactionInnerLayer in modules/simpletest/tests/database_test.test
Helper method for transaction unit tests. This "inner layer" transaction is either used alone or nested inside of the "outer layer" transaction.
drupal-6.bare.database.php in modules/simpletest/tests/upgrade/drupal-6.bare.database.php
Bare installation of Drupal 6.17, for test purposes.

... See full list


includes/database/database.inc, line 2719
Core systems for the database layer.


function db_create_table($name, $table) {
  return Database::getConnection()->schema()->createTable($name, $table);


Here's an example of adding a new table. You first add the table definition to your hook_schema() and this code will get the info from there. Note the doxygen comment is not "Implements hook_update_n" but the same as the untranslated string returned in the function.

 * Add the herp_derp table for the herp module.
function herp_update_7001() {
db_create_table('herp_derp', drupal_get_schema_unprocessed('herp', 'herp_derp'));
'Add the herp_derp table for the herp module.';

Based on this post:


it appears that using drupal_get_schema_unprocessed in an update function is not advised and you should *explicitly* create your schema within the update function to avoid possible issues later.

For the post, it seems (and I'm pretty sure) that drupal_get_schema() is unsafe, but drupal_get_schema_unprocessed() is perfectly fine to use in install file.

It's not about whether to use drupal_get_schema() or drupal_get_schema_unprocessed() in your update functions. The point is to use a table definition that isn't ever going to change, even if you make more updates in the future.

Let's say your module has to create a new table, so you do that in update 7010. Later on, you realize you need another column on that table, so you write it in update 7014. Now, if someone has only installed schema version 7005, when the run update 7010 and you used drupal_get_schema_unprocessed(), that table will already have the new column, because you were a good developer and added it to hook_schema() too. Update 7014 will then fail, most likely, because you're trying to add a column name that already exists.

Not everyone's going to get each update as it comes out, much as we'd like them to.

function wazi_rules_install() {
if (!db_table_exists('users_score')) {
  $users_score_schema = array(
    'description' => 'User gained score by type, area and time.',
    'fields' => array(
      'uid' => array('type' => 'int', 'unsigned' => TRUE, 'not null' => TRUE),
      'nid' => array('type' => 'int', 'unsigned' => TRUE, 'not null' => TRUE),
      'type' => array('type' => 'varchar', 'length' => 256, 'not null' => TRUE, 'default' => ''),
      'area' => array('type' => 'int', 'unsigned' => TRUE, 'not null' => TRUE),
      'score'    => array('type' => 'int', 'unsigned' => TRUE, 'not null' => TRUE),
      'timestamp' => array('type' => 'int', 'unsigned' => TRUE, 'not null' => TRUE, 'default' => '0'),