Hi there,

Not sure if this is an issue, but I get the above error on columns within derived classes where the column in the parent class also exists in the child class.

In my example I have two tables that share a primary key (one-to-one). Any "select" generated in the OracleDQE forms an alias on the PK column as "ColumnName_FullEntityName", and this almost always exceeds the 30 character limit in Oracle. I have made sure the entity class property name is identical to the database column name.

I am using the "1.0.2005.1 Final DEMO" version of LLBLGEN, and using the SelfServicing project type.

Any ideas (besides renaming the property and/or class)?

Is there any way you could add a feature to LLBLGEN to force a certain length of alias? E.g. in the app.config?

Thanks, Brian Johnson.

Trimming the alias would break generic code also used for other databases. So you should keep your entity fields' length below 30 chars. This is in general enough for most names.

If you have only field names in your entities of less than 30 characters, please let us know as that suggests a bug is located somewhere and we have to investigate it further.

Otis wrote:

Trimming the alias would break generic code also used for other databases. So you should keep your entity fields' length below 30 chars. This is in general enough for most names.

If you have only field names in your entities of less than 30 characters, please let us know as that suggests a bug is located somewhere and we have to investigate it further.

My entity name is 26 characters (VariationApplicationEntity) while my PK is 16 characters (VarApplicationId - the name of the db column), but this extended way past 30 when combined. It is only happening on the PK of this entity as a look at the generated query shows that the alias used for the PK is actually "VarApplicationId_VariationApplicationEntity", unlike the other fields that are using aliases that are the same as their column names. All other property names are less than 30 characters, as are the db column names.

I have changed the PK properyt name in my Entity to just "Id" so that the total is down to 29 characters ("Id_VariationApplicationEntity") which works. This issue only seems to appear on entities with derived entities. In this case, VariationApplicationEntity has a sub-type called VcmsCaseEntity (also has a db column called "VarApplicationId"). Other entities in the system also could easily break this length, but since they do not partake in any derived structure they all seem to work fine.

Hope this helps

zebranky wrote:

Otis wrote:

Trimming the alias would break generic code also used for other databases. So you should keep your entity fields' length below 30 chars. This is in general enough for most names.

If you have only field names in your entities of less than 30 characters, please let us know as that suggests a bug is located somewhere and we have to investigate it further.

My entity name is 26 characters (VariationApplicationEntity) while my PK is 16 characters (VarApplicationId - the name of the db column), but this extended way past 30 when combined. It is only happening on the PK of this entity as a look at the generated query shows that the alias used for the PK is actually "VarApplicationId_VariationApplicationEntity", unlike the other fields that are using aliases that are the same as their column names. All other property names are less than 30 characters, as are the db column names.

Strange, as the query should use aliases like F0, F1, F2 etc. if the fetch is a fetch for entities which are in a hierarchy...

Could you please paste a small piece of code (2, 3 lines) which initiates the fetch and the query produced? (by using DQE tracing, see Troubleshooting and debugging).

Otis wrote:

Strange, as the query should use aliases like F0, F1, F2 etc. if the fetch is a fetch for entities which are in a hierarchy...

Could you please paste a small piece of code (2, 3 lines) which initiates the fetch and the query produced? (by using DQE tracing, see Troubleshooting and debugging).

Apologies for the delay. I think the problem apears to be a version issue, as the version of LLBLGEN I have now and the old version that produced the code were different. The "F0", "F1" seems to be happening now, so I cannot reproduce the issue.

Good Please re-open the thread if you run into it again.