Three things I can think of.
1) SET FOREIGN_KEY_CHECKS = 0;, then do the update, then SET FOREIGN_KEY_CHECKS = 1; at the end.
2) Move all the FK ALTERs to the bottom of the processing queues
3) Recreate the main table structures given out by the update servers to contain the constraints initially. This one likely something that defeats the purpose of the update server

If number one works I think that would be the preferred method. Otherwise 2 for the win.
BTW I went ahead and removed your FKs from the update server until we thought of a solution so that we aren't making it worse trying to do something quick. Don't feel bad about the update though, you were implementing some major changes and not everything works out like we want it to all the time I would have quit long ago if I let little things like this get to me, so don't let this discourage you

I'm not discouraged, as it has to be done eventually. I just didn't know how the server handled creating a new DB. I now know that it creates a table, then does all that tables updates at once, then moves to the next one.
So what we can do is take a little more time to plan it, when you get time we can try the foreign key checks. I think that'll do it. I do not know what will happen though if you enable FK checks after the fact, and there is bad references... i might need to test that here.

just an FYI I seem to exceeded my limit again. Have the changes been removed from the database yet, because once they are I might try rebuilding the database from scratch again...

LethalEncounter wrote:BTW I went ahead and removed your FKs from the update server until we thought of a solution so that we aren't making it worse trying to do something quick.

Yes, we have reverted the FK changes for now. Sorry for the mess.