PDOExceptions

The same things happens to my site every time I flush the caches. Then the site stays down until i manually uninstall the module. Hope this helps.

I have been using ECK for a long time without issues. So, we need more specifics to figure out the problem. For example, if you install ECK in a vanilla installation of Drupal, do you get the same issues? When do you start seeing the errors? Does clearing the cache with drush solves the issue? Let's start there.

@tchopshop well.. thank you for reporting your issues, and hopefully this is something that is repeatable, so we can catch the bug later.

I have the same issue with my site. I duplicated the site files and db in another installation, same thing. I have to delete the eck directory to use the site I kept deleting and readding it until it suddenly took, and then that second site worked. Unfortunately, a db update by another dev required me to import his db, and now the issue is back.

Can this be linked to commons modules? I have 3.4 installed and that's considered obsolete. I think my entity api and entity reference module may also need upgrading.

UPDATE: I have installed the latest version of commons, and now have updated entity api, entity cache and entity reference modules installed. I still got the error, but figured out that if I "drush pm-disable eck", then go to the uninstall page (/admin/modules/uninstall) and uninstall eck, then re-install via "drush en eck", it seems to work. I admit that I have had a lot of back and forth on this to get it to work, so I'm not 100% sure I only did the preceding steps, but that's what I recommend trying first. Perhaps this will also give the developers some clues as to the possible cause.

I get the same issue when switching my site from PHP5.4 to either 5.5 or 5.6.
Same exact code works fine on 5.4, but yields these errors with the most recent PHP versions.

I get a similar exception when I delete an entity (an actual entity, not a bundle or type) and then try to add a new one. It is related to the Link Field module. When I delete an entity that has a Link Field, it doesn't delete the reference in the database. So, when I try to add a new entity, it assigns it the same ID and attempts to create a link field referencing that ID in the field record, but there's an existing field record that is already referencing that ID. thus this exception:

PDOException: SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry 'roadmap_result-242-242-0-0-und' for key 'PRIMARY': INSERT INTO {field_revision_field_result_link} (entity_type, entity_id, revision_id, bundle, delta, language, field_result_link_url, field_result_link_title, field_result_link_attributes) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3, :db_insert_placeholder_4, :db_insert_placeholder_5, :db_insert_placeholder_6, :db_insert_placeholder_7, :db_insert_placeholder_8); Array ( [:db_insert_placeholder_0] => roadmap_result [:db_insert_placeholder_1] => 242 [:db_insert_placeholder_2] => 242 [:db_insert_placeholder_3] => link [:db_insert_placeholder_4] => 0 [:db_insert_placeholder_5] => und [:db_insert_placeholder_6] => http://google.com [:db_insert_placeholder_7] => [:db_insert_placeholder_8] => a:2:{s:6:"target";s:6:"_blank";s:5:"title";s:22:"[roadmap_result:title]";} ) in field_sql_storage_field_storage_write() (line 515 of ~/modules/field/modules/field_sql_storage/field_sql_storage.module).

I have also got this issue. Im unsure of the cause or how to consistently reproduce, but once it happens, it doesn't fix itself with cache clear or registry_rebuild etc.

I've managed to trace back to line 480 (function loadAll())):

$entity_type->load('name', $name);

calling ->load on the new entities. Line 131 (protected function load($property, $value) {...), the error is coming from the db_select($this->table, 't') when $this->table in null.

I have got not further than to fix the issue by wrapping the db_select function in if($this->table) i.e on live 132.

if($this->table){
      $result = db_select($this->table, 't')->fields('t')->condition($property, $value, '=')
        ->execute()->fetchAssoc();
    }

:

Patch for #11 comment if useful.

I had the same error. I updated my core to 7.50 and all my other modules as well. ECK was updated from rc7-dev to rc8, but there were no real changes, only in the .info files. Still, when i ran update.php the site was broke. Even in a new dev environment, without running update.php, just having the new code, I got a 500 error on my homepage. What made it even stranger is that I even got the error using a copy of my local database, where the error did not occur, on this new staging environment. So it must be something environment or cache related, file cache. Perhaps it has to do with the order of the updates, the bootstrap process (order), ...

The thing that worked for me was what @4alldigital said, i.e. wrapping the select in an if. This is obviously not ok, since then the entity types are not being loaded at all, but after a cache clear, I re-enabled the code (removed the if) and then did a new cache clear so that the entities would be loaded, and they did! No error...

So I still don't know the exact cause of this bug, but I saw that the drupal_get_schema($table) call in eck.classes.inc line 36 was not returning a schema, therefore the $this->table was not being set there. I think this is because drupal_get_schema was not called before, on bootstrap or wherever it should be initiated, and thus an empty schema cache was being used. So it might be a core issue, or a wrong implementation of the schema_alter hook, or entity_info_alter hook, or something else by ECK. I don't know... And I'm not looking into it any further. I already spent a few hours on this bug. But, I hope my experiences will guide the maintainer to a permanent fix, and might help other developers facing this issue.

Patch in #12 fixed this issue for me.

Curious that this patch has not been applied to the release.

Looking at the patch and the comment in #13 this is obviously not RTBC and needs work.

I've been running into a very similar issue to this with the following error:

The following extensions will be enabled: eck
Do you really want to continue? (y/n): y
WD registry: PDOException: SQLSTATE[42S02]: Base table or view not found: 1146 Table                                 [error]
'database_name.eck_entity_type' doesn't exist: SELECT t.name AS name
FROM
{eck_entity_type} t; Array
(
)
 in EntityType::loadAll() (line 473 of /vagrant/docroot/sites/all/modules/contrib/eck/eck.classes.inc).
exception 'PDOException' with message 'SQLSTATE[42S02]: Base table or view not found: 1146 Table                     [error]
'database_name.eck_entity_type' doesn't exist' in
/vagrant/docroot/includes/database/database.inc:2227

I'm still not able to replicate it all the time but I added onto the patch in #12 to get around this for now. It seems like the schema is not installing on installation properly. I also considered adding to the __construct of the DBObject an option to install the schema if the schema doesn't exist.

    else {
      drupal_install_schema('eck');
      // @todo throw an exception.
    }

Oops. Uploading relative filename patch this time...

Update: Confirmed this ended the errors I was seeing for tables not being created on install. Also additional detail the module for ECK was enabling as a dependency from a feature module.

I had this same issue. Everything worked fine in production. When I set up everything locally and got the reported errors above.

I changed the version of PHP from 5.6.31 up to PHP 7.0.23 in WAMP and that made the errors go away. Everything worked again.

My production server is running 5.3.3.

Now I'm going to install the same version locally that is on the server. Something I should have done already in all fairness.

We're having the same issue when grabbing a local copy from Acquia Cloud via Dev Desktop. The only way it works is by applying #12, running update.php & clearing caches. After I revert the changes (remove #12) and site works just fine. This issue began after the last core update (7.58) so its worth investigating if something changed in core.

Not sure what happened with the dev branch that makes the tests fail. The patch in #17 applies properly to rc9 and fixed the problem for me.

hello, i've the same error. Because the production site is crashed (WSOD without any error), I installed on my locale server a Drupal 7.59 (on the production site, the version was 7.41), imported the SITES repertory and import all content of tables in the database whithout the content of the cache tables (and added missing tables). After it, I launched a update.php and received this warning. And it's impossible to display the site, because this error appears also. I tried with PHP 1.7 but it's the same. I would like to try the patch but I don't know how to do that.
Thanks for your help !

Finally, I tested the 3 patches (12, 16, 17) with a manual install (copy/paste the pieces of code at the right place) and launch update.php. Result : WSOD.
So I install the last version of eck (in dev but it's the more recent) and it seems the patch is not include into the code ??? I hate Drupal ! Why to do simple when it's possible to make it complicated !!! To install the module, I copied/pasted all files and repertory in the repertory of the module on my locale server and launched update.php ... and i have always the PDOException !!!

@cds-CMS Sorry that you have trouble with the way these issue processes work. The state of this issue here is "needs work". The proposed patches are here to try to solve the problem described in this issue. Until it has been approved to work, a patch is still only a proposition and will not be committed to the module repository. Once we all agree that a patch is working, the status will be set to "RTBC" and then the module maintainers can finally commit the code to the repo. More on this here: https://www.drupal.org/issue-queue/status

Try to download the rc9 release, apply the patch from #17 and then run update.php again. That did the trick for me.

Hope this information is useful: I had a similar problem when changing databases for a particular project in an Acquia install. Drush worked only partially, and drush rr and drush cc all didn't work, and all that I had was a WSOD.

This is a multisite install, and ALL the other sites were working (using the same code). We even went to DB backups that were working before and they did not work either. This was the dev site. The Staging and Live sites, using the same code and the same database worked without issue.

I came to the conclusion that the problem was something was clogging the Drupal Registry (which I understand keeps entity information) and it did not allow the bootstrapping process to finish. After a while, based on the error (PDOException similar to the one that appears in the first paragraph), I did a fix similar to the one at #12 (used db_table_exists(), not really that different):

  protected function load($property, $value) {
    if (db_table_exists($this->table)){
      $result = db_select($this->table, 't')->fields('t')->condition($property, $value, '=')
      ->execute()->fetchAssoc();
    }
    if ($result) {
      foreach ($result as $property => $value) {
        if (in_array($property, $this->serialize)) {
          $value = drupal_json_decode($value);
        }
        $this->{$property} = $value;
      }
      // We should only set the isNew flag as false if we loaded something.
      $this->isNew = FALSE;
    }
  }

Then I ran drush rr and everything went back up.

This is a very difficult issue, because of the WSOD. I think it might make sense to opt for applying the patch at #12 to the next release, because this can hit any production site (all it took in our case was removing an entity created by eck). The effect of the code is essentially an empty $result value, which is accounted for in the next if (because if the table doesn't exist, it certainly won't be able to load anything). I think it is fair to say that if this doesn't fix it completely, it certainly does not make it worse, IMHO.

Had the same issue and the patch in #17 resolved for me, though I had to re-roll for the rc10 release.

I've attached re-rolled patch.

We're dropping support for Drupal 7 since it has officially reached end of life on the 5th of January 2025.