Quote Originally Posted by wheat View Post
Prior to this version of ZenCart, I used the "paid" version of Easy Pop which allowed assign the Product ID

Why no longer matters as I am accepting this is not posible in EP 4.

However, my Zen Cart currnently thinks I have the maximum number of product ID (214........)

I know this number cannot be changed.

And I have found that because of this, using the current Zen Cart and Easy Pop 4, I cannot add new product, etiher via EP4 or "manually"

I am concernter that if I just go into the SQL DB and reset the number, it will start using numbers already assigned to existing products and it will be an even bigger mess (if that is possible)

We do have other add on in use, but I know from past experience (and the error log) that they are not the problem.

Any suggestions.

Thank you for your consideration

Wheat
Essentially it sounds like you need to "clean" your database, which is a function available under the tools->Store Manager section of the admin panel.

Yes, your concern is valid about randomly assigning the product Id. As for using EP to assign the product_id, it is possible, but which is easier to "remember" when working on the data, item #2 or RosyRedFlowers? Also, as a programmer, basically by forcing the data table to accept this new product #52, can cause that table to obtain errors (something like, though not necessarily because of, the problems you are experiencing. ) It does take a little more planning by the store operator to make it work, but the resulting functionality is tremendous. And actually, EP might be able to fix your issue.

If you were to download all of the table data from your store, you could copy your store program code to another location, from there copy the existing database, wipe out the data within the applicable product tables, then upload (through EP) all of the product data again. If all data and associated referenc information is properly reset, the this would resolve your problem also, but seriously, back up back up, BACKUP and a number of other concerns to possibly do things this way. I still think the database compression/cleanup described above would be the best bet, if not at least a great start.