RO CSVI
The use and non-use of ID fields
| RO CSVI
The use of ID fields in import files often gives many users problems, whether this is due to not reading the documentation or expecting different behaviour from CSV Improved is not the question I want to answer here. What I do want to hightlight is the problems that might occur using ID fields.
What is an ID field?
An ID field is a field that holds a unique reference number for data in the database. Examples of ID fields are:
- product_id: Holds the ID for a product
- manufacturer_id: Holds the ID for a manufacturer
- category_id: Holds the ID for a category
- etc.
What is the life expectancy of an ID field?
The life expectancy of an ID field can range from days to years. As long as the data does not get deleted from the database the ID stays the same. Regularly deleting and importing new data makes the ID change as often as this process is repeated.
How important is the ID field?
As mentioned earlier, the ID field is unique. This makes it important however not as important as other fields that are more consistent than the ID field. Some examples of more important fields:
- product_sku: The Stock Keeping Unit will almost never change as it identifies a specific product
- manufacturer_name: The name of a manufacturer is also unlikely to change
- category_path: The name of a category is unlikely to change
Even though the ID field is important to the shop, other fields are more important for import.
Which field should I use?
It is advised not to use ID fields for import. CSV Improved will find the correct ID based on the other fields you import. If an ID is ever changed and you don't know about it, the import will go wrong.
Another example is when you are importing new data, the ID field does not exist and nothing will be imported as the database cannot find the ID and your shop will remain empty.
Final words
Be cautious using ID fields in your import file, imports are more likely to succeed not using these fields.
Run an RO CSVI cron job using a URL on the frontend
| RO CSVI
In the document Setting up a cron job we explain how to run import and export jobs using the command line in RO CSVI. This is the preferred way of running cron jobs because this is generally not limited by the limitations imposed by running an import or export through the browser. However in some cases you may need to run a cron job using a URL on the frontend, in this document we explain how to set this up.
Deal with different collations in MySQL
| RO CSVI
One of the common issue which arises after migration of database is dealing with different collations in tables. Database cannot handle the mix of these collations and throw error like
Illegal mix of collations (utf8_general_ci,IMPLICIT) and (utf8mb4_general_ci,COERCIBLE) for operation '='
The cause for this error is because two different fields are been set with two different collation in same table.
To solve this problem
1. Go to PhpMyAdmin, select your database.
2. Look for the table having the issue, in this case it is #__virtuemart_products table.
3. Check the field which is having a different collation than other fields, in this example it is product_gtin. Normally fields use utf8_general_ci as collation or check what is the collation for your other fields in the table.
4. Select the Structure tab to see the complete field structure of the table.
5. Click on the edit icon or Change link for the field, here it is product_gtin. In the collation drop down look for utf8_general_ci and save the field.
Thats all to be done. If you still continue having the error, check for the same issue in other related tables.
Here are the few queries which can be used to convert column name or table or database to required collation.
To convert a column:
ALTER TABLE `your_table` CHANGE `your_column` `your_column` your_field_column_type
CHARSET utf8 COLLATE utf8_general_ci NULL;
your_field_column_type is the data type of the column like VARCHAR(10).
You need to replace this to the type of your column you are changing the collation.
To convert a Table:
ALTER TABLE your_table_name CONVERT TO CHARACTER SET utf8 COLLATE utf8_general_ci;
To convert a Database
ALTER DATABASE your_database_name CHARACTER SET utf8 COLLATE utf8_general_ci
If you have collation looking good on tables and columns and you still have this error, Check if your import file is UTF-8 encoded. You can check that by using CSVI Analyser page. If you see any unreadable characters as in the image then you need to Save your CSV file as UTF8 encoded file before running the import.
More articles on this subject
I want to import articles with images
| RO CSVI
With RO CSVI it is possible to import Joomla articles with images for fields image_intro and image_fulltext.
RO CSVI versions
| RO CSVI
This is a list with all the RO CSVI versions that have come out and which version of Joomla is supported. The list also shows the end-of-life of each major version and if support is available. All available versions can be downloaded from the Download section.
| RO CSVI Version | Joomla! Version | Available | Support | End of Life | Latest Release |
| 1 | 1.5 |  |
|
November 16, 2009 | 1.9.2 |
| 2 | 1.5 | |
|
February 19, 2011 | 2.3.18.1 |
| 3 | 1.5 |  |
|
February 6, 2012 | 3.8.4 |
| 4 | 2.5 | |
|
August 8, 2012 | 4.5.2 |
| 5 | 2.5 / 3.X | |
|
December 2015 | 5.21.2 |
| 6 | 3.X | |
|
December 2017 | 6.6.4 |
| 7 | 3.8+ | |
|
November 24, 2021 | 7.20.0 |
| Joomla! 3.10 as a minimum is required. | |||||
| 8 | 3.10+ / 4.x / 5.x | |
|
September, 2025 | 8.21.0 |
| Joomla! 5 as a minimum is required. | |||||
| 9 | 5.x / 6.x | |
9.3.0 | ||