There is a bug with quering the DB schema that i want to report and submit a PR with fix

• various Joomla code that queries the DB schema does not limit the SQL queries to the current database, but usually the bug is masked / hidden due to the fact that DB prefix is used in the queries

(thus bug will appear only if you have 2 (accessible) databases on same server, with same DB prefix)

• so do you have a copy of your database (in same server) with same db prefix ?

of course your case maybe different

@ggppdk do you think it's possible that this 2 databases with same DB prefix on same server bug could occur on a shared host? (I assume all of the databases and hosting instances are segragated by Apache and are not inter-accessable... unless there is a bug in linux or Apache, but that's not my first assumption for root causes)

Of cource, i did not mean on different accounts of the shared host,
because they are not visible anyway

i mean the case that in a specific account, you create a copy of joomla's database with a different name, thus you now have 2 databases that have the same prefix for the DB tables

@ggppdk In addition, one database user must have permission to both databases. Situation is entirely possible.

I think my specific case maybe different; I only have access to one database for this site.

@photodude
Yes it must be a different case

In regards to my comment, about schema checking queries, not limiting to table_schema i mean these queries:

FROM INFORMATION_SCHEMA.TABLES
WHERE ... TABLE_NAME = ...

they must be fixed to be:

$dbname = JFactory::getApplication()->getCfg('db');
...
FROM INFORMATION_SCHEMA.TABLES ... 
WHERE  ... TABLE_NAME = ...  
  AND TABLE_SCHEMA = '.$this->_db->Quote($dbname);

because the 1st one will return results from all databases that have table with the given name

... Except for MySQL INFORMATION_SCHEMA isn't used ...

https://github.com/joomla/joomla-cms/search?utf8=%E2%9C%93&q=INFORMATION_SCHEMA

@photodude are you still seeing this? Have you been able to find a way to replicate it?

@brianteeman I do still see this occasionally. As far as I can tell it's an intermittent and reoccurring issue, so sadly no replication instructions yet. My current assumption is related to CMS or Extension updates (possibly not the extension updates themselves, but something related to checking for updates and clearing the updates cache).
I did see a "Table '______' does not have column '______' with type '______'. (From file 3.x.x-________.sql.)" type message after upgrading a site from 3.4.8 to 3.5B3 a message not there prior to upgrading.

Next time you see it please post back - presumably when you see it again you will be able to report what the previous activity was. I cant see how any core action would alter the db but who knows

Ok, here are the things I did that eventually caused Table '#__updates' does not have column 'version' with type varchar(32). (From file 3.2.2-2014-01-18.sql.) to reappear

• updated from 3.4.8 to 3.5RC2 (fixed at that point)
• Made various backend changes, (switched templates, changed global configuration for SEO, viewed various system settings, other general site use, looked at extensions update, looked at and ran a discover, looked at database (about 1-2 hours after last fix) and the warning is back.

I'm leaning towards the issue being related to one of the various backend items like discover, global configuration changes, repeated returns to update section to check for and run update-checks/updates.

ok i will keep this open and see if i can replicate it myself

I think I found the source of the issue. I went through the updates one at a time and checked the database fixer after each update.
Seems either it's something with extension updates or with the 3rd party component Freestyle Support (the update which after completing I got the notice).

I'm going to review the Freestyle package to see if it has bad/Old SQL which will narrow which side the issue exists with.

I really think it must be that component or at least something not in the
core

On 14 March 2016 at 22:26, photodude notifications@github.com wrote:

I think I found the source of the issue. I went through the updates one at
a time and checked the database fixer after each update.
Seems either it's something with extension updates or with the 3rd part
component Freestyle Support (the update which after completing I got the
notice).

I'm going to review the Freestyle package to see if it has bad/Old SQL
which will narrow which side the issue exists with.

—
Reply to this email directly or view it on GitHub
#8999 (comment).

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

Looking at the Database with the error in place, seems something is altering the #_updates table column 'version' from type 'varchar(32)' to varchar(20)

After digging through the source code, I can now confirm it is Freestyle Support causing the problem. I have filed an issue with the.
Closing as 3rd Party code issue
source code causing the issue
$qry = "ALTER TABLE #__updates CHANGE version version VARCHAR( 20 ) DEFAULT NULL";
looks like this problem code has been hanging around post J3.2.2 changes

Knew it wasnt something in core - very naughty of them to be altering a
core table

Anyway glad it is sorted

On 14 March 2016 at 22:48, photodude notifications@github.com wrote:

Looking at the Database with the error in place, seems something is
altering the #_updates table column 'version' from type 'varchar(32)' to
varchar(20)

After digging through the source code, I can now confirm it is Freestyle
Support causing the problem. I have filed an issue with the.
Closing as 3rd Party code issue
source code causing the issue
$qry = "ALTER TABLE #__updates CHANGE version version VARCHAR( 20 )
DEFAULT NULL";
looks like this problem code has been hanging around post J3.2.2 changes

—
Reply to this email directly or view it on GitHub
#8999 (comment).

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

Apparently they were altering this core table way back when the column 'version' was VARCHAR( 10 ) but didn't fix/remove the change when column 'version' was updated to VARCHAR( 32 )

"people, what can you do..."