10 replies to this topic

[MFB]

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.

[CDI Fulfillment]

Dydacomp changed the type of FoxPro databases that they are using. In MOM 5.4 and earlier, the tables were free tables with DBF extensions. MOM 6.0 has changed to (I believe) FoxPro 9, which uses database container files (.DBC). I am a little surprised that you weren't informed about the change when you did the upgrade. Dating back to December 2006, there has been quite a bit of discussion in the Dydacomp MOM forum regarding the change.

It was first brought to light when I questioned the compatibility of R&R with MOM 6. I don't think that Dydacomp realized the havoc they were causing by making the change. I specifically asked if R&R would continue to work and if they had changed any of the field names in the databases and I was assured that it would simply be a matter of pointing the reports to the new locations. WAY WRONG ANSWER!! R&R actually ended up releasing a patch that allowed the program to handle container files.

As for the problem at hand, it may be as easy as going into the ODBC Data Source Administrator and changing the database type from Free Table Directory to Visual FoxPro Database. Hopefully it is.

[MFB]

Will try. Hopefully this will work

[MFB]

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

[MFB]

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.

[Warner]

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.

Try the free download below from Microsoft. I'm not sure if it works because I'm not upgrading from MOM 5.4 to 6.0 until a fix for this problem is confirmed by someone other than Dydacomp.

Microsoft OLE DB Provider for Visual FoxPro 9.0
Brief Description
The Visual FoxPro OLE DB Provider (VfpOleDB.dll) exposes OLE DB interfaces that you can use to access Visual FoxPro databases and tables from other programming languages and applications.

http://www.microsoft...;DisplayLang=en

[bobg]

Try the free download below from Microsoft. I'm not sure if it works because I'm not upgrading from MOM 5.4 to 6.0 until a fix for this problem is confirmed by someone other than Dydacomp.

Microsoft OLE DB Provider for Visual FoxPro 9.0
Brief Description
The Visual FoxPro OLE DB Provider (VfpOleDB.dll) exposes OLE DB interfaces that you can use to access Visual FoxPro databases and tables from other programming languages and applications.

http://www.microsoft...;DisplayLang=en

SIGH ... well, that one didn't work either. I did, however, notice some interesting things while trying various combinations of attempts to link tables to an access database...

When linking through a file DSN, whether it's free table database or vfp .dbc, I get the "reserved error -7778 .... no information is provided" error.

When I link through a system DSN, if I use the "free table database" option, all the .dbf files in momwin that have an associated .cdx file are hidden and I can't access them. The ones that DON'T have an associated .cdx file, however, are available for access. I didn't try to access them, cause they're not the ones I need (woudn'tcha know ...)

When I link through a system DSN and use the vfp .DBC option, I get the "not a table" error. Perhaps this might help someone help me find a solution. I have a client who runs daily reports from ACCESS and hasn't been able to do so for a week now, since upgrading to MOM6.

[bobg]

GOOD NEWS!!!

There is a way to get at the .dbf files w/o trying to use the .dbc (which doesn't work anyway).

There is a program called dbfconverter by HiBase software ... it's 30bucks for the licensed version and it will take the vfp9 dbf's and convert them to a standard .vfp format, so that you can set up your system dsn for ODBC access through crystal reports.

The program has command line functionality, so that you can automate the export/conversion on startup of MSAccess.

BAD NEWS ...
Dydacomp changed the names of some of the fields in the tables ... ex: csm.dbf version 5.4 had the field "order". in 6.0 it's "orderno".

this means that even after you access the files, you'll need to do some debugging of your reporting setup.

HTH

[dseibold]

sounds like getting real time updates will be impossible...
Everytime you want to update the current day's info, you'll have to reimport the tables...
I think I'll wait a little longer on upgrading.

[jeffld]

This issue also interests me as I have the same exact problem.

One workaround that I have is to make a copy of the DBF files, then change the first byte of each DBF using the WINHEX HEX editor from a HEX 31 to a HEX 30 and then I'm able to open the DBF files.

I'm looking for a better solution to this problem. If anyone has an C# .NET code to do this, It would be great if you could post it.

thanks

jeffld

[MikeN]

I know this is an old thread, but Microsoft uses this connection string:

"Provider=vfpoledb;Data Source="+HOME(2)+"Northwind\Northwind.dbc"

in an example from the "How to: Access Visual FoxPro Data in Visual Studio" article at http://msdn2.microso...895(VS.80).aspx ...

Has anyone successfully used this? Thanks...

MikeN