hi,

I got v2.0 llbl gen project. I successfully converted that to v3.0 llbl gen project. when I tried to validate the v3.0 project its giving following error.

The entity 'xxxx' is mapped on to the target 'dbo.xxxx' however 'xxxx' doesn't have any identifying field set , while the target is a table. when an entity is mapped onto a table, it requires at least one identifying field.

After doing some debug i found that the table had no primary key. So I defined one column(id) as identifying fields using designer. I got the following error.

Mapped Target - The isNullable flag on target field 'dbo.xxx.id' is set to 'True' while the IsOptionalFlag of the mapped field 'id' is set to 'False'.

Unfortunately the table doesn't have any not null columns to define identifying fields. Earlier v2.0 project allows these types of table to add to project . So I used those table entities In my application. now v3.0 is not allowing..So i can't use those table entites in my web application. But I need those.. Please help me out.

thanks in advance, kalyan.

Please go to the "Field Mapings" tab and select the field. Then hit the "Edit Field" button, and then remove the "Is nullable" check.

Is it mandatory to define the identifying field ? or can we bypass that error with out defining identifying field?

It's mandatory for tables.

You can do two things: 1) create a typedview instead of an entity for these tables. In v3 you can map a typedview onto a table. As these tables can only be used in a read-only fashion anyway, it doesn't make much difference in practice 2) create a view for the table (this leaves the table untouched) and map the entity onto the view instead of the table.

Currently I evaluating version 3.1.. My company had version 1.0.2005.1 which is quite old, but still very powerfull. Migrations is quite complex, because we made many custom templates.

Now I am evaluating new LLBL version for next project.. Old LLBL version generates tables without any problems. Hovewer, the new one has these "identity" errors.

I really do not want to go through all tables and add identies which in fact are not used at all... (I know its a bad design, but currently I do not want to touch database) . Also I cannot make views, because there are inserts to them..

So my question, is there any way to avoid such kind of validation?

Otis wrote:

It's mandatory for tables.

You can do two things: 1) create a typedview instead of an entity for these tables. In v3 you can map a typedview onto a table. As these tables can only be used in a read-only fashion anyway, it doesn't make much difference in practice 2) create a view for the table (this leaves the table untouched) and map the entity onto the view instead of the table.

If the table has a unique field, you may set this field to be the identifying field in the Designer. Else you'd better use a TypedView instead of an entity.

Sure, I know this variant.. But sill not all has such column.. Event worse: I have some tables, which has 2 columns, both are foreign keys, no PK and no unique field..

Walaa wrote:

If the table has a unique field, you may set this field to be the identifying field in the Designer. Else you'd better use a TypedView instead of an entity.

Hi Kalyan,

cerberis wrote:

So my question, is there any way to avoid such kind of validation?

Is short, no.

cerberis wrote:

Sure, I know this variant.. But sill not all has such column.. Event worse: I have some tables, which has 2 columns, both are foreign keys, no PK and no unique field..

I know you are struggling about this. But really, this is an improvement because in the generated code, tables without PK are useless in select/update scenarios. So, the workarounds for you are those posted by Frans. Is it possible for your application to go through these workarounds?

daelmo wrote:

I know you are struggling about this. But really, this is an improvement because in the generated code, tables without PK are useless in select/update scenarios.

I understand your improvement, still framework should not prevent to have such cases. I would say - it should be possible to disable such validation. We have situations, when we need only to read from such tables, because inserts are done by some triggers and so on.. And yes, I agree - its a bad design, but some old applications works in such way and I cannot change that.

daelmo wrote:

Is it possible for your application to go through these workarounds?

Not for evaluation...

We have situations, when we need only to read from such tables, because inserts are done by some triggers and so on.. And yes, I agree - its a bad design, but some old applications works in such way and I cannot change that.

I think you are missing one point here.

If you only want read-Only dataStructure, then you should use TypedViews, these are objects defined in LLBLGen Pro Designer, and not the database.

So instead of maping these tables to Entities and generating code for entities, you should map these tables to TypedViews, and generate code accordingly.

TypedViews are used for such read-only scenarioes.

Walaa wrote:

We have situations, when we need only to read from such tables, because inserts are done by some triggers and so on.. And yes, I agree - its a bad design, but some old applications works in such way and I cannot change that.

I think you are missing one point here.

If you only want read-Only dataStructure, then you should use TypedViews, these are objects defined in LLBLGen Pro Designer, and not the database.

So instead of maping these tables to Entities and generating code for entities, you should map these tables to TypedViews, and generate code accordingly.

TypedViews are used for such read-only scenarioes.

Its not always the case, when its read-only. There are also tables where it can be inserts from code or updates by some values (not by PK), using UpdateEntitiesDirectly or even deletes..

If you really want this, the only option is to set IdentifyingFieldsFollowDBPrimaryKeyConstraints to false in the project properties. Then you can add the PK to the entity. This will not require a PK definition in the table. As you can't change the DB, you won't refresh the project anyway.

Otis wrote:

If you really want this, the only option is to set IdentifyingFieldsFollowDBPrimaryKeyConstraints to false in the project properties. Then you can add the PK to the entity. This will not require a PK definition in the table. As you can't change the DB, you won't refresh the project anyway.

Thank you, this fits for my needs