Re: EasyPopulate 4.0 Support Thread
Yeah, "back then", the code simply assigned a "quoted" version of whatever the result for $v_tax_class_id was. In this case, a value of zero, false, or null would result in a pair of empty single quotes. Also "back then", databases would convert this to either an empty value if the field supported it or as should have been the case to convert it to the number type associated to the field. The products_tax_class_id is an integer, so again "back then" it would change that "empty" to a zero and store the zero. Now though (because of whatever background change that occurred at some point) the system reports an error rather than do the conversion.
So, if were #@!! bent on continuing to use that version, search for:
Code:
products_tax_class_id = '".$v_tax_class_id."',
And replace with:
Code:
products_tax_class_id = '".(int)$v_tax_class_id."',
In two places.
But... there are a lot of other fields that were populated that way and would cause a problem too and need either similar updates or better yet, upgrade of the software which doesn't suffer that issue.
Re: EasyPopulate 4.0 Support Thread
Quote:
Originally Posted by
jkenwell
Do you recommend I update to 4.0.36.ZC at this point and see if that solves the issue?
Yup. I sure do. Use of the most up-to-date software compatible with one's operating system is always advised. (sometimes even changing operating systems to ensure the most up-to-date.)
Should be as simple as uploading the files then clicking the update link in the upper right hand corner of the tools->EasyPopulate v4 screen.
Re: EasyPopulate 4.0 Support Thread
Quote:
Originally Posted by
mc12345678
Incorrectly understood. 4.0.36.ZC does not have this issue. I'll have to go look at what 4.0.30 was doing, but changes have been made to ensure that the proper datatype would be applied. Things that may have changed and *possibly* brought this to light in that version would be php version on the site has changed, the mysql database version may have changed, or possibly some configuration on the server. The code though has continued to be updated to prevent such issues and to maintain compatibility with its existing breadth of ZC versions.
I have installed the latest version and it appears that the error has disappeared. Perhaps a change was made on server side that created the error. Thank you very much for your contributions and your help with this issue.
Re: EasyPopulate 4.0 Support Thread
Quote:
Originally Posted by
jkenwell
I have installed the latest version and it appears that the error has disappeared. Perhaps a change was made on server side that created the error. Thank you very much for your contributions and your help with this issue.
Glad that solved the problem for you.
Re: EasyPopulate 4.0 Support Thread
Quote:
Originally Posted by
mc12345678
Glad that solved the problem for you.
I'm very sorry, now a new problem has arisen that was not a problem before. This is with a custom Numinix field. Can you think of a way to solve this?
MySQLi error 1366: Incorrect string value: '\x96 1.99' for column 'loblaws_special' at row 1
When executing:
UPDATE zenvv_products SET
loblaws_special = '31/01/2018 – 1.99'
Re: EasyPopulate 4.0 Support Thread
Quote:
Originally Posted by
jkenwell
I'm very sorry, now a new problem has arisen that was not a problem before. This is with a custom Numinix field. Can you think of a way to solve this?
MySQLi error 1366: Incorrect string value: '\x96 1.99' for column 'loblaws_special' at row 1
When executing:
UPDATE zenvv_products SET
loblaws_special = '31/01/2018 – 1.99'
Does this occur on export followed by immediate import of the same file, or only after saving the file from the spreadsheet editor?
The cause of this appears to be that the file was stored using latin1, while your store is using or capable of using utf8.
Re: EasyPopulate 4.0 Support Thread
Quote:
Originally Posted by
mc12345678
Does this occur on export followed by immediate import of the same file, or only after saving the file from the spreadsheet editor?
The cause of this appears to be that the file was stored using latin1, while your store is using or capable of using utf8.
No issue with export/import file. I am trying to find out how I can change the Openoffice csv file to utf8, but so far I don't see anything.
Re: EasyPopulate 4.0 Support Thread
Quote:
Originally Posted by
jkenwell
No issue with export/import file. I am trying to find out how I can change the Openoffice csv file to utf8, but so far I don't see anything.
Save as, check the box at the bottom left to edit filter settings, progress forward and then should be shown the current encoding as well as an option to change how it is to be saved.
Re: EasyPopulate 4.0 Support Thread
Quote:
Originally Posted by
mc12345678
Save as, check the box at the bottom left to edit filter settings, progress forward and then should be shown the current encoding as well as an option to change how it is to be saved.
It appears all issues are now resolved. I wouldn't likely have been able to do it without your guidance. Thank you again. Also, if you are the developer of EasyPopulate 4.0 is there a way to "donate"? These mods certainly save a lot of time.
Re: EasyPopulate 4.0 Support Thread
Quote:
Originally Posted by
jkenwell
It appears all issues are now resolved. I wouldn't likely have been able to do it without your guidance. Thank you again. Also, if you are the developer of EasyPopulate 4.0 is there a way to "donate"? These mods certainly save a lot of time.
I am not the original developer of EasyPopulate 4.0, but picked up the reigns from chadderuski at a time when he was no longer able to support at the level he used to and to incorporate changes that would allow this plugin to continue to function. He developed EP4 based off of older code and concepts where such concepts remain relatively central to any variation. I have made/published my share of mistakes (and continue to occasionally do so) but have been taking the input and requests of users to try to further build out the plugin.
I do not know how many other ways it is used or has been modified, but do know that another user has been able to incorporate functionality to support the bookx product type which comes with its own operational requirements. There are also other variations of this module either with a similar name or some other, but they all tend to have a common goal of updating many records of the database in a single operation.
That said, developers and those offering their support tend to have information either in their signature or profile through which one may find a way to offer back something in return for their work and effort. (ie. To buy a cup of coffee.) As an open source forum and program I would like to think that offering support back to Zen Cart and it's primary developers would be considered acceptable as well. I can not speak for everyone on that. I would think though that showing support in any way would be appreciated, whether it is through finance, assistance, or any other legal action/exchange.
