Update.php fail after upgrade

update.php shows this error?!? That would be very strange – under no circumstances should an update function trigger a Search API search.
What updates were you trying to run? Does it say which update produced the error? Do you maybe have some other search-related contrib, custom or feature modules installed that might be executing update hooks?

I also tried to install version 1.6 and in my case update process was frozen (no progress bar, no messages in log, just screen with selected menu "run updates"). After that, my site was in development mode and I returned the previous version.

I'm seeing the same error from update 7107, for what it's worth.

That's strange – update #7104 should have converted all text tables to the new schema, with a single fulltext table with the mentioned "field_name" column. Due you maybe have something like Features set up, or a complex deploy process, which might result in that update's changes being reverted, or not correctly applied?

In my case, Features could be the culprit. I didn't originally build this site, but I see a Feature exists that's related to Search API. Perhaps that's responsible.

I just tried updating this module as well and ran into the same issue as #6: "Cannot change the definition of field search_api_db_search_node_index_text.field_name: field doesn't exist."

In my case that's because I have set up 2 different databases: 1 for the site and 1 for the search_index. Update 7107 tries to change the table which exists in the search_index database by doing queries on the default database.
Previous updates were getting the database-connection manually.

Damn, you're right, didn't proplery account for a different DB being set in that update! (Did remember in all the others, apparently, though.) Thanks a lot for reporting!
The attached patch should fix this issue. Would be great if someone could test it!
I'll also include a note in the release notes – maybe someone does read them.

I am getting this issue as well. In my case everything is setup using features. The patch does not work for my situation. Any idea how I can fix this feature issue?

I had an error with table search_api_db_default_node_index_text, so I add validation for tables:
if ($text_table && db_table_exists($text_table)) {

I’ve tried the patch form #12, but with no success. I have a site set up with features too, it is a Commerce Kickstart distribution.

Also had the same problem after applying patch #12.

drush search-api-server-list
 Machine name  Name             Status
 zarquon       Zarquon          disabled
 zarquon_db    Drupal database  enabled

If you've got a setup with Features, the problem is most likely that you reverted the feature after running the update, which you shouldn't do. See the (numerous) other issues about the same problem in this queue.

This issue only applies if you have two DB servers setup, and don't use the default database for the search server. In this case, the patch in #12 should help and it would be great if you could test it and post feedback.

Thank you for your swift reply :)

I confirm it is controlled by features, but there where no revert before running update (hook_update_N(). drush up -y was we I did. This updated failed on one of our staging servers. To confirm that nothing changed when these servers restore from production, I checked the production db. directly.

Production server

show tables like '%search_api_db%';
+------------------------------------------------+
| Tables_in_elmcip (%search_api_db%)             |
+------------------------------------------------+
| search_api_db_kb_content                       |
| search_api_db_kb_content_field_node_ref_event  |
| search_api_db_kb_content_field_node_ref_work   |
| search_api_db_kb_content_field_tr_critical     |
| search_api_db_kb_content_taxonomy_vocabulary_1 |
| search_api_db_kb_content_taxonomy_vocabulary_2 |
| search_api_db_kb_content_taxonomy_vocabulary_4 |
| search_api_db_kb_content_text                  |
+------------------------------------------------+
8 rows in set (0.00 sec)

A bit baffled by this result.

 Search                               Database search (search_api_db)                                           Module  Enabled        7.x-1.5
 Search                               Search API (search_api)                                                   Module  Enabled        7.x-1.20
 Search                               Search facets (search_api_facetapi)                                       Module  Enabled        7.x-1.20
 Search                               Search pages (search_api_page)                                            Module  Enabled        7.x-1.3
 Search                               Search views (search_api_views)                                           Module  Enabled        7.x-1.20
 Search                               Solr search (search_api_solr)                                             Module  Enabled        7.x-1.11
 Search Toolkit                       Current Search Blocks (current_search)                                    Module  Enabled        7.x-1.5

This server have two search servers defined. One is MySQL/MariaDB that aslo Drupal runs of. The other is a Solr server, but it is currently disabled.

A little quick stepping in a debugger at foreach ($options['indexes'] as $index_id => $fields) gave me:

indexes = {array} [3]
  default_node_index = {array} [10]
  kb_content = {array} [23]
  test_tag = {array} [4]

That is very odd. This installation only got one index.

That is very odd. This installation only got one index.

Well, are these other indexes in the server options in the feature? In that case, you've got your error source. Just remove them from the options and the problem should be solved, I'd say.

Just a quick re-roll of #15 against latest version so I can add it to our make file.

#23 works! Thanks

Well, better late than never, I guess. Thanks a lot for testing and reporting back!
Committed.
Thanks again, everyone who worked on this issue!