Re: Error MVE133 'class must be abstract'

[Erik Reischl]

Just one more detail:

It works all right if there is no persistence mapper or if
PersistenceMapperXML is used. For PersistenceMapperSQLServer or
PersistenceMapperBdp (with SQL Server) it crashes.

Erik

[Erik Reischl]

Hi there,

I have a strange phenonemon. I have a model with four classes.
One of them is an abstract base class which two other classes
inherit from, the other one is just normal by itself. The
abstract class has one attribute which is of course common for
the two child classes, then each child class has its own
attributes. No associations, so everything is pretty simple.

Now the only thing I wanted to have is that the common attribute
isn't stored in the table for the abstract class, but in each of
the tables of the child classes. Therefore, I set the
TableMapping property for the abstract class to "Children". But
after compiling and validating the model, I get an error:

Error MVE133 "class must be abstract" (something like this, the
message is in german). But hey, the class IS abstract.

Even more strange: I start a new project from scratch, design
more or less the same model, compile, validate, and validation is
okay.

So, again my own stupidity or did I find a bug there?

Whatever I do, I simply cannot get my "old" project/model to be
validated to okay. Any hints, suggestions, help, ideas?

Cheers,

Erik

[Tao Lei]

Sometimes, the Class is "abstract" or "sealed" in Eco Class Diagram, but not in code, which I'm not sure can be considered as bug.
Have you checked code to verify "TYourClass = class abstract(...)" ?

"Erik Reischl" <erik.r...@lrpREMOVE.THISde> wrote news:444f52da$1...@newsgroups.borland.com...

[Erik Reischl]

"Tao Lei" <worldw...@sina.com.cn> wrote:
>Sometimes, the Class is "abstract" or "sealed" in Eco Class
>Diagram, but not in code, which I'm not sure can be considered as
>bug.
>Have you checked code to verify "TYourClass = class
>abstract(...)" ?

That's exactly what I needed! Works perfectly, thanks a lot!!

Erik

P.S.: Just for completeness, I have the impression that this might
be a but indeed, but it might be good to have an official
statement. Anyway, I'll wait until Update 2 is available in
german, maybe this is solved already.

[Jesper Hogstrom (Borland)]

Erik Reischl wrote:
> It works all right if there is no persistence mapper or if
> PersistenceMapperXML is used. For PersistenceMapperSQLServer or
> PersistenceMapperBdp (with SQL Server) it crashes.

Mapping information is only used in SQL persistence, so it is only
checked if the storage backend is indeed a sql database.

--Jesper

[Jonas Hogstrom]

Erik Reischl wrote:

It does seem to be a bug. I think the bug is in the delphi codedom
implementation. the Eco code generator will try to set the class to
abstract, and in C# it works, but in delphi, the additional keyword
"abstract" is not emitted to the source, and thus, the compiled model
does not realize that your class is abstract even if it looks like an
abstract class in the designer (and in the ecopkg-file). The bugreport
is now in RAID (223311).

--
/Jonas, Borland Eco R&D

[Erik Reischl]

"Jonas Hogstrom" <jonas.ho...@spam.please.borland.com> schrieb im
Newsbeitrag news:4459f274$1...@newsgroups.borland.com...

> > P.S.: Just for completeness, I have the impression that this might
> > be a but indeed, but it might be good to have an official
> > statement. Anyway, I'll wait until Update 2 is available in
> > german, maybe this is solved already.
>
> It does seem to be a bug. I think the bug is in the delphi codedom
> implementation. the Eco code generator will try to set the class to
> abstract, and in C# it works, but in delphi, the additional keyword
> "abstract" is not emitted to the source, and thus, the compiled model
> does not realize that your class is abstract even if it looks like an
> abstract class in the designer (and in the ecopkg-file). The bugreport
> is now in RAID (223311).

Thanks so much again, Jonas!

Erik