looking for suggestions for making massive database changes

[delia]

They specifically were expanding the product image field for one - in an effort to import a feed which was disastrous. I don't know what other fields were changed. Nothing should be using the larger size fields so I'm not worried about truncating data.

I started doing exactly what you suggested. Part of the way thru, I just didn't like doing that way since I definitely have not found the issue I know exists and that's the important part. Thus the question I posted - what way is the best?

[mc12345678]

Well, seems like it would help to identify what it is you are wanting to solve/resolve. This issue that hasn't been found, what is it or what seems to be amiss? The failed import, if you have a backup and the backup is shown to work without this unknown issue, then should be able to compare the two and identify what difference has been introduced. Otherwise still should look at the software side to ensure that hasn't been tampered with to cause the problem...

Best can be subjective and also depends on what is trying to be done or corrected. In the OP it appeared that the concern was in the definition of the tables. If that's not the concern or considered to be what will fix the problem then a different approach would be needed. Otherwise, there could be any number of approaches which some may consider better than others.

[delia]

That's not knowable but arose from this other thread: https://www.zen-cart.com/showthread....comments-field
All I know is that I proved the issue is caused by the database and not the template.

[gilby]

That's not knowable but arose from this other thread: https://www.zen-cart.com/showthread....comments-field
All I know is that I proved the issue is caused by the database and not the template.

I can't see how "fixing" this database will have any effect on the problems in your other thread.
I suspect you are heading down the wrong rabbit hole.
Hope others can offer better suggestions. ....

[mc12345678]

So here's thing. Unless the page is literally prepopulsted with the undesirable content as the text is going to the browser, the only database related information would likely be something that is also otherwise modifying the pre-existing html.

Using a browser/system that is not suffering with this auto-fill capability, I would take a snapshot of the html for both database versions. I would also consider the possibility that there is something in the headers being sent.

Otherwise your browser doesn't know squat about the database or even really the php code that is on the server.

If not mistaken, the same filesets (meaning no additional template overrides) have been used with two database "versions" (the fresh for one and the upgraded for the other).

Now unfortunately, even once the page's html is compared between the two, it wouldn't surprise me to think that even more of the database should be reviewed to potentially account for whatever flaws were abused on that older environment.

[delia]

and so I still have no good answers to the question.

So what would you do?
1) edit fields one by one
2) merge with a recent default database
3) set up new database and only transfer over pertinent tables

[chadlly2003]

Just some more insight on your issue.

As far as editing products you could use easy populate and export the information and edit it from an excel file. (its a very simple process)

As far as the database goes, I would download a new zencart and install it on your local machine and compare it to the old database. As was mentioned already.