Errors with 7.x-3.8

I believe this may be a configuration issue on your end. The view is looking for a Date field called "field_date", and not finding it on (some of) your entities. Perhaps your view is configured to retrieve (some) nodes that don't have a field of that name?

It's not a misconfiguration. The code assumes $date_field_name is an entity field but it could be an alias.

My view has two instances of the date field (startdate and start+end date).

    else {
      // I'm not sure why the "field_data_{field_name}_delta" field is part of
      // the $row, so it's possible that it will sometimes be missing. If it
      // is, make an educated guess about the delta by comparing this row's
      // start date to each of the entity's dates.
      dsm($entity, __FUNCTION__); <========
      dsm($date_field_name, __FUNCTION__); <===========
      $date_field_delta = 0;
      foreach ($entity->{$date_field_name}['und'] as $ndx => $date_array) {
        if ($date['start']->originalTime == $date_array['value']) {
          $date_field_delta = $ndx;
          break;
        }
      }
    }

but the field field_field_date_and_time_1 in `foreach ($entity->{$date_field_name}['und'] as $ndx => $date_array) {` does not exists.

Please check that by adding the two lines dsm() from #2642860-4: Errors with 7.x-3.8

Here's an update to a patch I wrote for another issue, which should remove these log messages you're getting.

The problem here boils down to date_ical not having enough information to properly build a unique UID for each event. The situation you guys have leaves date_ical unable to determine the delta for the date field that it's using, which means it has to assume that delta is 0. Previously, the code was making a different (incorrect) assumption, and that was causing the warning messages.

Unfortunately, assuming the delta is 0 is not really the correct course of action. There may be a situation in which two different events will now be given the same UID, which is similar to the problem I was trying to remedy when I wrote the original version of this patch for #2644520: Dates through relationsships doesn't get unique UID. Hopefully there won't be any circumstances where the change I added for this patch will cause non-unique UIDs, but I don't know enough about the different ways that views can be configured to guarantee that.

@coredumperror I guess your patch is not solving the problem as my view has no relation.

When adding a field twice views creates an alias. Is an alias a relation?

No, I don't think an alias is a relation. A relation is when you need to pull in data from another table that's related to the main table you're pulling from. Like if you have a Node Reference in your content type, and you want to pull the entire node it's referencing into your view.

I'll have to look more into how aliases work to learn how to deal with this. But I'm curious: why are you adding this date field to your view twice? If I understood the purpose of that, it might help me find a solution.

I can confirm that for events.drupal.org, commit 4e9284b, the equivalent of #7, fixes an issue with the same notice.

fixed in 7.x-3.10 to be pushed shortly