bsmither Posted February 9, 2016 Share Posted February 9, 2016 Ugh! All columns of a FULLTEXT index must have the same character set and also the same collation. And, you have to change the character set for all involved columns AT THE SAME TIME. For that 'name' column, what does phpMyAdmin say about its characteristics? Quote Link to comment Share on other sites More sharing options...
keat Posted February 9, 2016 Author Share Posted February 9, 2016 It's a good job one of us knows what we are talking about, and it's not me. Quote Link to comment Share on other sites More sharing options...
keat Posted February 9, 2016 Author Share Posted February 9, 2016 If i look at name under the columns drop down and compare it to product code and description, it does have an extra box below default. Not sure if this is relevent. Althouigh I checked this agianst 3 or 4 V3 sites and they are all the same Quote Link to comment Share on other sites More sharing options...
bsmither Posted February 9, 2016 Share Posted February 9, 2016 I see for Collation, there is latin1_swedish_???. A CubeCart 6 database structure has for CHARSET=utf8 and for COLLATE=utf8_unicode_ci. Just out of curiosity, please Browse the CubeCart_history table. What is the highest value in the 'version' column? Quote Link to comment Share on other sites More sharing options...
keat Posted February 10, 2016 Author Share Posted February 10, 2016 It says 6.0.10 Also I checked against at least 4 of my V3 sites and the table 'name' are all latin1_swedish. Looking at the V6 database, 3 columns are latin1_swedish_ci. These are: description, name and and prod_sefurl, so I changed all three to utf8_unicode_ci, but it didn't help. At the moment, I'll leave them as uft8 Quote Link to comment Share on other sites More sharing options...
keat Posted February 10, 2016 Author Share Posted February 10, 2016 I've just performed a clean install on a subdomain and compared the two databases. The new one doesn't have half as many tables as the upgraded one. This image shows the upgraded database, note how it appears to have duplicated tables ending utf8 Quote Link to comment Share on other sites More sharing options...
keat Posted February 10, 2016 Author Share Posted February 10, 2016 I've tried every concieable way to fix this myself today and come up against one stumbling block after another. On a new domain, I installed a clean copy of 6.010, then took a snapshot of the empty database. I've tried to copy just the data from the problematic database to clean database, but come up against many errors. I can only seem to copy the structure and data successfully, but then the fault returns. Quote Link to comment Share on other sites More sharing options...
bsmither Posted February 10, 2016 Share Posted February 10, 2016 A database originally created in CC3/4 used the default character set that the database engine configuration was set for - typically some latin1 variant. The standard default is now UTF8 and in the upgrade process, CubeCart sends each table through a process that converts them to UTF8. That process is to first create a UTF8-named table, copy all the records from the source table into it, then drop the source table, finally renaming the UFT8-named table back to the original name. Since these UTF8-named tables are still there, one possibility is that PHP ran out of time to finish the upgrade process right at that step. Another possibility is that the database user that CubeCart uses to access the database does not have DROP privileges. Quote Link to comment Share on other sites More sharing options...
keat Posted February 10, 2016 Author Share Posted February 10, 2016 I suppose I could recreate a copy of the V3 again this evening and try another upgrade. Quote Link to comment Share on other sites More sharing options...
keat Posted February 10, 2016 Author Share Posted February 10, 2016 Mirroring the V3 to a fresh domain and upgrading again, but the issue is still there, The duplicate utf8 tables exists in the database. Right at the very start of the update i get this error [10-Feb-2016 17:11:23 UTC] PHP Notice: `version` is not allowed as a key in 'CubeCart_history' table! in /home/kingp/public_html/classes/db/database.class.php on line 858 I noticed when it popped up, it mentioned V3.18, yet when I look at the downloads, there is no 3.18 don't suppose this has anything to do with it ? Quote Link to comment Share on other sites More sharing options...
keat Posted February 10, 2016 Author Share Posted February 10, 2016 As an experiment, i thought i'd try and upgrade to 5 to see if it worked, then upgrade to 6, but it seem V5 requires a license. Quote Link to comment Share on other sites More sharing options...
bsmither Posted February 10, 2016 Share Posted February 10, 2016 Almost all of the upgrade happens at the CC500beta1 step. There is a bit to move the database from CC3 to CC4, and about a dozen very small steps to move from CC500 to CC6010. So, I say moving to the latest version of the CC5 family gets you no closer to getting over this one particular step than using the latest version of the CC6 family. It could be the History table has not been created when the upgrade process wants to write to it. And, actually, that's perfectly fine. The History table is not a part of CC3. The latest version of the CC5 family doesn't need a license, so I am surprised that it is asking for one. Maybe you don't have the latest CC5 version. Please analyze the users assigned to your CubeCart database and verify what privileges they have against the database. Quote Link to comment Share on other sites More sharing options...
keat Posted February 10, 2016 Author Share Posted February 10, 2016 I gave the user full rights. Quote Link to comment Share on other sites More sharing options...
keat Posted February 10, 2016 Author Share Posted February 10, 2016 I'm really not sure what the fix is, so I'm trying work arounds, it definately appears to be geared around the invettory table. From the admin panel, I exported the catalogue from the faulty V6, then imported this to a brand new V6. I then removed the faulty table and imported the brand new table. Now the search facility works, but it appears that it didn't copy the product_id, so all the images are screwed up. At least it's proven that the fault is with Inventory, but I really need ideas how to fix it. Quote Link to comment Share on other sites More sharing options...
bsmither Posted February 10, 2016 Share Posted February 10, 2016 If, when you say you exported and imported the catalogue, if this was under CubeCart's Export/Import Catalogue feature, that was not the best approach for this. Probably within phpMyAdmin, having the contents of CubeCart_inventory dumped to a CSV, the table reconstructed, then that new table loaded with the same CSV - making sure the table accepts the product_id as given (there should be a setting to force this). Otherwise the product_id may start at some other number during the loading. Quote Link to comment Share on other sites More sharing options...
keat Posted February 10, 2016 Author Share Posted February 10, 2016 This is exactly what I'm trying at the moment, export the funny table to CSV, manipulate it so it looks the same as a good table then try and import it back in,but have an Invalid column count in CSV input on line 17. I cant see anything different to the few before it. Wondering if it might be related to entry 17, I re-organised the CSV but it staill stalls with the same error. Quote Link to comment Share on other sites More sharing options...
keat Posted February 10, 2016 Author Share Posted February 10, 2016 I went over it again, double checking all entries and this time it imported. It looks like it might be working, but I'll know more when I do some testing tomorrow. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.