LLBLGen fails handling back fields with long column names

Posts   
 
    
AlexP
User
Posts: 17
Joined: 24-Jan-2020
# Posted on: 01-Mar-2021 11:29:49   

Hi,

we're facing an issue when using LLBLGen on a '3rd party' (well, not one we control) database. That Oracle database has a couple of columns that are more than 30 characters (the pre ?12.2? limitation).

When querying the database Oracle returns an ORA-00904 invalid identifier and tells us that a specific table doesnt have a column called F__4175993907.

Is there some setting in LLBLGen that we should change, or could this perhaps be some LLBLGen issue?

Note: we can't change the column name to circumvent this problem as it's not ours.

Walaa avatar
Walaa
Support Team
Posts: 14983
Joined: 21-Aug-2005
# Posted on: 01-Mar-2021 22:34:40   

Could you please provide more details on the LLBLGen Pro version you are using, the exact version of the database and the driver you are using?

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39749
Joined: 17-Aug-2003
# Posted on: 02-Mar-2021 08:52:40   

I think it's a limitation at the moment. We could correct this for the latest v5.6/5.7 versions btw. They currently always clamp the names regardless of whether you've set the compatibility to 12C+ or not.

Frans Bouma | Lead developer LLBLGen Pro
AlexP
User
Posts: 17
Joined: 24-Jan-2020
# Posted on: 02-Mar-2021 09:06:45   

Walaa wrote:

Could you please provide more details on the LLBLGen Pro version you are using, the exact version of the database and the driver you are using?

We are using LLBLGen 5.7.2 (can upgrade to 5.7.3) in combination with Oracle.ManagedDataAccess 19.10.1. Which are prety recent versions.

AlexP
User
Posts: 17
Joined: 24-Jan-2020
# Posted on: 02-Mar-2021 09:12:00   

Otis wrote:

I think it's a limitation at the moment. We could correct this for the latest v5.6/5.7 versions btw. They currently always clamp the names regardless of whether you've set the compatibility to 12C+ or not.

Is that something we could do ourselves, by overriding or 'hiding' a certain method or implementing a specific 'handler'?

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39749
Joined: 17-Aug-2003
# Posted on: 02-Mar-2021 10:52:55   

Yes, you can for the time being compile the runtime sourcecode yourself and make a change there. First download the sourcecode archive from the website, it's located under 'Extras' under My Account -> Downloads -> <version> Then open the runtimelibraries sourcecode .sln in visual studio or rider and remove everything except the Oracle DQE project.

  • Reference the ORMSupportClasses package from nuget
  • In AssemblyInfo/SharedAssemblyInfo.cs, remove the strong key reference

Now to fix this, open OracleSpecificCreator.cs, and on line 83, change : base(true) into :base(false). That's it. Compile the project and in your own project reference that DQE dll instead of the one we ship.

I see the long names are introduced in 12.2. This kind of sucks as we have a compatibility level of 12C, which doesn't support long names, so we need to add a new compatibility level too to make this doable for people who use 12.2 but also have people who use 12.0 C have their long aliases be converted properly to short names. disappointed

We can silently introduce a new compatibility level in 5.7 and document it in 5.8 (which is now in beta).

Edit: another way we can fix this is to keep the clamping for aliases (as that won't hurt you) and remove the clamping for table / view fields as these names come straight from the meta-data anyway so clamping these is a bit redundant (and won't work anyway at runtime).

Frans Bouma | Lead developer LLBLGen Pro
AlexP
User
Posts: 17
Joined: 24-Jan-2020
# Posted on: 02-Mar-2021 11:51:04   

Thank you very much for your help. We will have a look at fixing it 'for the time being' the way you've mentioned.

Hopefully the issue gets fixed in a future version of LLBLGen ... perhaps version 5.8

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39749
Joined: 17-Aug-2003
# Posted on: 02-Mar-2021 13:11:26   

yeah we're going to remove the table/field name clamping as it doesn't make sense, thinking about it: the name is always 30 chars or lower if it's been created from metadata from a DB of v12C or earlier, and if the schema is created on 12.2C or later and has longer names, and the project is created on that schema and then used on a database with 'equal' schema but shorter names, the behavior is undefined as it is. So the aliases you're going to use will still be clamped to 30 characters, but that's ok, you won't notice that.

Frans Bouma | Lead developer LLBLGen Pro
Otis avatar
Otis
LLBLGen Pro Team
Posts: 39749
Joined: 17-Aug-2003
# Posted on: 02-Mar-2021 14:30:45   

We've made this change in v5.7.4 hotfix, which is now available

Frans Bouma | Lead developer LLBLGen Pro