"Duplicate key name query" when upgrading Ubercart modules

Also:

To save the hassle of going through a complete website database restore, I've also tried simply removing the Ubercart 6.x-2.11 file folder and restoring 6.x-2.6 and running update.php. This only results in more errors, and a still-broken store.

Here are the errors viewed when attempting to revert back to 6.x-2.6 without a DB restore:

• user warning: Incorrect table definition; there can be only one auto column and it must be defined as a key query: ALTER TABLE uc_payment_receipts DROP PRIMARY KEY in /home/chase/public_html/includes/database.mysql-common.inc on line 395.
• user warning: Multiple primary key defined query: ALTER TABLE uc_payment_receipts CHANGE `receipt_id` `receipt_id` INT unsigned NOT NULL auto_increment, ADD PRIMARY KEY (receipt_id) in /home/chase/public_html/includes/database.mysql-common.inc on line 529.
• user warning: Incorrect table definition; there can be only one auto column and it must be defined as a key query: ALTER TABLE uc_orders DROP PRIMARY KEY in /home/chase/public_html/includes/database.mysql-common.inc on line 395.
• user warning: Multiple primary key defined query: ALTER TABLE uc_orders CHANGE `order_id` `order_id` INT unsigned NOT NULL auto_increment, ADD PRIMARY KEY (order_id) in /home/chase/public_html/includes/database.mysql-common.inc on line 529.
• user warning: Duplicate column name 'product_count' query: ALTER TABLE uc_orders ADD `product_count` INT unsigned NOT NULL DEFAULT 0 in /home/chase/public_html/includes/database.mysql-common.inc on line 307.
• user warning: Duplicate column name 'currency' query: ALTER TABLE uc_orders ADD `currency` CHAR(3) NOT NULL DEFAULT '' in /home/chase/public_html/includes/database.mysql-common.inc on line 307.
• user warning: Duplicate key name 'qty' query: ALTER TABLE uc_order_products ADD INDEX qty (qty) in /home/chase/public_html/includes/database.mysql-common.inc on line 443.
• user warning: Duplicate key name 'nid' query: ALTER TABLE uc_order_products ADD INDEX nid (nid) in /home/chase/public_html/includes/database.mysql-common.inc on line 443.

This necessitates a full restore to get operational again. Unsure how to proceed with upgrading Ubercart at this point.

Could be they're artifacts from the last time I tried upgrading and had to revert back after the store quit working.

I'll try removing these from their respective tables and upgrading again.

Thanks for the reply, longwave. I'll see if this fixes it.

Well, tried removing these columns and updating again, but this time Ubercart simply didn't create the new columns. Don't know why. Ended up restoring the old databases pre-column removal to make sure everything was still there.

Root issue is the store being broken; customers can purchase items, but don't receive downloads. After fiddling around some more with Ubercart 6.x-2.11 and being unsuccessful at getting it to grant file downloads to buyers of products, I reverted the system back to Ubercart 6.x-2.6. Voila, no problems anymore; now when someone purchases a product, he gets his file downloads again.

Not sure if this is an Ubercart-wide problem that file downloads are simply broken, or if there's something specific here; but for whatever reason, file downloads with purchases work fine for me with 6.x-2.6, but anything higher than that and the store doesn't work.

Any thoughts on this one? My gut now is it's better to simply ignore the "Security Update!" warning; a slightly-insecure store is better than one that doesn't work at all.

Can't say I particularly appreciate the condescension on this message, but let's look past that and get to the meat of the response here...

No, it's not an Ubercart problem, it's a problem with your site. You need to perform the upgrade properly then inspect all your file downloads settings (especially the order status that you've chosen as the trigger to grant the download permission) then it should work again.

This is a useful comment, thanks. I'm a business owner first, Drupal maintainer / manager second, and some of this stuff I simply haven't learned yet. I'll try another update and see if I'm able to find a trigger that's getting broken with the update to fix.

Your store was probably OK at the time of your first post, since those "errors" are just warnings telling you the columns already exist. Since the whole purpose of that update function was to create the columns, and since the columns did exist, the database ended up in the correct state. Of course you messed that up by what you did in #1 ...

Actually, I tried disregarding the warnings and processed transactions regardless, the first time around and every time around. Payment is completed; granting of files to buyers is not. When you're doing a fair amount of business and don't want to be manually granting file access to everybody who buys anything, this isn't a condition you want to have sitting around for too long on a live site while you scratch your head and stare at the screen. Only real option was going back to a version that worked.

Well, 2.6 is 18 months old already - Drupal updates always go easier when you do them incrementally instead of waiting a long time then trying to jump five versions. Putting it off isn't going to make it easier in the future - just the opposite.

I upgraded from 2.6 to 2.8 when it came out, and followed the upgrade process to the letter. I didn't realize there was a problem until days later when I checked my inbox and found heaps of complaints forwarded from customer service personnel about customers not receiving their purchases; the customer service people were having to manually grant everyone their file permissions. That's when this problem originally surfaced, and when I found myself having to go back to 2.6.

I hoped it was some kind of glitch in the program that'd be fixed in a subsequent upgrade. Apparently it's something with the site; I just don't know what it is or where it came from, and I'm not enough of a Drupal pro to figure it out.

And in another year it's likely that Drupal 6 will be obsolete, so I would even consider working on moving your site to Drupal 7 right now. But first you have to be up-to-date with Drupal core and with all your installed modules.

Tried that a couple of months ago. Very frustrating, but eventually got most of the site running. A few modules froze up though and caused the site to crash. After a couple of weeks spent working on the upgrade, I had to admit defeat, and shut down the dev site; upgrade failed. I've contented myself to stick with Drupal 6 for now. I have other D7 sites running... but the difficulty moving a site of this level of complexity over I simply couldn't get past. And trust me, I spent a LOT of time scouring Drupal message boards looking for solutions to the (innumerable) problems I was having. Even straightened most of them out. But a site that's 95% working when your traffic is broaching a million visitors a month isn't good enough.

Anyway, that's a mere 6 years of part-time Drupal hacking experience talking. At this point, I figure I'll just wait until the business needs another upgrade, and then I'll just hire a team of guys who've been doing Drupal for 6 years FULL time instead, since obviously I've reached the limit of my own capabilities.