DB structure difference (customers, customers_info) between 1.3.0.1 & 1.3.8a?

[bodyjewelrystores]

Hi all,

Our live site is currently v1.3.0.1. I have started working with a separate test installation of v1.3.8a, and (after successfully importing the products and categories), I am now trying to import the customers information tables.

This is what I've done, in order:

• Carefully checked the differences in table structure (in `customers` and `customers_info`) between v1.3.0.1 and v1.3.8.
• Exported the `customers` and `customers_info` tables from the live site, and imported into the 1.3.8a test site.
• Altered the imported tables to match the structure and fields of a fresh 1.3.8a database (added the two new paypal fields to `customers` table, with the exact same parameters).

Now I am experiencing two problems - one big, one small:

1. The big one: Customer info shows up in the Admin -> Customers list, but when I click "Edit" on any customer, all the fields are blank, and these warnings appear:
   Warning: reset(): Passed variable is not an array or object in d:\zencart\local\test138a\admin\includes\classes\object_info.php on line 29
   Warning: Variable passed to each() is not an array or object in d:\zencart\local\test138a\admin\includes\classes\object_info.php on line 30
   .
2. The small one: Certain non-English characters in customers' names come up garbled in the imported table.
   For example, "é" becomes "é", and "ñ" becomes "ñ"...
   Even though I've verified that the import is made with the correct collation (latin1).

You will probably tell me "you're doing it wrong - you must upgrade version by version according to the FAQ". Well, there are two reasons why I am not going through the normal upgrade process -

1. On our old site, I was stupid/inexperienced enough to completely disregard the overrides system, and there are literally hundreds of custom changes scattered through the core files. A fresh install, modded in an organized manner, seems to be the only manageable solution.
2. Even if I were to use the normal upgrade process, I'd still have a lot of work to do on the test server before the new site is ready to go live. By the time it's ready, the old live site will have a lot of new customers who weren't there at the time of the upgrade; so I will need to export/import their info to the new site anyway - same thing I'm trying now - in order to have the most up-to-date data.

This is why I'm pretty much forced to export/import directly between the old and new versions, rather than upgrading.
Of course, if you have suggestions on circumventing these problems, they would be very much appreciated, but please take these things into account.

Anyway, how do I ensure that 1.3.8a will not experience problems with customer info imported from the older version?

Is there a way to patch only these 2 tables manually, to conform to v1.3.8a standards?

Thank you very much in advance.

[kobra]

Anyway, how do I ensure that 1.3.8a will not experience problems with customer info imported from the older version?

Is there a way to patch only these 2 tables manually, to conform to v1.3.8a standards?

Get your files in the new install squared away - -
now you have a current file set
Make a backup of the live site DB and import it(might not include the configuration table)
Run zc_install and select "DB Upgrade Only"
For that many versions back you might select the check box to upgrade DB one step at a time - - It runs fast but you will repeat the upgrade about 6-7 times

This way you do not have to fuss with table structures etc let the upgrade script do it

[bodyjewelrystores]

kobra,

OK - I did as you suggested, seems to have worked. Thanks!!
At least the big problem has been solved - I am not getting errors when trying to edit customers info. :)

However, 2 questions... :

1. The problem with non-English characters in customers info becoming gibberish... still happens. Do you know of a way to solve this?
I've made sure to select the correct collation when importing the db that I extracted from the live site; not sure what is causing this.
Perhaps this is due to how phpMyAdmin handles things...?

2. As I said above, before the new version goes live, I will have to do this again, for new customers that are going to sign up in the meantime (while I continue setting up 1.3.8a).
Seeing that I will have a fully-functional 138a database by then, I wouldn't want to re-import the entire db from the live site, just to update customers and orders.
What would you suggest to do? Would the incremental upgrade process (version by version) still work, if only a few of the tables are "old"?

Thanks again!!

[kobra]

Not sure what language is your default??

But even with another language you need an english.php edited for the other language as other_lang.php and in it find this

// look in your $PATH_LOCALE/locale directory for available locales..
// on RedHat try 'en_US'
// on FreeBSD try 'en_US.ISO_8859-1'
// on Windows try 'en', or 'English'
  @setlocale(LC_TIME, 'en_US.ISO_8859-1');
  define('DATE_FORMAT_SHORT', '%m/%d/%Y');  // this is used for strftime()
  define('DATE_FORMAT_LONG', '%A %d %B, %Y'); // this is used for strftime()
  define('DATE_FORMAT', 'm/d/Y'); // this is used for date()
  define('DATE_TIME_FORMAT', DATE_FORMAT_SHORT . ' %H:%M:%S');

Edit for the Hebrew language

@setlocale(LC_ALL, 'he_IL', 'he', 'hebrew');
define('DATE_FORMAT_SHORT', '%d/%m/%Y');  // this is used for strftime()
define('DATE_FORMAT_LONG', '%A %d %B, %Y'); // this is used for strftime()
define('DATE_FORMAT', 'd/m/Y'); // this is used for date()
define('DATE_TIME_FORMAT', DATE_FORMAT_SHORT . ' %H:%M:%S');

[bodyjewelrystores]

Well, our store is in English, but this problem seems to be unrelated to the browser encoding, or to any Zen files - even when I check the database contents directly with phpMyAdmin, I see the correct characters in the live db (to which the customers enter their info directly), but gibberish in my new test db (after the export/import).

I'm thinking it might be due to the fact that the MySQL charset and connection collation (on both servers) are utf8 - but the table collations are always latin1 (seems to be the Zen default), and I've always selected "latin1" when importing. So I'll need to experiment with that :)