Files are up to date 2.09 but database 2.04 version upgrade.php not working

[airtetdotin]

Some times saying cache directory not present but it presentee in home directory. some times old and outdated file please help me.
http://topindianforum.com/upgrade.php

[margarett]

The message about the database version is not important. There are no database changes for a long time, that's why the patch updates don't increase its version
So you can just ignore that.

About the cache error, the exact error is required

[kat]

On your upgrade page...

Notice: Undefined index: upgrade_upgrade_utility in /home/topind/public_html/

Notice: Undefined index: upgrade_overall_progress in /home/topind/public_html/upgrade.php on line 3502

Notice: Undefined index: upgrade_time_elapsed in /home/topind/public_html/upgrade.php on line 3527

Notice: Undefined index: upgrade_time_mins in /home/topind/public_html/upgrade.php on line 3528

Notice: Undefined index: upgrade_time_secs in /home/topind/public_html/upgrade.php on line 3528

Notice: Undefined index: upgrade_step in /home/topind/public_html/upgrade.php on line 3493
1: Login

Notice: Undefined index: upgrade_step in /home/topind/public_html/upgrade.php on line 3493
2: Upgrade Options

Notice: Undefined index: upgrade_step in /home/topind/public_html/upgrade.php on line 3493
3: Backup

Notice: Undefined index: upgrade_step in /home/topind/public_html/upgrade.php on line 3493
4: Database Changes

Notice: Undefined index: upgrade_step in /home/topind/public_html/upgrade.php on line 3493
5: Delete Upgrade

The upgrader was unable to find some crucial files.

Please make sure you uploaded all of the files included in the package, including the Themes, Sources, and other directories.

I'd pay heed to that message, in red. If you uploaded the files, using Filezilla, that MIGHT be the problem, if you had the "Transfer type" set to the default setting, "auto". Change it to "binary" and you might get lucky.

[margarett]

If you are already in 2.0.9 you *DON'T* need to run upgrade.php!

[kat]

That's true. I wonder what he's, actually, trying to achieve...? Trying to upgrade coz he's seeing the older db reference?

We really ought to do something about that stooopid message, don't you think?

[margarett]

Kill it

[Kindred]

it is not a "stupid message".....   the message IS completely correct (technically)
it just so happens that there have been no actual database changes - so the logic in displaying the message is a little skewed... but if there had been database changes since 2.0.4, then it would be absolutely necessary to have the message displayed....

[airtetdotin]

Is there any way to upgrade only database. now i am going stick it because no problems with 2.09 version of files and 2.04 database.

I tried to freshe install 2.9 with Old database. it asking Upgrader not Installer.

I have downloaded 2.09 large upgrade package uploaded to where 2.09 files are and opened upgrade.php. database upgrade processed without no errors.
I am going mark this thread problem as solved. any suggestions.

[margarett]

The database doesn't need an upgrade...

If you really want to have versions matching, go to phpmyadmin, table "smf_settings". The first record is the database version, edit it directly

Again, you don't need to do it...

[kat]

To put it in words of one syllable (kinda) the database and the software aren't and don't have to be, the same.

Kindred's observation is correct. However, my feeling is that it should only scream if the database really IS in need of an update, otherwise we'll keep getting people trying to do exactly what you are.

[Kindred]

while I agree, in concept, k@....   how does one determine, during an error, if the database has received an upgrade during a previous release - so that the message can be shown or not shown properly?

[kat]

Can the script not look at the version and compare it with the current one? (Just curious)

[Kindred]

that's what it does right now... which is what leads to the confusion.

for example

8.0 is released - database value is set to 8.0
8.0.1 has no database changes - database value remains 8.0
8.0.2 has no database changes - database value remains 8.0
8.0.3 has a few database changes and thus, updates the database value to 8.0.3.
8.0.4 has no database changes - database value remains 8.0.3
8.0.5 has no database changes - database value remains 8.0.3


if an error occurs in 8.0.1 or 8.0.2 - it is going to see that the database does not match the version.
if an error occurs in 8.0.3 it notices that the database matches the current version
if an error occurs in 8.0.4 or 8.0.5 - it is going to see that the database does not match the version.
This is what happens currently.....

in these cases, there *IS* an actual error referencing something in the database.
the versions do not match - so, the system tells you the actual error *AND* notifies you that the database versions do not match.
both of these conditions are TRUE...
the fact that the second condition can be ignored because there were no actual changes in the database between versions (this time) is the problem...

[kat]

Exactly.

I'm no coder, as we all know. But, I'd've thought that getting around that would be relatively easy.

'course, I could be VERY wrong.

[Kindred]

getting around it how?

look at the logic...   how does the error generator know if the database should have or should not have been updated?
The only thing it can do is compare existing value against current version.

The "fix" actually would be to change the error message to indicate that the database noticed a difference, but that doesn't mean anything unless there were database updates since (current value). There is no really good way to (logically) do that, except to update the database every time there is a point-release.... which is something we don't want to do, usually.

[kat]

Dunno, mate. I can't code.