looking for suggestions for making massive database changes

**delia** · 1 Jul 2019, 08:11 PM

Some lovely previous person made quite a number of database changes - expanding the size of fields deliberately but also the cart was originally 1.3.8. I'm trying to clean it up and noticing a lot of fields with mediumText where recent versions use text instead. I know there's an unknown issue buried somewhere as well.

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

I hate all of the choices as it's so easy to have something go wrong. What do you think is best?

**mc12345678** · 1 Jul 2019, 09:31 PM

Well, I would think that there must have been reasons to modify the field lengths the way they were and it may have been in part based on what was available at the time.

Two factors come immediately to mind, first is potential database data loss by shortening fields. The second is future data loss by shortening the fields (as data is entered).

I personally would export the database to a readable format. Compare the table structure to a known/original database. (so really just export structure first).

Then with a backup of the database, modify the fields to the desired state. Export the modified database looking at the data only and compare to see what if anything had been lost.

Then knowing what field(s) were in question, evaluate the code differences where those fields are used to see what if anything is affected/those changes are further needed.

The other part of this though is regarding such field length concerns, how do they appear to play into the unknown issue?

I know some others that have had odd issues during an upgrade from way back then that have taken everything except the configuration table from the old version and been able to regain "sane" operation.

**delia** · 1 Jul 2019, 11:03 PM

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** · 1 Jul 2019, 11:46 PM

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** · 2 Jul 2019, 01:57 AM

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** · 2 Jul 2019, 02:06 AM

Originally Posted by 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.

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** · 2 Jul 2019, 05:51 AM

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** · 11 Jul 2019, 10:12 PM

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** · 12 Jul 2019, 04:35 AM

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.