Taxes are all gone after update

Hi!

I recently updated my OC to 1.5.6, now I know it wasn't such a smart move, but anyway, now all prices on my webshop are showing without taxes.
So price incl. tax and price excl. tax are exact the same and shipping cost, invoice fee etc. are all showing without tax, just as if tax calculation would be turned off.
But under settings for my store it is turned on to "Display prices with taxes", and I have tax class and rate configured (also tried setting up a new one).
And when I thought it might have been a bug in OC 1.5.6 I installed version 1.5.5.1, but still the same problem :/

Anyone got an idea on how to solve this? or perhaps give a hint to the right direction...

Regards
Fredrik

Different symtom, same essential problem, same two basic approaches:
http://forum.opencart.com/viewtopic.php ... 62#p426562

Well, if you read my entire first post, you would see that I tried installing a new (old) version.
Now I have even tried using my backup for 1.5.1.3 but that damn issue is rolling with.
I erase all files on my server, then I put back all my files from when I used version 1.5.1.3 (this is the version I've used most and was the one before I installed 1.5.6). So one would think that the problem should be solved, but no, it's still there.
Can it be something with the SQL database, because it seems as if I can't restore that using one of my backups (I get an error message, can't see it now since I'm removing all my files from the server once again).

Upshot: make a new database or prefix-database, nude and hollow, and populate that with the original database THE SAME WAY you backed up the database, THEN be sure that both config.php files have that new one's username and password. If your db backup was from phpMyAdmin Export, then use phpMyAdmin Import. If your db was from OC admin System / Backup then use System / Restore (or with an extension it could be called Export / Import). The reason for that is that the data are the same but the file syntax differs slightly between the .sql files made the two ways, so don't mix them.

"Well, in your entire opener" the term 1.5.1.3 happens to be missing, along with mention of reverting to it. What I saw and see is that you upgraded something unstated to 1.5.6 and then tried 1.5.5.1, so I suggested reverting to whatever it was. You are frustrated, so let's go with what you've now said, you have a 1.5.1.3 from backup.

The jump from 1.5.1.3 all the way to either 1.5.5.1 or 1.5.6 straddles significant core and database changes. IF you let the upgrade mess with the database, then you must reinstate the database as it was, that will work with 1.5.1.3. Neither extreme of version will know exactly what to do with the opposite vintage of database. The ORIGINAL database itself will need to be restored, IF you did not take the precaution of setting up a new database name or prefix for the upgrade(s).

The fileset itself should be intact, just be sure that the two config.php files DATABASE sections refer to the database in effect, and that it is the database that your 1.5.1.3 knew in the first place. The fileset is not the problem. Restoring the database may have run amok of the username/password. See Upshot, a blank nude and hollow database should take in the original backup via phpMyAdmin.

I assume that by "SQL" you mean "mysql" . . .

Yes, I am truly sorry, I have no one to blame but me for having these problems but unfortunately I let some of my frustration go over you. Thank you for still trying to help me.

Even if I don't fully understand the things I need to do, I've done this so far;
I did a clean install of version 1.5.1.3 and since I didn't find a way to create a new database (I think my web hosting company doesn't allow that) I erased all data in the existing one.
I then went to mysite.com/install and followed the steps to install OC.
So now I have nothing in my store, a pure and clean set up I would think.
As I understand, now I should go to "System->Backup/Restore" and restore my backup of the database from when it all worked? Am I correct?

AFTER that is done, I should move both config.php files from my backup when the site worked and put them back to the server. Am I correct?

Regards
Fredrik

Yes. Your account might have only one allowable database, but you can usually work around that by giving a separate "prefix" to different uses of the one database (each will then put in its own tables). The brand new database is empty. Restore prior good-working-order (GWO) database. Check the two different pairs of config.php -- the originals will look to the original databasename/username/password, and would need to match whatever the newdatabase name/username/password are. Probably don't need the original ones but don't throw 'em away, either.

You're almost there. (Usually some blue air helps, but you've probably already taken care of that part.)

As I've already noticed I am a terrible person to help, so therefore I did go ahead and tried to restore my backup of the database, the "same" way I did to take it, using OC "System->Backup/Restore"-function.
But I can't, I get this error message:

In category table's list of fields (columns) only one field, linkto, is missing. If you have /vqmod/ installed, flush its cache. If you HAD vqmod installed but dinna put it back into service, do that, THEN retry. That missing field (column) can be manually inserted. It should be in there, that's a longstanding basic feature. (Databases resemble spreadsheets, but top row is special and left column is special -- columns are fields, or data types, rows are records, or individual entries.)

For database manipulation, does your host control panel allow you to use something called phpMyAdmin? That would simplify tucking in that field. If so, we can step you though it.

The error may or may not have aborted the Restore. Does the store show stuff in it -- does that turkey have stuffing?

IF it aborted, there is a quick workaround. In System / Restore uncheck the category table. Rerun it. That table can be fiddled with and then stuffed in a little bit later. There would be no visible categories (and consequently no visible products) meanwhile but other stuff would be there.

I've now re-installed VQmod but I still get the same error message.
Yes I do have access to PHPMyAdmin...

It kind of sorta restore things... I see some of my pictures back in the store front, such as for manufacturers, so it restored my banners. But nothing more that I can see right away...

Backing up between reading and editing here.

(1) Flush vqmod cache. (2) Another way is using a text editor that can handle a big file. How big is the .sql file? (Good, you have phpMyAdmin, and good, dinna abort entirely, is missing categories and so also won't show products but they should be in there.)

(1) No cache in VQmod (I cleaned it before putting it back on server)
(2) Yes I do have phpMyAdmin
(3) 2.61MB
(4) I've tried restoring again, same error message

Per (4), retry with Category table unchecked. That way it will skip the table and not just stop there (the tables sail through in alphabetical order).

Well, I tried cleaning the both cache (system and VQmod) and I now have a different error message when trying to restore;

That one can wait (IP blacklist), the prior one matters first (category).

Okay. The normal set of fields is: " Full texts, category_id, image, parent_id, top, column, sort_order, status, date_added, date_modified". Your thrown error showed "... top, linkto, column ...". That is not where the version is handling the links that matter most (products). The linkto must come OUT.

Go ahead and diddybop into phpMyAdmin . . .

You'll initially choose database(s), then click phpMyAdmin, then click database name at top of list. You'll see a full list of tables in the main screen, partial roster on the left. Then give a shout.

uhm, yea now I'm probably too tired. But I do believe the "restore-action" have been able to go past that category problem, because I can now see categories in my store front (none in admin though).

Then the essential first question is answered, category table went through. It has an unwanted field (column) in it. The store sees categories, probably also products.

******************************* ******************************* ******************************* *******************************
If you're tired, then you may want to take a break, maybe even to bed, first. [Which timezone are you in (gmt Greenwich +/- what)?] I see the timezone. Go to bed! Take it fresh in the morning. [Done deed, zzz.]
******************************* ******************************* ******************************* *******************************

From above, "Go ahead and diddybop into phpMyAdmin . . . You'll initially choose database(s), then click phpMyAdmin, then click database name at top of list. You'll see a full list of tables in the main screen, partial roster on the left."

I JUST NOTICED SOMETHING THAT YOU NEED TO DO AS SOON AS YOU'RE IN YOUR CONTROL PANEL. WON'T SAY IT TILL YOU'RE IN THERE. For that, and given that you're past bedtime, see PM when you awaken and return, you can fix that before turning to database. [Under control.]

Update.-- There is no such thing as a bad nap. Resumed. There is no such thing as a good foredoom. Upgrade reversed. Private matter remedied -- domain was unlocked, no user/owner access to the setting (u*b), now it is safely locked. Table blacklist replaced with structure and no records from another server's phpMyAdmin Export taken in by phpMyAdmin Import. Table category field linkto became harmless, all values are null, other fields align correctly with grid. Crucial data fields, records, intact. Minor post-surgical deployment of Star Trek magic medical salt shaker, sub-Avogadro anti-Heisenburg .zip model. Maintenance mode. Host transplant planned. More tomorrow.