Bummer... That was kind of a fun time... with everyone plugging away at the code. I'm sure others have taken over where those guys left off...
So here is the latest update. I've been focusing on the issue of it not wanting to run the repair tables function. Through alot of debugging I discovered these specific problems....
When checking the category stats... in the nph-build.cgi routine _reset_category_stats, it compares the actual number of links it finds in the CatLinks table for each category, vs the number in the Category table field "Number_of_Links".
Here is the GT Module call:
and this is what the SQL query should look like:
SELECT COUNT(*)
FROM CatLinks, Products
WHERE CatLinks.LinkID = Products.ID
AND (CategoryID IN (128) AND isValidated = 'Yes')
but this is what we're getting:
SELECT COUNT(*)
FROM CatLinks, Products
WHERE
AND (CategoryID IN (128) AND isValidated = 'Yes')
Any thoughts on what might be causing the GT module to be writing bad querys like that?
Best regards,
AlexJ
So here is the latest update. I've been focusing on the issue of it not wanting to run the repair tables function. Through alot of debugging I discovered these specific problems....
When checking the category stats... in the nph-build.cgi routine _reset_category_stats, it compares the actual number of links it finds in the CatLinks table for each category, vs the number in the Category table field "Number_of_Links".
Here is the GT Module call:
Quote:
my $total = $cat_link->count ( GT::SQL::Condition->new (['CategoryID', 'IN', \$str], ['isValidated', '=', 'Yes']));and this is what the SQL query should look like:
Quote:
SELECT COUNT(*)
FROM CatLinks, Products
WHERE CatLinks.LinkID = Products.ID
AND (CategoryID IN (128) AND isValidated = 'Yes')
but this is what we're getting:
Quote:
SELECT COUNT(*)
FROM CatLinks, Products
WHERE
AND (CategoryID IN (128) AND isValidated = 'Yes')
Any thoughts on what might be causing the GT module to be writing bad querys like that?
Best regards,
AlexJ
