Admin\Configuration\any sub-category --> missing page data

[DrByte]

Hmmm. The only way I can recreate the symptoms you described is to wipe out the contents of my configuration_groups table.

The configuration_group_id records from the configuration_groups table are in a one-to-many relationship with the configuration_group_id records in the configuration table. If those records get out of sync (which would be extremely odd in normal operation) then the same symptoms would occur.

You said this is a test site which is a copy of the live site, right? I'm frankly very disinterested in fixing problems on test sites because test servers are very seldom configured the same as properly functioning live servers, especially if they're on a small home/office PC. However, if your live site is working fine, and your test site is not, and maybe your database records didn't import properly, then perhaps doing a fresh backup of your live site and re-importing it to your test server (after first deleting all the tables on the test server) ... may be a help.

[jazznuts699]

Hmmm. The only way I can recreate the symptoms you described is to wipe out the contents of my configuration_groups table.

The configuration_group_id records from the configuration_groups table are in a one-to-many relationship with the configuration_group_id records in the configuration table. If those records get out of sync (which would be extremely odd in normal operation) then the same symptoms would occur.

You said this is a test site which is a copy of the live site, right? I'm frankly very disinterested in fixing problems on test sites because test servers are very seldom configured the same as properly functioning live servers, especially if they're on a small home/office PC. However, if your live site is working fine, and your test site is not, and maybe your database records didn't import properly, then perhaps doing a fresh backup of your live site and re-importing it to your test server (after first deleting all the tables on the test server) ... may be a help.

this is a test site in prep to go live. once i have everything configured properly i will copy everything to live. as we stand now zencart is only installed on the test box thus i have no live db to go back to.

if i delete the configuration tables (configuration and configuration_group) would i be able to just recreate those two tables using sql scripts from the install folder zc_install (which has been removed as per install instructions)

[DrByte]

When did this problem first show up?

[jazznuts699]

When did this problem first show up?

i had this problem from the get go -- but not being familiar with zencart when i first installed it i thought it was normal.

i just whacked the entire db and reinstalled under a new db. install runs great except that due to my version of mysql i have to replace every instance of TYPE=MyISAM with ENGINE=MyISAM in mysql_zencart.sql else the sql install fails.

I also did this in the below files just in case:

mysql_upgrade_zencart_127_to_130.sql
mysql_upgrade_zencart_124_to_125.sql
mysql_upgrade_zencart_121_to_122.sql
mysql_upgrade_zencart_114_to_120.sql
mysql_upgrade_zencart_104_to_111.sql

none of the other upgrade sql files had any references to TYPE=MyISAM

long story short -- the problem i reported is recreated with a fresh install making me believe this is a bug.

[DrByte]

... making me believe this is a bug.

Fair enough.
Yours is the first I've seen of someone reporting the problem you mention, so *if* there is a bug, then it's unique to the combination of software on your test computer.

Zen Cart v1.3.8 was never tested for compatibility with MySQL 6, and as such may encounter some problems with it. So that may be the wildcard for you.

And, since MySQL 6.0.3 is presently experimental alpha code as far as MySQL is concerned, perhaps using an officially released version might give you better mileage.

Try using MySQL 5.something.


And, you don't need to edit those mysql_upgrade_*.sql files if you're not actually doing upgrades.

[jazznuts699]

crap.... i was hoping this would be something else. i'm not trying to be 'fresh' about a bug or not a bug. We actually have one live website on this box which runs on mysql thus if i downgrade to 5.1 i may break something -- you know any sites that discuss how to downgrade (mysql documentation mentioned downgrading from 5.1 to 5.0 not 6.0.3 to 5.1). Our live box where zencart will go ultimately run is on mysql 5.0.37 but as mentioned before this box is on mysql v6.0.3.

[DrByte]

Is there any reason why you can't set things up on your 5.0 server to use as your staging area? Then when it's ready to go, move it to the desired working live folder?

[DrByte]

I don't have a MySQL 6 environment available to do any testing at this point, so can't offer much assistance in that area, at least not right now.

[jazznuts699]

Is there any reason why you can't set things up on your 5.0 server to use as your staging area? Then when it's ready to go, move it to the desired working live folder?

it's not as much a problem as a hastle due to bandwidth -- this is because the box i wanted to stage everything at is in the US, while my live box is in EUROPE. And i am currently in the US. Thus having the ability to setup a box here then just copy over tables/files would be the best scenario :). When i RDP into the box in Europe everything is in slow motion .

i think my best bet would be to downgrade to mysql 5.2 and go from there. i'll perform a full backup of the box and see where that takes me. thanks for your help.

[DrByte]

Ya, the slo-mo challenge can be a bit of a pain.