Jump to content


MFB's Content

There have been 7 items by MFB (Search limited from 18-May 23)


By content type

See this member's

Sort by                Order  

#1878 MOM 6 status...?

Posted by MFB on 25 August 2007 - 02:31 PM in General Mail Order Manager Discussion

Getting more and more stable every day. We've been using it since early July. I'd recommend it in 2-3 months minimum.

There are still many bugs to be worked out, and for software this expensive, should have been much better than this. We managed to lose a decent amount of money due to duplicate shipments because of the a bug in the system that has still yet to be worked out in the system.

Customer Support (as usual) is terrible.

We have a whole set of reports we run with MOM data and the MOM software upgraded to Foxpro9. This caused a problem because Microsoft doesn't support ODBC for FoxPro9. We switched to the OLE database driver, which involved partial rewrites of many query statements, etc. You can check out the info here

It'd be nice to hear the opinions and horror stories of others.

My advice: If you have no real need to upgrade to MOM 6, don't, at least not yet.

:)



#1873 MOM + Linux + Wine?

Posted by MFB on 20 August 2007 - 01:32 PM in General Mail Order Manager Discussion

Unfortunately no success after trying the Mono implementation.

If for some reason I get it working, I'll post the steps here.



#1872 MOM + Linux + Wine?

Posted by MFB on 20 August 2007 - 11:47 AM in General Mail Order Manager Discussion

MOM uses the .NET framework which doesn't run under WINE/Linux. Tried installing under Ubuntu 7.04 with wine.

I am going to try a mono implementation, and will post here about the results or anything that changes.



#1847 [Microsoft][ODBC Visual FoxPro Driver]Not a table.

Posted by MFB on 10 July 2007 - 10:10 AM in MOM & FOX Database Issues

It does appear that the DBC file is the container for all of the tables, but the data still remains in the DBF files.

It works out that the DBC file is a giant data dictionary of all of the tables within MOM, something that Dydacomp was reluctant to release before.

But I am still looking for a way to query the DBC to get the information out of the DBF files, since I cannot access them directly (I get the response that is posted in the first post of this thread).

Would be great if someone shed some light on how we might be able to query the MOMDATA.dbc file so we can access the rest of our data.



#1846 [Microsoft][ODBC Visual FoxPro Driver]Not a table.

Posted by MFB on 09 July 2007 - 05:57 AM in MOM & FOX Database Issues

Unfortunately this doesn't seem to do the trick. Will do some more investigating.



#1845 [Microsoft][ODBC Visual FoxPro Driver]Not a table.

Posted by MFB on 06 July 2007 - 10:53 AM in MOM & FOX Database Issues

Will try. Hopefully this will work :)



#1843 [Microsoft][ODBC Visual FoxPro Driver]Not a table.

Posted by MFB on 06 July 2007 - 07:58 AM in MOM & FOX Database Issues

I'm responsible for developing new MOM ASP applications and maintaining the existing ones witihin our intranet.

Last night we upgraded to MOM version 6. I came in this morning to find that none of our intranet MOM reports were functioning properly... or at all.

Nothing works. Output was stated as:
Microsoft OLE DB Provider for ODBC Drivers error '80040e37' [Microsoft][ODBC Visual FoxPro Driver]Not a table. ...File Path and Line Number of error...

Based on the information that I had accessible from MOM 5.4 table structure, I took a look at the table structure of MOM version 6 only to find all of the essential fields still there with some more included (obviously, since MOM version 6 has a good number of additional features)

DSN Connection using the live MOM DBF files has always worked well for us in the past, since infomration could be gathered in real time.

I guess my question has two parts.
  • Why doesn't ASP think that the tables that I am querying (the ones that worked yesterday) are tables? Did Dydacomp do something differently besides update them?
  • It also gives an error code of '80040e37', as stated above. Can someone explain to the best of their knowledge what it means?
Thanks for your guidance.