Unfortunately, it sounds like your Workflow-ng problem was one fixed in a later version and torgosPizza (who manages the file download sales for http://www.rifftrax.com) just gave us a patch for better code for file downloads that will be in the 1.5 release. Any chance you can update your site?

Is your database server not the same server as the one hosting your Drupal installation? I can't say I've ever seen that error before.. why you'd be losing the connection to the database during that query, which is relatively small, I think.

I don't have any experience with them. I know UC users who do, but not sure if they use File Downloads or not. I might consider running the issue by mt's support guys, tell them what you are doing and what the error is, and perhaps they can narrow down the issue. I don't think it's a PHP limit per se, but probably something to do with MySQL hanging for some reason. Perhaps tables are being locked and staying locked when they shouldn't be - do you have a lot of users connecting at once?

Yeah, seems strange. I would update to the latest bazaar version of the uc_file.module if you can. I don't think that'll have an effect either way on the "lost database connection" error you experienced. There's the chance that this is an issue separate from the downloads failing, but they could be related somehow.

One thing I can mention: if the File Downloads and everything is setup correctly, but the users still are not getting downloads, check your SKU fields. I helped an issue with someone a while back where the same thing was happening - orders were being completed but no Downloads events were getting fired. It turns out the user had spaces in their SKUs, and/or their SKU fields were quite long. You'll need to download the uc_file_retro queue (File Downloads Retro) I wrote, which will allow you to edit your product's SKU, and then edit and "re-commit" the File Download feature.

Sorry if that's a confusing statement. But basically once you edit the SKU field in your product, the file downloads will break, and so you'll need to edit the Features again and re-submit them for the new model.

Also, did this just happen recently? Or did it not work to begin with?

Finally, talk to mt again and tell them that you know the difference between a db and a file server. Ask them to actually check the mysql and apache error logs to see if there is any clue as to why the connection between the two servers would be dropping during a simple UPDATE.

actually i'm wrong. I changed a file name, not the SKU.

for reference, here's my longest SKU:

SNRD002iPhoneCellular

Let me know if this is a problem

The SKU looks fine to me, but I know that when you change filenames you should resubmit the file feature (in the product edit form) to make sure users can download it going forward.

And regarding the FTP issue - you're saying you went into your site's files location, via FTP, and the files stopped even there? That sounds like a more serious issue. How are you connecting? FTP or SFTP? How big are these files we're talking about?

That sounds like another issue you should mention to mt. Perhaps they have limits on how large file transfers can be? I mean, I've never heard of that, but anything is possible, I suppose.

Re: 10 and 11, do you have Cron running every hour?

I'm wondering if mt is running a Cron on your server or something else that you're not aware of? 600 megs is fairly large, but our site has files that are bigger, and we don't have this type of issue.

Did you manage to get ahold of support again? They should really investigate this issue, since on a dedicated server things appear to work without issue, but on the grid they break for some unknown reason. Well, the reason appears to be a dropped connection with the db. To me it sounds like a problem with mt's grid service, at least so far.

Yeah to me, that is pointing to a more serious problem. I'm subscribed to this thread so I'll see any updates you post. Please keep us informed, and if they say that "it's not us, it's Ubercart" then let us know. I doubt that'll be the case, but who knows what they'll say.