"This view has been automatically updated to fix missing relationships". Referenced entity relationships removed.

It doesn't wipe out any field settings, it just adds relationships that used to be implicit but are now required to be explicit. It's possible that the relationship it tried to add is incorrect, that can happen with a complicated view, but it can't "work just fine". If that fix was applied, it means that a prior assumption is no longer true. This is mostly true if you were using a field related to the author of a node, though if I recall correctly there were a couple of relationships that used to be implicit but we later required to be explicit.

Once you save the view, the relationship that was missing got added, and the fix won't be needed again.

The automatic update does not remove fields. There must be something else causing it, and whatever is damaging the view is also triggering the automatic update.

Going to throw my $0.02 out there...

I "think" it might be a result of the "Master" display not being setup properly...

I'm getting the same error on a brand spanking new view, after being on 3.5... (well past the inclusion of this method)

After enabling the "master" display in the view settings, I setup the master display to reflect the main defaults that should be propagated down to the other displays and the error seems to have gone away. At least for now...

Might be a good place to start looking though.

I am having the problem described in #4 too.
The view works just fine, but when I go edit it I get the same error message and some fields disappear on the admin interface (and also a sort filter). I'll try to check the master view behaviour.

Hello everybody, same problem as #4. It all started when updating views module to 7.x-3-6. Please help!

Hello again, following philsward clue I have activated master view option (I had this disabled) and now fields are not wiped though automatic proposal correction message is still appearing. This time since no fields are wiped I can save view and hope this message does not come out again as mentioned previously by merlinofchaos. I will keep you informed.

Any idea where to start looking for the cause of the problem?

In my case this automatic update executes every time after the following sequence of events:
Save changes -> Switch to another display -> That display gets a few fields removed from it. Other displays and any other settings remain untouched.

I also have a fairly big view with lots of displays. I have since moved 4 displays from that into a separate view, but now both of these views get the same problem. I am not using any relationships per se in these views. Also have tried enabling master display - no effect.

Hello everybody, I thought the problem was solved when activating master page in advance options but far from true. I have more complex views using counting aggregation fields which still are wiped out. But the really critical situation is that I have discovered that if I try to create a new view from scratch and try to add a relationship the related fields are no longer available to be selected!!!
It seems like views is no longer capable of following database related fields!!
Please help Merlinofchaos!!!! Only solution for me is to create the view with an older version of views and later try to import it it newer environment but this is quite messy and in the end always will get automatic relationship repair message which acts in fact as a relationship breaker!!!!!!!!
just for the record i am using Commerce Kickstart 7.x-1.8 distro
thanks in advance

I had this problem and in my case it was caused by updating Features from version 1 to version 2. I had neglected to update all my features, causing fields to be in an inconsistent state. I just had to update my features and revert all my fields and everything was back in order.

Hello everybody,
I have this problem, my view has no relationship set, it's a pretty simple one in fact. Once I saved it and get back to editing form, all the fields were gone (only title remained)...I don't have Features installed. Views 7.x-3.7 for me.
thanks in advance

I have the same sequence of events happening as described in #10 (views-3.7).

But in my case taxonomy filter gets removed. What seemed to help: I created a relationship with the taxonomy and a new filter "Has taxonomy terms with depth" (simple without depth did not work).

Very strange and frustrating.

We are experiencing the same problem. Drupal 7.19 and Views 3.5. One thing we've noticed is that clearing the cache solves the problem for a period of time. We have memcached and apc cache running on the site. Restarting memcached without doing a Drupal cache clear solves the problem for a while and then it reappears.

Our problem seems to have been isolated to two sites trying to use the same memcache instance without including the configuration to prefix any keys with a unique string. One site would overwrite the other's keys, the other site would get confused etc etc. Explains why a cache clear would solve it for a while.

any updates,
I have noticed that the problem appear when adding a field which is a term reference.

It is a big problem when you want to edit the view and you find yourself need to rebuild it.

Updating metadata. From the responses here this:

1. Does not appear to be a bug in Views, but rather originates from the way a website is configured (either Features, Memcached, the way the master view is set up, stale caches etc). That makes this a support request rather than a bug report.
2. Does not specifically occur with Views 7.x-3.6.
3. The error does not appear erroneously, but correctly - it indicates bad configuration.
4. Field settings are not wiped out, but just appear empty. Fixing the underlying configuration problems make them reappear.

I'm leaving the issue active so that people that encounter this error message can get some help and ideas on how to resolve it.

I have reviewed the code in question and not much seemed to be wrong with it at the time. It is really not removing any field settings, it is just detecting that previously existing relationships are no longer valid and tries to repair the damage in a responsible manner.

In the two cases mentioned here where the source of the problem was found it was caused by forces outside of Views' control, by other modules messing with Views' configuration. It might still be a bug in Views though, but the evidence so far seems to indicate otherwise :)

@tmsimont and others: Whenever I see the message, I hit Cancel and then come back to the view, this preserves the fields so I can edit the view.

I've got the same issue. I need to create a lot of views. this "autofix" removes some fields and I have to cancel and check everything when cloning the views.
notice: to remove duplicate result, I've enabled aggregation then this autofix happens.
if i click save some fields are disappeared. after that when i try to add those field again they are not available anymore.

I have seen this error a number of times when working on Drupal Commerce sites.
Most recently I saw it after i added a relationship to the product referenced in the order on the shopping cart view.
Configuration:
Commerce Kickstart 1.19,
Views 3.7.
Xampp 1.8 on Ubuntu 12.04, with PHP 5.4.16 ; I tested it as well on a regular Ubuntu 12.04 LAMPP setup with Ubuntu Lampp packages (PHP 5.3)

After I try to edit the view, the message appears and both the relationship included in the commerce initial setup and my newly added relationship are gone. All the fields that were to be displayed in the view are gone as well.
If i do not click "Save", the view itself works well.

Now: the bug was notorious, *except* one case when I entered the view edit interface not by the usual Views UI, but by contextual links. After the first edit I made, this way never worked again :-(.

EDIT:
I've found a related issue https://drupal.org/node/1611692. It's not very clear to me.

Views description:

RELATIONSHIPS
Commerce Order: Line items
(Line Item) Commerce Line item: Product

FIELDS:
(Line Item) Commerce Line item: Display path
(Product) Field: Image (Image)
(Line Item) Commerce Line Item: Title
(Line Item) Commerce Line item: Unit price
(Line Item) Commerce Line Item: Quantity text field
(Line Item) Commerce Line item: Total
(Line Item) Commerce Line Item: Delete button

Adding "(Line Item) Commerce Line item: Product" was my own intervention. I meant to display "(Product) Field: Image (Image)".

What's more: you *can* edit the view a number of times, but at some point the bug appears and it's over.

Some other links pointing to a similar problem:
http://drupal.devheads.org/post-install/views-multilingual
http://support.scratchpads.eu/issues/3328 (this suggests it's related to multilingual features)

It seems as its is related to access permissions.

A similar problem was encountered in creating product views in drupal commerce. If you want to relate to the fields of the referenced product, you have to grant the View permisssion to all products (non-node enitities of DC). Otherwise the users without permission to view the product enitities will see an empty view (see Views results empty for unprivileged user when using Relationship: Content: Referenced Product). What makes it especially difficult to track that the problem does show up only when one uses Relationship & "Fields" display. A similar view with content / teaser etc renders the same content without problems.

Now, I wanted to add an image of the product to the cart view. I referenced the Image field of the product in the cart ((Line Item) Commerce Line item: Product), and put the image field from there.

The view itself works fine, but if u go to the UI of the view (edit it), the message pops up, and the ability to add relationships gets very restricted . I am sure you can't add a referenced product. I will try to provide more exact info here after more tests.

I understand that the permissions problem prevent the view from functioning properly. It seems to be that it's a bug that
a) the view itself functions well
b) that the problem appears after entering the UI of the View.
c) that the error message is not informative.

It seems to me that this behavior is just a side effect of a number factors in how the Views/UI work.

So I'm getting this error on 2 sites and after disabling Semantic Views the views work normally.

Edit: nevermind, it has started again, without Semantic Views.

I was having this problem on a Commerce Kickstart 2 site, and fixed it by disabling the Administration Language (admin_language) module. Found the solution here, with more explanation as to the possible cause: http://drupal.stackexchange.com/questions/84468/this-view-has-been-autom....

I admit I don't quite understand the explanation given there, but it seems that it may be a more general issue that is not limited to the Admin Language module.

Same problem here: all my View fields are eliminated when "This view has been automatically updated to fix missing relationships" message appear.

I'm using the "Administration language" (admin_language) module that can cause conflicts as mentioned here: http://drupal.stackexchange.com/questions/84468/this-view-has-been-autom...

EDIT:
Yes, disabling the admin_language module the problem disappear

thats not hte solution! disabling admin_language

Yes, I confirm Admin Language is the culprit. That's a *very bad thing* for the module.

Confirming admin_language is the cause. The issue is here: #2158975: Admin language causes "This view has been automatically updated to fix missing relationships" in Views.

Maybe this issue should be kept visible in the Views queue to prevent duplicates, or maybe issue a warning about admin_language on the project page?

I just started getting this error yesterday. I am not using any of the previously mentioned items that people thought were causing the problem. The view is very simple with no relationships at all. When I do an export of the view, here is a section that seems to indicate the error:

/* Field: Broken/missing handler */
$handler->display->display_options['fields']['field_org2_location']['id'] = 'field_org2_location';
$handler->display->display_options['fields']['field_org2_location']['table'] = 'field_data_field_org2_location';
$handler->display->display_options['fields']['field_org2_location']['field'] = 'field_org2_location';
$handler->display->display_options['fields']['field_org2_location']['label'] = '';
$handler->display->display_options['fields']['field_org2_location']['element_label_colon'] = FALSE;

The above field is using the addressfield module (see below).

When the problem occurs, and I try to add fields to the view, none of my custom fields show at all

Since this is a site underdevelopment, I can start disabling modules that have been recently enabled to see when (if) the problem goes away.

Environment:
Drupal 7.28
Views 3.28

Recently enabled modules
Address Field (addressfield) 7.x-1.0-beta5
Geocoder (geocoder) 7.x-1.2
geoPHP (geophp) 7.x-1.7
IP Geolocation Views & Maps (ip_geoloc) 7.x-1.25
Leaflet (leaflet) 7.x-1.1
Leaflet Markercluster (leaflet_markercluster) 7.x-1.0
Leaflet More Maps (leaflet_more_maps) 7.x-1.9
Leaflet views (leaflet_views) 7.x-1.1

I have the above modules enabled on another test site with no problems, so there may be a conflict with other modules...

WHAT THE FUDGE IS THIS, IT HAS COMPLETELY RUINED MY SITE. NOBODY ASKED THIS POS TO AUTOFIX MY VIEWS.

I, too, have experienced this issue. I only experienced this issue when moving my site from development to production, so you can imagine my frustration when this newly configured feature overwrote all of my views and stripped ALL of the fields. I couldn't even manually rebuild the views as all of the fields are now missing from the Add Fields List.

I experienced this issue when upgrading to 7.x-3.8. Since upgrading, rolling back to 7.x-3.7 no longer fixes the issue.

In order to work through this issue, I chose to export all of my views to hardcoded views saved in a custom module in order to avoid this "automatic update".

EDIT: I can provide exports if requested in order to review the types of fields used if needed. Unfortunately, the only errors I was experiencing in the logs were irrelevant to views besides some memory issues.

As near as I can tell, this happens when there is some sort of conflict in the views system. If you start removing anything you just added (content types, custom modules, content) and check the views that used to work after each step, you will find out the conflict. When the conflict is removed, everything will magically show up in the view that was damaged again.

The challenge is to figure out why there is a conflict and how to fix it.

The interesting thing here is that I have my dev and prod environments which are built on similar systems architecture.

With the same exact site, my views are having no issues in dev. However, in Prod, Views are totally wiped out. While I could roll things back in dev to see what went wrong here, my issue arose during a go-live event and is not reproducible in dev, despite a mirrored configuration.

I think that for me, this had something to do with the latest security update 7.x-3.8x for views, I rolled my site back to before the update, and everything is working fine. I can edit and change views without the website exploding. For now, I will just not update views, as I'm almost positive this is the cause.

Also, I think it has something to do with this change in particular from the change log, #102688 by tim.plunkett, dawehner: Use a proper reference for get_handlers.
- because after updating, the views say Broken/Missing Handler...

I have different views pages that show icons across my site in a grid format, as part of the content type I have a simple select list field. I use this select list to filter certain views. For instance, if I only want this an icon to appear on the front page, i will select front page from the list, and the view on the front page only shows the icons with that front page filter. If someone knows why my views are breaking with this update, I could really use some help here.

Thanks,

My Views issue, that upon upgrading, when I went to edit my view, and I got the "fix" message, but after it runs, there is only the title field, all other fields disappear - (there were no relationships in my original view), just using title, body & link fields. Trying to resolve the problem, I added the missing fields back, but it fails and I get a broken handler message. Downgrading back to 7.3.7 resolved the immediate issue/panic of all my custom view pages being empty except for the titles... Everything came back once I downgraded and cleared the cache.

sioux, this is EXACTLY what happened to me... does anyone have any idea how to fix this, is this just something we will have to accept and then completely rebuild the website? How is it possible that the update could mess things up so badly?

I have exactly the same problem since I upgraded to Views 7.x-3.8.x. Sometimes when I revert my feature with the broken view and clear the cache it then works OK. But later it may break again.

How could I revert safely my Views module to the previous version 7.x-3.7.x? Will I then lose my changes that I made to the views after the upgrade?

Sometimes when I revert my feature with the broken view and clear the cache it then works OK. But later it may break again.

Well, at least a cache clear is always suggested after an update.

I had upgraded a second site and after a few days, I needed to edit a few views block. After a few edits, I got the "fix" message and broken handlers all over the view I was working on. I did not "fix" or save the view. I used ftp and overwrote the views module 3.8.3, back to 3.7.3, and my block view was restored, without any loss of data, (including edits made after the initial upgrade).
This was the error message when the view had broken handlers: "Notice: Array to string conversion in views_handler_filter->admin_summary() (line 166 of /.../modules/views/handlers/views_handler_filter.inc)."

I am experiencing the same problem described here resulting from the Views 7.x-3.8 update. Reverting the Views module to 3.7 is the only thing that helps.

Well at least we've sorted out what issue is, something changes in the security update. Current solution... don't update views module.

I found out something that helped with the 7.x-3.8 update breaking our views. In my case I spent a lot of time turning off all forms of caching on the site. Varnish, apc, memcache, js, css, because the strange behavior would disappear for a single page view every time I would "drush cc all" but then I turned off Views Data Caching in the Advanced tab of Views Settings: /admin/structure/views/settings/advanced and now things seem to be working normally. I wonder if the issue is a conflict with other types of caching that was running on the site but for now, turning off views Data Caching is saving the day.

This is the good solution ! Thanks dgdrupler.

Will try that one, thanks!

Update:

I can confirm that clearing the table cache fixed the issue for my LAMP server, after updating the same issue started, but then after clearing the views cache, and turning it off it no longer does this. Although, it might be working now because I had removed some fields that were redundant prior to updating. On another note I updated the views module yesterday on a server running IIS, and did not seem to have any of the broken missing handler views exploding issue. So it might have something to do with apache.

I turned off Views Data Caching, along with all other Performance>caching and it did not fix my ability to use Views 7.3.8. Once again all my fields disappeared within my views pages, and all the events disappeared off my calendar page, (using calendar module). Restoring back to Views 7.3.7 repaired all of my views.

I can certainly confirm that the 7.x-3.8 version of Views is critically broken.

I've attached screenshots with the errors. Prior to the update, none of this was happening.

sioux, did you turn it off before you updated or after? It worked for me, but I turned it off and cleared the views cache before updating.

Turning off views cache worked for me. I cleared views cache, turned off views cache and then updated to views 3.8. Everything is working now. Thanks dgdrupaler!

I just encountered this problem.

Beside the good effort that @dgdrupler, @hawkdavis, et. al are handling (looking into the 3.8 “security update” as the cause for the unintended behavior)…

… I’d like to propose a different kind of change to this mechanism:

The spirit of the mechanism, according to (my understanding of) @merlinofchaos’ comments, was to explicitly declare relationships that were implied in some previous versions. The current observed behavior is that other things are impacted, albeit unintended.

I propose:

• the mechanism be changed to alert the Drupal maintainer that a change should be considered to “fix” relationships, and suggest the changes, and/or declare what is broken.
• The mechanism might then afford the Drupal maintainer a button that allows the mechanism to fix the changes automatically.
• In the meantime, the view would not be automatically altered, eliminating the errant alteration which I and others are experiencing, which promotes the sense of loss and helplessness to the “autofix” that is prevalent in this thread, whether or not the “auto fix” is malfunctioning.

I believe the above puts the Drupal maintainer back in a position of control and effective troubleshooting. And the spectrum of causes for the “autofix” mechanism to be triggered… would naturally fork into proper threads of discussion which handle those issues.

Turning off the cache as described in #48 worked for me on a solaris machine with PHP 5.4.11. Thanks for that.

Strange thing is, that the same project/installation with Views 3.8 has no issues on a ubuntu machine with PHP 5.3.3

+1 on this issue, our team has spent several hours trying to determine the cause of this.

We've found an issue that may be related and posted there as well: https://www.drupal.org/node/2153517

To restate the issue, saving any existing view, even without actually modifying any settings, causes views around the site to degrade and eventually break.

Editing a view after saving one will show broken handlers, the query for the view will be incomplete or malformed

We've found a one-liner change that seems to fix the problem, its probably a remedy and not a solution but
if you edit line 49 in /includes/cache.inc (views 3.8)

from:
else {
// If there is still no information about that table, it is missing.
// Write an empty array to avoid repeated rebuilds.
views_cache_set($cid, array(), TRUE);
}

to
else {
// If there is still no information about that table, it is missing.
// Write an empty array to avoid repeated rebuilds.
views_cache_set($cid, array(), FALSE);
}

This tells views_cache_set not to add the language code to the cid value for the cache entry....

Don't know why, but this is working as a temp solution for us....

As in #48 disabling Views Data Caching resolves this issue completely.

just turning off the data caching is a remedy, not a solution...turning off the caching can have a performance impact on your site....

Agreed but it seems there is no other solution right now.

see comment 58

Great to see we have progress hopefully this is added to the next release.

I can confirm I'm seeing this problem after upgrading to 7.x-3.8 from 7.x-3.7 on a PHP 5.4 environment and that disabling data caching does restore the handlers. Clearly this isn't really a solution, so I'd be keen for the next release to address this problem. Strangely, I do not get the same results on another environment (running PHP 5.3) but it's not clear to me at this stage whether that's a contributing factor or not.

So will turning off the cache will this restore all the fields that have been removed, or will I have to redo everything I've done since my last server backup which was 8 hours ago?

As long as you have not saved any of your views it will restore the issue.

I confirm that reverting back to views 3.7 fixed the issue and the missing fields automagically returned as soon as views 3.7 was dropped into the modules folder.

I think something in the last update (view 7.x-3.8) is causing the bug. I recreated my views plenty of time (reused a view and started from scratch) and it would lose the relationship. I didn't even use the relationship function. Not sure where the relationship is being lost.

Good news tho! I've found clearing the cache fixes the error.
Configuration > Performance > clear cache

Do not use the development tool > flush all cache. It doesn't work and nothing changes.

Once you clear the cache, your view should function as normal. Be sure to go back to the administrative view, edit the view, and cancel the last change. Once again, edit your view and all the settings should return.

Hope this helps.

Just report my situation with this same problem.

I have a server with php5.5 and MariaDB 5.5.37, it will show the problem, and all my views' fields and relationship lost. I also try some method mentioned above, but not work for me.

But I also notice that it is ok in my localhost environment, my localhost environment is php5.5 and mysql5.5.38, I am sure that all the drupal files and SQL file are same.

And then I change the server site's database connection to my localhost mysql server, then I visit the server site, it is ok.

So maybe the problem is caused by the database, I am not professional at views and database, so can not analyse it, just report and hope this helps.

Can anyone comment on the suggestion made in #58 ?

Downgrading to views 3.7 fixed our issue

Reversing the patch from : https://www.drupal.org/node/1944674 solves the issue.

By the way, I have memcached running, PHP 5.6. If I turn memcache module on, opening any view causes it to break. Or it will break by itself after a while. restarting memcached service fixes the situation for a while.

edit: All the views seem faster now after reversing the patch!

saving the view (#3) worked for me perfectly - as of now, hope the view-break won't reappear. thx @merlinofchaos for your work. i am still stunned to be able (as a non-techie) to handle complicated drupal sites. my most important site was just throwing this error and i expected to spend the rest of my day repairing it. nope - not with drupal and it's marvellous community: google led me to this thread and in #3 merlinofchaos calmed my nerves: just save the view! i did it and all is fine again. thx!!!

Same issue encountered on the website running on PHP 5.3.3. However, disabling the "Disable views data caching" as suggested works for the time being. Hopefully this can be resolved completely. Quite a frightening experience when it was first encountered that most fields on Views gone missing ... =="

After spending two days finally i mange to fix the problem by activating master view.

/admin/structure/views/settings

Always show the master display

Following up on comment 58 above here, it looks like this has connected to the proposed patch in #1944674-42: Improve performance of ViewsDataCache that Needs Review. Also, memcache is likely connected for a lot of these sites, per comment 45 in that issue.

It seems like ultimately, this could be considered a duplicate of #1944674: Improve performance of ViewsDataCache since the only related development will take place there?

Confirmed, this is still happening in latest 7.3.x, after a couple of browser refreshes all the fields of the views are lost. Using XAMPP in Windows here. I had never seen this kind of bug before (using UniServer), maybe it's server-configuration related?

Disabling Views cache did the job but is not a solution. Reverting to an older version also works, but I use jQuery update in my administration theme so it's not an option for me. This should be fixed ASAP.

BTW: Found another fix: deactivate cache, cancel all view-breaking changes, and when everything is back to normal, make some pointless change to the view and re-save it. activate cache again: view should not break anymore. Now repeat for all your views :(

I had the same problem with Entityqueues module.
I cleaned the views cache on admin/structure/views/settings/advanced page and it helps me!

I'm seeing this on a site that moved from PHP5.4 to PHP 5.5, and another that moved from PHP5.3 to PHP5.5. Disabling the Views Cache worked; I reenabled it and flushed the cache and the problem hasn't recurred... yet... will keep an eye on it though. :/

ETA: it recurred. Views disappeared and/or not updating despite different contextual filters... what a mess.. Disabling the cache is the only fix.

Same problem here with php 5.5 :( Disableing the cache (how Renee S. told), solves the problem but I think its not the best way to handle this.

Setting version to dev, hopefully this will get looked at before the next release, as large hosts like Rackspace are pushing out 5.5 to default in the next month or two.

One more vote for the issue appearing after upgrading server to PHP 5.5. Haven't found a workaround yet, and it's breaking views on my production site. Clearing caches usually fixes it for a time, but so far it's always come back, though I can't find a single triggering scenario.

Workaround mentioned in this related issue: #2442021: Broken/missing handler after upgrade

Seeing this scenario pop up now and then, not sure what the trigger is just yet. Testing out the reverting of the patch mentioned there is our next step.

I am using Memcached and the problem was caused by issue documented here: https://www.drupal.org/node/1954348
There is written, that Views tries to save memcached entry object bigger than max memcached entry size (by default in Memcached 1MB), so Memcached ignores them and in cache is some mess .
So for me was this problem solved by changing Memcached configuration file (/etc/memcached.conf) by adding line

# Increase max entry size
-I 20M

Hope this helps

had to turn off views caching views 7.x-3.10
admin/structure/views/settings/advanced

Follow up to my post in #84, we are still seeing this issue and I'm testing a patch involving how Views data is cached from #1944674: Improve performance of ViewsDataCache. Will report back if it helps.

@markbannister Can you try the patch at the bottom of #1944674: Improve performance of ViewsDataCache and see if it helps? Also - if you have any steps to reproduce that would be helpful. For us it only appears randomly.

I suspect that "randomly" has something to do with when caches fill up/expire... but that's just a feeling.

@Renee S: I agree, it is most likely due to partial caching in Views (that's the thrust of that Issue) but some of these Views aren't even cached. So it strikes me as odd that Views is caching non-cached Views data and using that data to build relationships. But there is so much going on that it's possible my understanding is just incomplete.

torgosPizza
I got to this thread from here: https://www.drupal.org/node/1955472
I was seeing this issue as well but it went away in dealing with the others, but the only thing I see consistently with views caching on is the header/footer issue.
The patch did not help with header/footer.

torgosPizza: ah, but they are -- not directly, through caching in the view itself, perhaps, but the default performance cache does do a bunch of work even if your views aren't explicitly cached.

I have updated views to 3.11 and activated caching this morning and for most of my views, the problem is gone. There is only one left. And for this view, the problem stays even for 3.10 with deactivated cache. What is your experience?

The only way I see this being set is via

    if (!empty($missing_base_tables)) {
      // This will change handlers, so make sure any existing handlers get
      // tossed.
      $this->display_handler->handlers = array();
      $this->relationships_changed = TRUE;
      $this->changed = TRUE;

because

  if (!empty($view->relationships_changed) && empty($_POST)) {
    drupal_set_message(t('This view has been automatically updated....'));

When I hit a breakpoint on that first block I can see that I indeed had missing base tables - So to me it sounds like this is just a poorly worded error, it should probably tell you which base tables are missing - 'fix missing relationships' actually means 'you have a basetable missing and I've removed it without telling you which one'

So what you want todo is examine $missing_base_tables in view.inc around line 632

Patch applied to reword the error for those of us who aren't views ultra experts