Pingfah:
Hi, I am having a little problem with EP4.
I have ZC1.5.6c, installed from that version, not upgraded. I also have Ultimate URLs and Dynamic Filter installed.
EP4 is installed, and I have imported a bunch of products, no problem, all worked great. It is when I have come to add some attributes that the problem has occurred. I have created a one line/product file for ease of testing, I upload & import the file and I get the following 2 error messages at the top of the page:
**1. File Import Completed with issues.
- An SQL error has occured. Please check your input data for tabs within fields and delete these. If this error continues, please forward your error log to the Easy Populate maintainer
**
Then at the bottom of the page the error is listed thusly:
SKIPPED! - Primary key: v_products_model:bcard - Not Found! Unable to apply attributes.
The product does exist, it has a master category assigned correctly, and I have opened the file in Notepad++ and checked for any tabs, and also made sure the file is converted to UTF8.
Here is the contents of the file (which is named "attrib-basic-ep-test.csv"):
v_products_model,v_products_options_type,v_products_options_name_1,v_products_options_values_name_1
bcard,1,First Name,TEXT
>
>
> Can anybody shed any light on this?
> **amiablesoul:**
>
> Just a guess here, maybe v_products_model should be v_products_id?
Really, really sorry for not responding sooner. I have no reason, only excuses.
While there is a lot of good information in the above post and as a result I would like to say that the issue is fully on the code, I have come to realize that there are a few things possibly missing and as a result I am asking questions to try to gain information not to doubt anything provided.
So the below are in no particular order but each could be either the single cause or in combination with other things.
As pointed out by amiablesoul, there is an option in the software to change the primary_key from the default products_model to products_id. It is also possible that the error message is incomplete and inaccurate identifying the desire to use the products_model instead of properly identifying that the products_id is the item to be found. This issue is corrected in an upcoming release.
The statement about "converting to UTF8" does not identify in what program the conversion was made. If Excel was used to specifically save the csv data as utf8, then it is a "known" issue that it adds a BOM character to the beginning of the file and that actually will cause the field to not be readable. Please, for those that wish to blame this software, there simply are too many ways that data can be incorrectly provided to be able to then evaluate all of the possibilities (and still not identify how the data was incorrectly formatted) instead of following recommended processes or just keeping it simple. In fact I have yet to find a way to discover by review of the import file whether the csv file was generated by Excel or other programs such as Open Office or similar consistently. Yes, there are occasions where a character may be found that signifies the data coming from Excel, but even those are addressed in this code by converting such characters to standard utf8 equivalent.
As part of the processing of the data, a message was generated indicating that there was a problem with the sql statement. This program generates a debug log of its own in the associated import/export file. The contents of that file may be helpful in determining the cause/issue.
Another thing which is suggested in the start of the instructions is to basically initially work with unedited data. This will help step through the process that works in your environment to consistently get the desired results. So. Suggestion would be to export some amount of data, open it with your preferred editor, save it with a new filename and no changes and then attempt import (after upload) of that data. Then review the results. If there are issues, then would suggest simply reimporting the original file to validate operation.
So, what appears correct? I see that the filename matches the expected format to support processing the attributes correctly. I "see" the proper columns and what appears to be correct dividers between data; however, the issue may be with other data inserted by the conversion that is not visible but instead is electronic data not displayed as visible characters. I do see that text is not bounded by quotes, though this is not required it can have an effect *if* that internal text had special characters in it as well... (meaning in this case it does not appear to be an issue)
There doesn't appear to be any spaces in any of the headings nor field data, but that would require review specifically of the file itself.
So... while there may be some initial "setup" of concern, perhaps can see that there are a lot of ways things can go wrong, but reproducibility of it going right is actually easy.
