Fatal error: Call to a member function get_option() on a non-object in $base_url\sites\all\modules\views\includes\view.inc

I had this exact error as well - drupal 6 to 7 migration, some fields and content types seemed to not make it over completely. Any attempt to edit content types that were afflicted caused this error to output, same with attempts to create new content of the same type.

My only work around was to basically create a copy of the content type and go through the fields one by one to find the offending field causing the problem and create a new instance of it. Messy stuff.

It depends on what your views are doing with the data. In my case it was simply a "profile" content type I had to recreate. I just called it "profile 2" using virtually the same fields as "profile" had. In my views I simply filtered for content of type "profile" as well as "profile 2" so that the old profile content and new would be included.

Same problem, also a D6 -> D7 migration, but I could edit the affected content type on August 9. Something happened in between then and last week, but I can't figure out what it might have been.

Here's the call stack if that helps anyone:

( ! ) Fatal error: Call to a member function get_option() on a non-object in C:\Stash\Web\LCHC\sites\all\modules\views\includes\view.inc on line 2481
Call Stack
#	Time	Memory	Function	Location
1	0.0007	634568	{main}( )	..\index.php:0
2	2.3648	44051192	menu_execute_active_handler( )	..\index.php:21
3	2.3698	44319096	call_user_func_array ( )	..\menu.inc:516
4	2.3698	44319416	node_page_edit( )	..\menu.inc:516
5	2.3699	44319944	drupal_get_form( )	..\node.pages.inc:15
6	2.3699	44320880	drupal_build_form( )	..\form.inc:131
7	2.3700	44323488	drupal_retrieve_form( )	..\form.inc:341
8	2.3755	45041160	call_user_func_array ( )	..\form.inc:800
9	2.3755	45041648	node_form( )	..\form.inc:800
10	2.3909	45078712	field_attach_form( )	..\node.pages.inc:309
11	2.3910	45079448	_field_invoke_default( )	..\field.attach.inc:568
12	2.3910	45079912	_field_invoke( )	..\field.attach.inc:386
13	2.4249	45778800	field_default_form( )	..\field.attach.inc:209
14	2.4252	45786800	options_field_widget_form( )	..\field.form.inc:81
15	2.4252	45790112	_options_get_options( )	..\options.module:86
16	2.4252	45790192	module_invoke( )	..\options.module:245
17	2.4252	45794568	call_user_func_array ( )	..\module.inc:826
18	2.4252	45795144	node_reference_options_list( )	..\module.inc:826
19	2.4252	45795192	_node_reference_options( )	..\node_reference.module:994
20	2.4252	45795192	node_reference_potential_references( )	..\node_reference.module:728
21	2.4255	45796968	_node_reference_potential_references_views( )	..\node_reference.module:800
22	2.4255	45797784	references_potential_references_view( )	..\node_reference.module:822
23	2.5267	56353088	views_db_object->get_items( )	..\references.module:189

Update: OK, it was the node reference field that was causing the problem. On August 9 that field had not yet been migrated, which is why I could successfully edit the content originally. When I look at the Migrate Fields page (/admin/structure/content_migrate), it shows the following errors for the node reference field:

• The field uses the view Locations to determine referenceable nodes. You will need to manually edit the view and add a display of type 'References'.
• Missing formatter: The 'node_reference_taxonomy_term_reference_plain' formatter used in 9 view modes for the field_location field is not available, these displays will be reset to the default formatter.

I had already manually created the References display, but I had failed to update the field settings for the field to point to the references display (which I could only do by clicking on "Node reference" under Manage Fields — clicking "edit" got me the same error as above.

Taking these steps resolved the problem, and was a lot less work than recreating the content type. Hope this helps other people. (I'm going to take the liberty of marking this fixed, but if anyone can't resolve this by fixing problems reported on the Migrate Fields page, by all means, reopen it.)

I thought I described the steps pretty well above.

1. First I looked at the Migrate Fields page (/admin/structure/content_migrate) and found which fields that appeared on the problematic content type had errors.
2. From that page, I was able to determine that the problem was with a node reference field, and the error message told me to manually edit the view "Locations" and add a display of type "References."
3. As instructed, I created a new display on the view "Locations" and chose "References" as the display type. I saved the changed view.
4. Then, I went to the Manage Fields tab on the problematic content type. Next to the problematic node reference field, I clicked "Node reference" in the "Field Type" column. From there, I changed the value of "View used to select these nodes" to "Locations - References" so that it now pulls data from my new References display.
5. I saved the field settings, and then my problem was solved and I could edit content again.

See if you can replicate those steps on your site and let us know if it solves the problem.

Thanks @BrightBold - your solution worked for me, much appreciated :-)

Thanks very much!
It worked for us too!

In case it might help someone,
I disabled the Views Data Export module(contrib) and I didn't have the fatal error again.

Created a patch needed by my team for this issue - a complication is we discovered this while executing a term merge using the taxonomy manager.
Error was: "Fatal error: Call to a member function get_option() on a non-object in sites/all/modules/views/includes/view.inc"
line 2574