ViewDataTable ID 'table' is already in use!


#1

Hello,

I downloaded version 2.16.0 installed and everything seemed alright, then I updated it to version 2.16.1, through the UI. I guess the connection timed out and I got a 500 server error. Then I re-uploaded the files for version 2.16.0 and I started to get a “ViewDataTable ID ‘table’ is already in use!” error.

I googled the issue but it seems that there have been only two cases with a similar error:

In both threads, it seems the problem with this kind of message gets fixed if you reupload the files manually.

Since this is a fresh installation, I dropped all the tables in the DB, deleted all the files in the server, and started from scratch. After installing version 2.16.0, and, this time, downloading the RC, I uploaded and updated the software. No errors… cool.

Then I noticed that Piwik is not tracking. As one of the things this page suggests:

http: //piwik.org/faq/troubleshooting/faq_58/

I checked the “piwik_log_visit” table… it has no rows, then, I enabled the “DBStats” plugin, and when I check the Database usage I get the same message:

ViewDataTable ID ‘table’ is already in use!

This is a fresh install, I uploaded the files manually, the FTP transfer was set to binary… How can I solve this? Is there something else I need to do? should I just re-upload version 2.16.0? I can definitely try that, but if I get the same error, how can it be fixed?

When I do a System Check, everything has a green check mark next to it.

Thank you.

UDPATE

After a while it seems I’m starting to get some data; however, the ‘table’ is already in use still persists. Here are some screen shots that will hopefully help?

I get the same messge for:

  • Length of Visits
  • Referrer Websites
  • Visits by Server Time
  • Visitor Browser
  • Search Engines

UPDATE 2
It seems the problem has to do with /piwik/plugins/CoreVisualizations/Visualizations/HtmlTable/PivotBy.php (piwik-2.16.1-rc1 doesn’t have it anymore). I’m assuming is no longer needed, so I deleted it; The error is now gone, and data is being displayed in those modules where it appeared.

The getAvailableViewDataTables function of Manager class sets the table index of the results array:

["table"]=> string(65) "Piwik\Plugins\CoreVisualizations\Visualizations\HtmlTable\PivotBy"

But it seems that the pivotBy index gets never unset (source: /piwik/plugins/CoreVisualizations/Visualizations/HtmlTable/AllColumns.php):

$this->requestConfig->request_parameters_to_modify['pivotBy'] = null; // always unset pivotBy

Could this be a bug?

My approach seems to have fixed my issue. So I’m posting it here in case it helps someone else; if, however, this is not the right approach, maybe Matthieu (or someone more familiar with the software than me) will hopefully read this and let me know.


Piwik 3.0 database upgrade error
(Stefan Giehl) #2

That might be a bug indeed. We removed the PivotBy.php to avoid some other issues. Maybe there is now a problem with already stored Settings. I’ll have a look.


(Stefan Giehl) #3

Ok. I’ve checked that. Problem only occurs when PivotBy.php is not removed in the update process.


#4

Excellent. Thank you, Steve. I’m glad to know I took the right approach by removing the PivotBy.php file.

I’m just putting this on the table for your consideration: Maybe you can add a function that checks files that are being removed in newer releases, and if they exist in current installs, then dispose of them.

Thanks.


(Matthieu Aubry) #5

Hi there,

actually this is already implemented (from On update, automatically delete from filesystem all Piwik files that are not in the latest release · Issue #5936 · matomo-org/piwik · GitHub) and it runs during auto likley it didn’t work for you because your installation timed out during auto update… for sure it will happen to other users as well until we implement a smarter auto update to prevent timeout, (can’t find the issue on github just now)


#6

Hi Matthiew,

Thanks for replying.

Just to clarify, I didn’t auto update the app… I downloaded the files and uploaded them myself. Since I did it myself, then all files got replaced but the ones that didn’t exist in the new version (e. g. PivotBy.php).

Since you already have this implemented to run during auto, could it be possible to make it run also when someone uploads the files and updates the software manually? If this is set to run like that as well, then yeah… it probably timed out and didn’t remove the file.

If nothing like this is implemented when a manual update is made, could I suggest to run a systems check before proceeding like you do on a fresh install? I way to do that could be to have a file that stores the current version (e. g. 2.16.0), and when a manual update is made, then the “new” index.php file checks if its current version set in the config.php file (e. g. 2.16.1-rc1) is the current one. Since those versions won’t match, that means the installed version is the newest one and then run the clean up and remove those files no longer in use along with any other db updates and maintenance routines you’d normally do. After all that’s done, update the “version” file with the new one, in this case 2.16.1-rc… Something like that.

Thanks!


(Matthieu Aubry) #7

Thanks for the details. I’ve added a comment in Deleting outdated files may not work during the upgrade and 1) fail silently, 2) not executed during manual updates · Issue #7986 · matomo-org/piwik · GitHub - hopefully that’ll be fixed/improved in the future!


#8

Thanks very much, Matthieu. All the best.


(Marcel Blum) #9

Thanks for posting this info, same problem happened to me and the same solution worked.


(Christian) #10

Sorry but I do not understand what is the solution for the problem…
Thanks!


#11

Read Update 2 of my post.


#12

Glad it helped.

It seems the array had a “conflict of interests” with the file, and that’s why it needed to be removed in the latest release… then again, I may very well be mistaken.


#13

After deleting PivotBy.php I get the next error:


(spain) #14

Thanks for the fast solution. Works like a charm!


#15

I have the same problem like enigma1964. I already copied the files manually and uninstalled 3rd-party extensions.

Any idea someone?

TIA


#16

frankblack and enigma1964,

are you guys using the 2.16.1-rc1 or the release version?

The message says: “Maybe the server had a temporary issue…” Can you check your log files to see if you have more details on the error and share them here?

If you’re using Piwik 2.16.1, which I haven’t had the chance to update to (I’m still using the RC), let me know and I’ll too update to the latest release, and see if I get the same error; if I do, I’ll try to track down the error as soon as I’m able to. That said, maybe Matthieu or SteveG can give a quicker answer/solution to this.


#17

I am using the release version. Which log you want to know about? piwik.log? There are several breakdowns by query, so this is difficult to read for me.

Firebug tells me about several Internal Errors e.g. for
http://bla.bla.de/piwik/index.php?date=2016-04-11&module=VisitsSummary&action=getEvolutionGraph&columns=nb_visits&widget=1&idSite=1&period=day

The parameters are:
action = getEvolutionGraph columns= nb_visits date = 2016-04-11 id = Site1 module = VisitsSummary period = day widget = 1

As a post a token_auth is delivered. But I have to confess, that I am on PHP/5.3.10. If you need more information, just ask and I will try to provide. :slight_smile:


#18

Ah, that may very well be the culprit, since the required config should be PHP 5.3.3 or greater…

To clarify, I was talking about the PHP error logs… but what you’ve posted may also help.

Can you run a System Check under Diagnosis to see if there may be other issues that would need to be resolved?


#19

Too bad, I can not switch the PHP version right now. But I don’t want to have an unsecure version running on the server. The System check was ok. So I have to wait until our IT department moves forward.

But thanks for the hint!


#20

No problem, don’t mention it.