metadata operation failed (8013110E) : Database file is corrupt and may not be usable.

[Tomas Vera]

Hello All (This is being cross-posted to the C++ group),

I've started receiving the subject message during a compile of a C++
based interface module used in my C# based WebApp. This module exposes
some functions from our main Windows DLL to my web app. I get the same
error message whether I compile from the IDE or from our normal
command line based build process.

What database file does the message refer to?

Any help is appreciated.
-tomas

The full text of the build output is as follows:
------- COMPILE OUTPUT ----------------
Deleting intermediate files and output files for project 'MyProj',
configuration 'Debug|Win32'.
Compiling...
File1.cpp
AssemblyInfo.cpp
Generating Code...
Linking...
File1.obj : fatal error LNK1215: metadata operation failed (8013110E)
: Database file is corrupt and may not be usable.

Build log was saved at
"file://c:\Src800\tomasv\gui\webui\MyProj\Debug\BuildLog.h tm"
MyProj - 1 error(s), 0 warning(s)
------------ END OF OUTPUT --------

[Mohamoss]

Hi Tomas
In some other cases, this had to do with the order of #using<> statements
if you're including header files that also have #using<> statements). Make
sure you're not #using anything twice if you don't need to or at all if you
don't need it.

This usually happens because somehow the compiler puts
slightly different metadata in two modules for the same type. At link time,
when the metadata is merged, this error is emitted because the name for the
type is the same, but there is some discrepancy in the rest of the metadata
describing that type. The first thing I would look at are the command line
options used to compile the two modules, and then I would look at the
includes leading up to the definition of the type for the two modules. Both
of these things can sometimes affect the metadata for a type. If these
don't yield any clues, then I would use metainfo to dump the metadata for
the two object files, and look for the differences that way. Often this
will lead you back to the includes or the command line options

Mohamed Mahfouz
MEA Developer Support Center
ITworx on behalf of Microsoft EMEA GTSC

[Tomas Vera]

Thanks for your reply. But.....

This is an established project that has been compiling for several
months. So the order of the #using statements is not an issue in this
case.

My WebApp is a web-based front end for our standard Windows based
product. As I develop more dialogs (to match existing Windows
dialogs), I need to add some string wrappers to the strings available
to the Windows app. This is done through an enumeration in one of my
header files. For some reason, I can only add two more members to my
enumeration. Adding a third member causes the link error.

Creating a new enumeration does not ease the problem. I have even
tried adding an additional header file with no result.

Adding this statement into a class in a header that is included after
my string header solves all my problems:
static Dword const THIS_IS_JUNK = 1;

Why???

We had similar issues with the linker two years ago that related to
the number of "__gc struct" members allowed in a single header file
(no more than 16 "__gc struct" members were allowed in a single
header. This was acknowledged as a bug my MS and has since been
corrected.

I have not been able to identify the exact conditions that cause this
problem ( I have a fast-approaching deadline). But I have a
work-around. So for now, I will simply work around this and post any
insights at a later time.

Bottom line: buggy linker (again).

-tomas vera

On Sun, 05 Dec 2004 10:39:13 GMT, mo************@egdsc.microsoft.com
(Mohamoss) wrote:

Hi Tomas
In some other cases, this had to do with the order of #using<> statements
if you're including header files that also have #using<> statements). Make
sure you're not #using anything twice if you don't need to or at all if you
don't need it.

This usually happens because somehow the compiler puts
slightly different metadata in two modules for the same type. At link time,
when the metadata is merged, this error is emitted because the name for the
type is the same, but there is some discrepancy in the rest of the metadata
describing that type. The first thing I would look at are the command line
options used to compile the two modules, and then I would look at the
includes leading up to the definition of the type for the two modules. Both
of these things can sometimes affect the metadata for a type. If these
don't yield any clues, then I would use metainfo to dump the metadata for
the two object files, and look for the differences that way. Often this
will lead you back to the includes or the command line options

Mohamed Mahfouz
MEA Developer Support Center
ITworx on behalf of Microsoft EMEA GTSC