Issue: Table 'xxx.vw_upgradelog' doesn't exist in src/XF/Db/AbstractStatement.php

So by your other report (https://www.vaultwiki.org/issues/6462/), it seems like you got past this one somehow.

Can you offer any insight into what you did to get around it?

I actually can't see a logical path to reproduce this, because:

• if vw_upgradelog was renamed to xf_vw_upgradelog by the XF2 upgrade
• The very next line of code creates the vw_patchinfo key that says vw_upgradelog was renamed
• The vwStopProcessing call that throws your error message must run in the next request, because the call is before any upgrade steps
• When resolving the name of vw_upgradelog for the query:
  
  • If a path based on the version numbers runs too early for the upgrade it uses the updated name
  • If all other paths fail (expected), the vw_patchinfo key exists, so it uses the updated name.

If this was solved by just reloading the page, possibly this can happen if you clicked the "Upgrade" button again, while the upgrade is already running in another browser tab, making two concurrent upgrade processes. I'm not sure that it is possible to do this by double-clicking the "Upgrade" button, because it requires one of the processes to perform a browser refresh first. But this theory requires precise timing, because one request needs to try to run a query while another request is between two immediately subsequent lines of code.

• The first request hits vwStopProcessing, and logs an entry to vw_upgradelog successfully, and reloads the page
• You click "Upgrade" again, starting a second request.
• After reloading, the first request reaches the phase where it renames the vw_upgradelog table
• The second request hits vwStopProcessing, it can't find vw_upgradelog anymore, throws your error
• The first request reaches the next line of code, and creates the vw_patchinfo key saying that vw_upgradelog was renamed

Here's what happened:

• While I waited for the VW upgrade screen the other error had already occurred, but I was not aware of it.
• 11 hours later it was still running so it was clear the process was stuck. I refreshed the page in the hope to continue the process. IIRC this then lead to the above error.
• I closed the page and went to:
  /admin.php?add-ons/
  Saw VW as an upgradeable addon for version 4.1.2 and clicked upgrade:
  /admin.php?add-ons/vw-vw/upgrade
• This gave me an upgrade modal for a bit, but quickly resulted in the above error again.
• After a few minutes I did go back to the addon overview and click upgrade again. This then lead to exactly the same error.
  After trying a few more times, it was clear that Im stuck in the upgrade process until I find a solution to this error.

UPDATED the above text.
I assume that reloading the upgrade page may have caused a second upgrade process.
Could it be that after 11 hours the upgrade process was still running, while only reaching version 4.1.2? Do I need to keep it running for so long?

Also: It probably unrelated, but just in case I'll mention it here. I have encountered an error for these addons:
https://xenforo.com/community/thread...6#post-1724810
I encountered the error some time before and some time after the upgrade process. Not during.
I did a rebuild of master data but this did not help.

And its PHP 7.3

When I was talking about a second upgrade process, I was discussing a race condition where one process could run a line of code that the other process was also about to run. If the processes are 11 hours apart, this would not happen.

This tells me that the upgrade process successfully renamed the table vw_upgradelog to xf_vw_upgradelog, but did not successfully execute the next line of code, which logs that the rename was successful. You will keep having the same error until the log entry exists.

You should make sure you have the following in both vw_patchinfo and xf_vw_patchinfo:
xf_vw_patchinfo should contain all the rows that are in vw_patchinfo:
Make sure you have the following in xf_vw_upgradelog:
The only situations I imagine this happening normally:
- The server rebooted while the upgrade was between those lines of code.
- The PHP process manager rebooted while the upgrade was between those lines of code.
- MySQL started backing up the database while the upgrade was between those lines of code, resulting in a "MySQL has gone away" error.
- MySQL rebooted while the upgrade was between those lines of code.
We are talking about something happening in a fraction of a second that could have interrupted the process.

I suppose it is also possible that you didn't have a vw_patchinfo table in your XF1 installation, which would be strange, but could have also caused the error.

In my xf1 install I do have a vw_patchinfo table. The value is:
patchid: 2
version: XF 1.3.0 Beta 1
label: proxy

Those values seem weird for a XF 1.5 install.

In my xf2.3 install I do have a vw_patchinfo table. The value is:
version: 4.0.21
label: patchinfo
And also one with same version and apikey as label.

I added an entry to vw_patchinfo with version 4.1.1 and label x_upgradelog.

xf_vw_patchinfo has an entry with version 4.1.1 and label x_upgradelog.

xf_vw_upgradelog had an entry with upgradetype XF2 and version 4.1.8 and step 0 and offset 0.
I changed this.

I then tried the upgrade process again and had the exact same error.

For vw_patchinfo, you missed the colon in version ":4.1.1"

For xf_vw_upgradelog, I was going by where this error should normally occur. If the upgradetype "X2" row was "4.1.8" that's already newer than "4.1.0". Changing it to an earlier number would restart some upgrade scripts and most likely cause errors on the next attempt.

I'm assuming you have other rows in your xf_vw_upgradelog table with versions of ":4.1.0 Alpha 1", since you reported elsewhere an error later in the upgrade.

If so, it seems like your upgrade almost reached the end, so it knew that vw_upgradelog was xf_upgradelog, but then it "forgot" that information after a while. Since the entry is missing only from vw_patchinfo, this seems like it was deleted for some reason.
- When you noticed that your upgrade was "hanging" after 11 hours, were there any indications of a MySQL error? MySQL has plenty of disk space? Possibly the new value was still in memory and InnoDB didn't try to write it to disk until later. If the disk was full, the value could have been lost that way.
- This could also happen when restoring the database from a backup, if only tables starting with vw_ are restored. In this case xf_addon and the xf_vw_ tables would still have the new state.

I added the colon to the version of vw_patchinfo

For xf_vw_upgradelog XF2 I changed it back to 4.1.8 and step 0.
Here are the versions for the following rows in xf_vw_upgradelog :
A+ 4.0.9 Beta 1
ACT 4.0.0 Alpha 1
ALL 4.0.9 Beta 1
C 4.1.2
CD 4.0.28
F 4.1.2
L 0.0.0
M564 4.0.9 Beta 1
XF130 4.1.0 Alpha 1
XF150 4.1.0 Alpha 1
XF1T2 4.1.0 Alpha 1
XF21 4.1.0 Beta 1
XF22 4.1.0

I started the upgrade around 4.30AM and noticed it was still hanging at 3PM.
I dont see any diskspace or memory issues. I did not encounter any errors It was merely the length of time and the fact that the screen still showed the same version it was working on: 4.1.2
The logs do show that around 5.30AM there was a peak of relatively high CPU, load and IO. And around 2.30PM high IO and bandwidth use.

You've probably been able to complete the upgrade at this point, but if you could email your recent upgrade logs in internal_data/vw_logs/upgrade/ it could give some clue to what happened.

I have not been able to complete the upgrade as I am encountering the same error as above when I try to enable the addon:

XF\Db\Exception: MySQL statement prepare error [1146]: Table '.vw_log' doesn't exist in src/XF/Db/AbstractStatement.php at line 230

XF\Db\AbstractStatement->getException() in src/XF/Db/Mysqli/Statement.php at line 207
XF\Db\Mysqli\Statement->getException() in src/XF/Db/Mysqli/Statement.php at line 46
XF\Db\Mysqli\Statement->prepare() in src/XF/Db/Mysqli/Statement.php at line 61
XF\Db\Mysqli\Statement->execute() in src/XF/Db/AbstractAdapter.php at line 96
XF\Db\AbstractAdapter->query() in src/addons/vw/vw/_core/controller/db/xf2.php at line 227
vw_DB_Controller_XF2->query_first() in src/addons/vw/vw/_core/model/db/mysql/vw.php at line 25
vw_DB_MySQL_Model->select() in src/addons/vw/vw/Setup.php at line 1349
vw\vw\Setup->onActiveChange() in src/XF/AddOn/AddOn.php at line 704
XF\AddOn\AddOn->onActiveChange() in src/XF/AddOn/DataManager.php at line 206
XF\AddOn\DataManager->triggerRebuildActiveChange() in src/XF/Entity/AddOn.php at line 128
XF\Entity\AddOn->_postSave() in src/XF/Mvc/Entity/Entity.php at line 1324
XF\Mvc\Entity\Entity->save() in src/XF/Admin/Controller/AddOnController.php at line 134
XF\Admin\Controller\AddOnController->actionToggle() in src/XF/Mvc/Dispatcher.php at line 362
XF\Mvc\Dispatcher->dispatchClass() in src/XF/Mvc/Dispatcher.php at line 265
XF\Mvc\Dispatcher->dispatchFromMatch() in src/XF/Mvc/Dispatcher.php at line 121
XF\Mvc\Dispatcher->dispatchLoop() in src/XF/Mvc/Dispatcher.php at line 63
XF\Mvc\Dispatcher->run() in src/XF/App.php at line 2826
XF\App->run() in src/XF.php at line 806
XF::runApp() in admin.php at line 15

There is no table vw_log while there is a table xf_vw_log

I have emailed you the upgrade log.

Okay, by reviewing your log, I found out what happened.

In 4.1.3 on XF 2, there is an upgrade step that cleans up a problem during fresh installations that used the 4.1.1 upgrade script, which is the version where vw_ tables were renamed to xf_vw_ in XF 2. Apparently, in some versions of the 4.1.1 install script, it actually created both vw_ and xf_vw_ tables for many tables, rather than only the xf_vw_ variant. In the 4.1.3 upgrade, it tried to resolve this by just removing tables that still matches the old naming pattern if there was a matching table using the new pattern.

But 4.1.3 did not consider that the vw_patchinfo table needed to be excluded if its upgrade script was also being run during the middle of an unfinished upgrade from XF 1.x (only safe to do after the XF 1.x upgrade), because it is actually normal (and necessary, as you've found) to have 2 copies of this table in that case. The reason why vw_patchinfo exists even after this is because the table recreates itself whenever patch data is logged.

In order to resolve the issue, you basically just need to copy all the data from xf_vw_patchinfo back into vw_patchinfo.
This is the opposite of a query I asked you to run earlier.
After doing this, the upgrade should proceed to the end.

This issue will be resolved in the next patch release. If you run the upgrade again before then, you should edit src/addons/vw/vw/_install/lib/upgradepath/steps/4/1/3/C/xf2.php. Find:
Replace with:
After the upgrade is complete, you can safely remove the vw_patchinfo table manually. You can test this by renaming the table first. The problem only arises when it is removed before the XF 1.x upgrade has completed.