We have a feature named "Height or Width" representing the longest dimension of a Product in inches, which should be a numerical data type since we want it to be sortable as such. It is defined as numerical in CS-Cart. Unfortunately, I just discovered that the formula we have been using to generate product import CSV files defines it as text data type. This mistake has been present from early on when we decided to change the data type of this feature from text to number. BTW, the original "Height or Width" feature (which was defined as simple text) is still present but was deactivated when we added a new Height or Width feature defined as number.
For example, here is a typical "Features" field value from a Products import CSV:
SKU: T[104B]; Brand: T[Byers' Choice, Ltd.]; Medium: T[Mixed]; Height or Width: T[10]
Since we want "Height or Width" to be a number this should be:
SKU: T[104B]; Brand: T[Byers' Choice, Ltd.]; Medium: T[Mixed]; Height or Width: O[10]
There is an inconsistency between the way the feature was defined in Cs-Cart (number) and he way it has been defined in the CSV file used to import values (simple text). Despite the inconsistency, we do not get an error when importing but we want to know what the data implications are: Is text data in CSV being converted to numerical in mySQL, or is a mySQL number field storing text? We also want to fix it and are wondering if the following plan will be effective:
1) Optimize or repair database after confirming number data type of active feature "Height or Width" and deleting inactive text data type feature of same name.
2) Export Product Id, Language and Features fields as a CSV file features.csv
3) Replace text string "Height or Width: T" with "Height or Width: O" in features.csv
4) Import the modified features.csv file back in to Cs-Cart, which should update features only.
5) Optimize or repair database
Any comments or suggestions appreciated, especially as to what's going on here with mySQL. Thanks!