Again, this wouldn't make sense. "Doing Mom Daily" wants the Packing Slips to print a certain way for the purpose of Picking. Why would they? Picking is done via Pick Tickets. Packing is just about throwing already-picked items into a box and have nothing to do with Bin Location.

Chris - I can see where you are coming from on this, but some of us don't print picking lists. For instance, I have my fulfillment center set up so that we pick directly from the packing slip. I have created my own custom packing slips, using R&R, that list the bin locations in walking sequence. It sounds like this is what "Doing MOM Daily" is trying to do. If I am understanding it correctly, that can't be accomplished out of MOM. If Dad wants to be set up as I've described, he's going to have to go down the same road I did and create custom packing slips using R&R, Crystal, or some other reporting app.

Josh - Why do you have someone going in and manually updating each line item to show as shipped? That sounds like a lot of work to accomplish something that MOM will do for you. I don't know what you are doing to ship the packages, but if MOM won't automatically update the orders when you do a batch order process, it sounds to me like you might need to change some of your global parameters.

The instruction given in the error message tells you what to do (copy, zap, append), but really isn't very helpful if you don't know what that means.

• Make a backup copy of the corrupt database file
• Open DBUWin for the company with the corrupt database
• Open and browse the corrupt databse
• Click on Table -> Copy To...
• Click OK, then choose the location to save the file (I suggest something like the desktop, not in the MOMWIN folder)
• Click on Table -> Zap (you should get a message that warns you that this will permanently delete everything from the table. If you haven't made your backup yet, this is the point of no return)
• Once the ZAP is complete, browse the table again; it should be completely empty
• Click on Table -> Append From...
• Select the file that you saved on your desktop
• Restoration is complete. Close out of DBUWin and you should now be able to go into MOM
• Note: I have seen where multiple databases will get corrupted and you have to do this multiple times. MOM only tells you about one at a time, so you may have to go through this whole process, try to log in, then find out that an additional database is corrupt and have to go through the whole process again.

Always remember, DBUWin is a very powerful tool and anything that you do within the program CAN NOT be undone. Make a backup. If your still not comfortable working with DBUWin, hire someone that knows what they're doing.

I've been running v12 pretty much since it's release. I don't know that I have noticed any real changes between v11 and v12, but supposedly you get free updates for life, so that's nice. With MOM, the biggest need to upgrade to v12 would be if you are running MOM v6. R&R v12 is supposed to be able to handle the Foxpro database containers that Dydacomp switched MOM to. I am still running MOM v5.4, so no real changes here.

Somehow this thread has gone from a venting of frustrations by David into a MOM bashing. I understand that MOM definitely has shortcomings and quirks, but the fact of the matter is that it is a pretty dang good program for the price that we pay. I definitely don't agree with the manner in which Dydacomp has rolled out v6. It is buggy and no indication was ever given that they were changing from free tables to database containers. I know that I specifically asked about the functionality of R&R with v6 before I purchased it in December '06 and I was assured that there would be no disruption in functionality. They were dead wrong. R&R is a product that Dydacomp promotes, but nobody took the time to test it before they went live.

In the past, I have looked at Stone Edge, Mailware, and Colinear Response. (I consider them to be the closest peers/competition to MOM.) None of those programs were able to meet my needs in different areas, so that's why I'm still using MOM. If you want a better program, you are going to have to pay for it; a lot more. If anyone hates the program that bad, stop using it. Switch to another software package. You'll be happier and we won't have to listen to you complain so much.

I feel like a broken record, but I too purchased MOM v6 in December '06 because I could get this great deal on the upgrade (thinking that upgrading was inevitable anyway). What a disappointment! I spent no less than a month attempting to upgrade, but the conversion never even worked correctly. Then I starting hearing all the horror stories form those that had successfully "upgraded" and I was sure glad that it never worked for me. Here I am, nearly 1 1/2 years later and still running v5.4. At this point I am not sure that I will ever make the change. I have too many R&R reports, ODBC connections, etc. to deal with the endless hours that it would require to get back to the point where I am now. I am happy with v5.4 and I can make it do pretty much anything that I need.

My opinion is that v6 is probably perfect for newcomers to MOM or those that have been running simple configurations of v5.4 or earlier versions. For those of us that have been around for a while, changing from the open database configuration to the database containers really screwed a lot of things up and made it nearly impossible to for a change without a major investment. As long as v6 users continue to experience speed issues, as well as the other quirks that we continually here about, v6 isn't even a consideration for me.

That's not right. You can use a single account number for multiple MOM companies, though as I recall it is not as easy as it should be. I run a fulfillment house and in the past we used the built in UPS link function to create our shipping labels. I have since moved on to processing via other means, but what I do recall is that in each company I would try to commission the station, get some sort of error from MOM, then go through the back door using DBUwin and copy the commissioned status (mailbox ID, etc.) from a commissioned company into the one that failed. Sorry that I can't be more specific, but it has been 3+ years since I have dealt with that scenario.