By Install new Modul with Database tables comes this message.

DatabaseSchemaObjectExistsException: Table xxxxx already exists. in DatabaseSchema->createTable() (line 623 of http://xxx\xxx\xxx\xxx\includes\database\

But this tables doesnt already exists.

Greets Lennard


Damien Tournoud’s picture

Category: bug » support
Status: Needs work » Postponed (maintainer needs more info)

That probably means that your module is incorrectly calling drupal_install_schema() in its hook_install(). This is not necessary anymore as Drupal is calling this for you automatically.

Lennard’s picture

Thanks i haved see it. Now is the Install hook out and the error is gone.

David_Rothstein’s picture

Status: Postponed (maintainer needs more info) » Fixed

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

calbert’s picture

Could you explain how I would remove this to fix the problem?

David_Rothstein’s picture

@calbert: File a bug report against the module that is causing the problem (whichever module's tables are being installed when this message appears).

christophebst34’s picture

That issue comes from the old implementation of hook_install ()

Apparently it is not required anymonre, according to Drupal. But many tutorials and books are still using it for Drupal 7....

Here is an example of a proper implementation :

 * Implementation of hook_uninstall().
function big_deal_uninstall() {
    // Remove tables.

 * Implementation of hook_schema().
function big_deal_schema() {

    $schema['big_deal'] = array(
        'description' => 'enregistre une annonce',
        'fields' => array(
            'annonce_id' => array(
                'type' => 'serial',
                'not null' => TRUE,
                'description' => 'la reference annonce',
            'texte' => array(
                'type' => 'varchar',
                'length' => 255,
                'not null' => TRUE,
                'default' => '',
        'primary key' => array('annonce_id'),
    return $schema;


Hope it will help...

David_Rothstein’s picture

The hook_uninstall() implementation in the above example is actually also unnecessary. All you need is hook_schema()... everything else is taken care of automatically by Drupal. See

christophebst34’s picture

Yep.. Not necessary anymore. This is correct.
But if left it does not trigger an error...

BTW, absolutely not required in Drupal7.


calefilm’s picture

I'm really sorry to take this issue backward... I'm just so confused. I'm not very experienced at Drupal. I can enable, disable a module, put a site online, install patches, etc etc,, the basic stuff but when you get technical and start talking 'hooks' I'm just not there yet.

The reason why I'm here is I was referenced this post after responding to a similar thread here:

It seems i get a message like this if I enable a particular module:

DatabaseSchemaObjectExistsException: Table <em class="placeholder">comment</em> already exists. in DatabaseSchema->createTable() (line 652 of /Users/cale/Sites/acquia-drupal/includes/database/

Is this because my comments table still exists in my database, which it does? If I disable it I cannot uninstall it, even if I have comments in the database. . . This has happened before with other modules.

So my question is, does my issue pertain to the link you have provided to the Hook install? If so, can someone explain... since I can't grasp how to do a hook... am I okay moving forward with building my site or will this issue come back to haunt me?’s picture

Hi, How do you change the hook install... I'm getting a problem something like this, if not exactly.’s picture

Status: Closed (fixed) » Active

Yes, I'm having the same problem... c'mon guys give us a easy answer not one we have to figure out... I know figuring stuff out is one of the 'joys of Drupal' but there's only so much time in a day, huh? Please! How do we get this hook thing out of the way. Every module I load is throwing an error (after I restored database, by the way)... who knows what else is screwing up... I was getting really excited with Drupal 7 for a bit there but working with it is still like walking on glass!

pxljedi’s picture

I'm new to Drupal too and I'm receiving this error. I don't understand how to fix the "hook".

interlated’s picture

@pkljedi - you need to search your whole system for a .install file that specifies the schema for the database table.

e.g. it says "Table ognotify_attending" missing you need to search for "ognotify_attending"

A .install file should come up (e.g. ognotify.install using my example)

The most likely fix is that there is no 'drupal_uninstall_schema'. This is assuming the module is being enabled a second time. If you have 2 modules that create the same schema you are in trouble.

function ognotify_uninstall() {
drupal_uninstall_schema('ognotify_attending ');

Replace 'ognotify_' to the name of the module and 'ognotify_attending' to the name of the table that you searched for at the beginning.

Add an updated version of the above code. Disable, clear caches,uninstall/install the module.

It is a 'bug' in the module - so raise an 'issue' against the module.

I actually had to put the code in:

function ognotify_disable() {
drupal_uninstall_schema('ognotify_attending ');

as the module has sub-module dependencies. This would remove data during disable, so probably not appropriate to leave there.

Probably easier to delete the database table using sql and just raise a bug. I often also find that a refresh of the 'white screen' does what I wanted it to do.


David_Rothstein’s picture

Status: Active » Fixed

#14, that's actually not correct.

As stated above, in Drupal 7 modules should not be calling drupal_uninstall_schema() during uninstall themselves, since Drupal does it automatically. (It's harmless if they do call it, but it won't fix anything either, so you shouldn't file a bug report suggesting that they need to do it.)

As far as I know there are really only two possible causes here:

  1. If you look at the module's .install file and see code like this:
    function MODULENAME_install() {

    (with the actual name of the module replaced), that's a critical bug which would cause this, and you should file a bug report against the module to remove this code.

    However, these days, this kind of bug is pretty unlikely to come across, since it's totally impossible to install a module in Drupal 7 that has this code so it probably would have been fixed already, and certainly fixed already for any module that is remotely ready for use on a production website.

  2. More likely is that some other bug (or something you did hacking around the database?) caused your installation to get really messed up, such that Drupal thinks the module is uninstalled when it really is partially installed (such that some of its database tables exist). Therefore, when it tries to install it again, things explode.

    As long as you don't have any important data stored in that module (because the procedure here will destroy it), the thing to do here is probably to temporarily fool Drupal into thinking the module is installed, so it can be uninstalled and then reinstalled again, basically something like:

    • Running the following database query against your database:
      UPDATE system SET status = 0, schema_version = 0 WHERE type = 'module' AND name = 'MODULENAME';
      (again using the actual name of the module).
    • Then afterwards, going to admin/modules/uninstall and uninstalling the module cleanly via the user interface.
    • And finally, enabling it again the normal way (at admin/modules).

    This isn't guaranteed to work as it probably depends on the specific way in which your site broke, but that can't really be dealt with in a generic issue like this one. It should also be something that very few people ever run into. (See also #1551132: When trying to create a table that already exists but is empty, recreate the table rather than throwing a DatabaseSchemaObjectExistsException which proposes making some changes so that in the unlikely event you do run into it, Drupal can more gracefully recover without the need for the manual database query described above.)

interlated’s picture

David. The 2nd one then. There was no drupal_install_schema in my example. I got uninstall from #7 as you corrected previously.

Therefore, the only answer is to drop the table using SQL (which I had to do). It is also indeterminate how the problem occurred in the first place. Probably some other bug stopped the module install process. I expected 'uninstalling' the module to get rid of the table but it does not.

tbrowninfinitymark’s picture

I am having the same issue with OG on a new D7 site I just built last weekend. I don't get any of these errors until I enable OG - then I get them all over the place.

I have tried restoring site files and db to no avail. Anyone able to resolve this yet?

tbrowninfinitymark’s picture

My issue was happening when attempting to make a content type a group type. I just dropped the tables it was complaining about (field_group_group and field_revision_group_group) and saved the content type successfully. Then I experienced a similar issue when attempting to make an existing content type a group post type - I again dropped the tables being complained about (field_group_audience and field_revision_group_audience) and was able to save it successfully.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

SocialNicheGuru’s picture

Given what was said above, should this line be in modules/system/system.install?


SunRhythms’s picture

Another work around....
The Table is the actual Table in the database. It basically means there is a mismatch in data from your original database file and the one you currently have, but unfortunately it can't overwrite it. You have to actually uninstall the module and all of its required modules, fields, and other components and then delete the table item out of the MySql database then reinstall the module if you need it (unless you know how to rewrite the sql table information that is needed yourself, I'm assuming)...