.
Zen Cart - putting the dream of business ownership within reach of anyone!
Donate to: DrByte directly or to the Zen Cart team as a whole
Remember: Any code suggestions you see here are merely suggestions. You assume full responsibility for your use of any such suggestions, including any impact ANY alterations you make to your site may have on your PCI compliance.
Furthermore, any advice you see here about PCI matters is merely an opinion, and should not be relied upon as "official". Official PCI information should be obtained from the PCI Security Council directly or from one of their authorized Assessors.
Aww, I was thinking of adding a "greater than" like function, actually last thought which I liked was a value in this array type function. Though perhaps both would be of benefit.
The lack of "complaint" about that query? Well, I can say I've seen this problem before and there have been others that have reported a similar issue, though none seemed to publicly relate the lack of upgrade with the shipping_method field... if they did, I don't recall it.
ZC Installation/Maintenance Support <- Site
Contribution for contributions welcome...
Just to let you know, I have had another occurence of this issue, again due to the length of a shipping title. Whilst it may not affect everybody using Advanced Shipper as it really depends on what names they have given the methods when setting it up, clearly it is an issue. Whether the zc devs choose to address it directly by modifying the installer or not is up to them, but if no such modification is to be made, then I would suggest some note in the documentation advising people of the possibility of encountering this error.
There is also a problem with the attempt to add additional countries, resulting in a Duplicate entry '247' for key 'PRIMARY' error being logged. The database in question has some additional countries added for Scottish Highlands etc. Given that adding additional countries is not an uncommon occurence, I have to question why the ZC devs have used a strict method of setting the countries_id given that the field is Auto Increment. Surely it would be better to have not assigned the countries_id, instead letting MySQL increment the value as necessary.
Hi
I've attempted upgrading from 1.5.4 to 1.5.6b and am encountering this error again - any recommendations?
Duplicate entry '247' for key 'PRIMARY'
INSERT INTO countries (countries_id, countries_name, countries_iso_code_2, countries_iso_code_3, address_format_id) VALUES (247,'Curaçao','CW','CUW','1');
---------------
Duplicate entry '248' for key 'PRIMARY'
INSERT INTO countries (countries_id, countries_name, countries_iso_code_2, countries_iso_code_3, address_format_id) VALUES (248,'Sint Maarten (Dutch part)','SX','SXM','1');
---------------
When you inspect the store's database using phpMyAdmin from your cPanel, what is currently present for countries_id values 247 and 248?
If you're talking live data (version 1.5.4 prior upgrade) - there is no 247 or 248 - it only goes up to 245.
Otherwise if you mean what's in there after my failed upgrade -
247 | Curaçao | CW | CUW | 1 | 1 |
248 | Sint Maarten (Dutch part) | SX | SXM | 1 | 1
Actually forget the countries thing - I think it is getting caused because I keep trying to force the upgrade.
My real problem (I think) is this -
---------------
May 31 2019 16:23 -- upgradeException
ALTER TABLE orders MODIFY shipping_method VARCHAR(255) NOT NULL DEFAULT ''; 1292: Incorrect datetime value: '0000-00-00 00:00:00' for column 'order_delivery_date' at row 5150
Yes, that '0000-00-00' value for a datetime field is going to cause issues. You'll need to take a two-pronged approach, since simply updating the database will correct the database, but I'm guessing that the Order Delivery Date plugin might be looking specifically for the zero-date value.
You can correct the database using the following SQL (either the site's admin's Tools->Install SQL Patches or via phpMyAdmin), recognizing that you'll need to include any DB_PREFIX value if you're using phpMyAdmin:
Be sure to make a database backup first! Then, you can use the DTK to find all occurrences of 0000-00-00 in all files. That will let you know where, if at all, any code is relying on those now-invalid dates.Code:ALTER TABLE orders MODIFY COLUMN order_delivery_date datetime NOT NULL default '0001-01-01 00:00:00';
Bookmarks