Hi there,

I seem to be back to this issue again, and I think I may know the scenario: 1. I have a table with a trigger that generates a new number using an Oracle Sequence. 2. I save the entity fine:

vcmsCase.Save(true);
if (vcmsCase.SelectedSectionCollection.Count > 0 && vcmsCase.IsCaseComplete)...

As soon as the 'vcmsCase.SelectedSectionCollection.Count' is called, the error is raised.

Here is the LLBLGEN output:

Method Enter: CreateSelectDQ
Generated Sql query: 
    Query: SELECT "VCMS"."VARAPPLICATION"."VARAPPLICATIONID" AS "VcmsApplicationId_VcmsApplicationEntity", "VCMS"."VARAPPLICATION"."CAPTUREUSERID" AS "CaptureUserId", "VCMS"."VARAPPLICATION"."VARIATIONTYPEID" AS "VariationTypeId", "VCMS"."VARAPPLICATION"."INDUSTRYSECTORCODE" AS "IndustrySectorCode", "VCMS"."VARAPPLICATION"."APPLICATIONNUMBER" AS "ApplicationNumber", "VCMS"."VARAPPLICATION"."PARTYID" AS "PartyId", "VCMS"."VARAPPLICATION"."APPLICATIONDATE" AS "ApplicationDate", "VCMS"."VARAPPLICATION"."PROVINCEID" AS "ProvinceId", "VCMS"."VARAPPLICATION"."VARIATIONFROM" AS "VariationFrom", "VCMS"."VARAPPLICATION"."VARIATIONTO" AS "VariationTo", "VCMS"."VARAPPLICATION"."TOTALEMPLOYEES" AS "TotalEmployees", "VCMS"."VARAPPLICATION"."TOTALEMPLOYEESAFFECTED" AS "TotalEmployeesAffected", "VCMS"."VARAPPLICATION"."VARIATIONREASON" AS "VariationReason", "VCMS"."VARAPPLICATION"."HASPOINTOFDISSENTION" AS "HasPointsOfDissention", "VCMS"."VARAPPLICATION"."POINTSOFDISSENTION" AS "PointsOfDissention", "VCMS"."VARAPPLICATION"."HASOTHERPARTYDISPUTE" AS "HasOtherPartyDispute", "VCMS"."VARAPPLICATION"."OTHERPARYTDISPUTEDETAILS" AS "OtherPartyDisputeDetails", "VCMS"."VARAPPLICATION"."SIGNATORYNAME" AS "SignatoryName", "VCMS"."VARAPPLICATION"."SIGNATORYPOSITION" AS "SignatoryPosition", "VCMS"."VARAPPLICATION"."SIGNATORYDATE" AS "SignatoryDate", "VCMS"."VCMSCASE"."VARAPPLICATIONID" AS "VcmsApplicationId", "VCMS"."VCMSCASE"."CURRENTASSIGNID" AS "CurrentAssignId" FROM ( "VCMS"."VARAPPLICATION"  INNER JOIN "VCMS"."VCMSCASE"  ON  "VCMS"."VARAPPLICATION"."VARAPPLICATIONID"="VCMS"."VCMSCASE"."VARAPPLICATIONID") WHERE ( "VCMS"."VARAPPLICATION"."VARAPPLICATIONID" = :LGPPARAM_1)
    Parameter: :LGPPARAM_1 : Binary. Length: 0. Precision: 0. Scale: 0. Direction: Input. Value: binary lob.
Method Exit: CreateSelectDQ

Note the 'VcmsApplicationId_VcmsApplicationEntity' column name right at the beginning of the generated query.

The last time I logged this (see http://www.llblgen.com/TinyForum/Messages.aspx?ThreadID=6501), the issue was resolved by having aliases named as 'f0', 'f1' etc. Should this not also be applied in this instance too? The actual entities I am working with are the identical ones to that last thread, just the scenario is different (hence why I opened a new thread).

Using LLBLGEN Pro v1.0.2005.1 Final, June 19th 2006. Using Self-Servicing. Using VS 2005, ASP.NET 2.

Regards, Brian Johnson

Hmm. Could you give me the tables in the inheritance tree of the entities resp.: vcmsCase and SelectedSection and the relation between these two entities as well (vcmsCase -> selectedsection) ? It indeed should use F0, F1 etc. If it doesn't, it can't read the row back into an entity anyway. Strange.

As requested, these are the table scripts:

  CREATE TABLE "VCMS"."VCMSCASE" 
   (    "VARAPPLICATIONID" RAW(16) DEFAULT NULL NOT NULL ENABLE, 
    "CURRENTASSIGNID" RAW(16), 
     CONSTRAINT "PK_VCMSCASE_ID" PRIMARY KEY ("VARAPPLICATIONID") ENABLE, 
     FOREIGN KEY ("CURRENTASSIGNID")
      REFERENCES "VCMS"."VCMSCASEASSIGN" ("ASSIGNID") ENABLE, 
     FOREIGN KEY ("VARAPPLICATIONID")
      REFERENCES "VCMS"."VARAPPLICATION" ("VARAPPLICATIONID") ENABLE
   ) ;

  CREATE TABLE "VCMS"."VARAPPLICATION" 
   (    "VARAPPLICATIONID" RAW(16) DEFAULT NULL NOT NULL ENABLE, 
    "CAPTUREUSERID" RAW(16) NOT NULL ENABLE, 
    "VARIATIONTYPEID" RAW(16), 
    "INDUSTRYSECTORCODE" VARCHAR2(4 BYTE) NOT NULL ENABLE, 
    "APPLICATIONNUMBER" NUMBER(38,0) NOT NULL ENABLE, 
    "PARTYID" VARCHAR2(32 BYTE) NOT NULL ENABLE, 
    "APPLICATIONDATE" DATE DEFAULT SYSDATE NOT NULL ENABLE, 
    "PROVINCEID" NUMBER(10,0) NOT NULL ENABLE, 
    "VARIATIONFROM" DATE NOT NULL ENABLE, 
    "VARIATIONTO" DATE NOT NULL ENABLE, 
    "TOTALEMPLOYEES" NUMBER(38,0) NOT NULL ENABLE, 
    "TOTALEMPLOYEESAFFECTED" NUMBER(38,0) NOT NULL ENABLE, 
    "VARIATIONREASON" CLOB, 
    "HASPOINTOFDISSENTION" NUMBER(1,0) DEFAULT 0 NOT NULL ENABLE, 
    "POINTSOFDISSENTION" CLOB, 
    "HASOTHERPARTYDISPUTE" NUMBER(1,0) DEFAULT 0 NOT NULL ENABLE, 
    "OTHERPARYTDISPUTEDETAILS" CLOB, 
    "SIGNATORYNAME" VARCHAR2(100 BYTE) NOT NULL ENABLE, 
    "SIGNATORYPOSITION" VARCHAR2(100 BYTE) NOT NULL ENABLE, 
    "SIGNATORYDATE" DATE DEFAULT SYSDATE    , 
     CONSTRAINT "PK_VARAPP_ID" PRIMARY KEY ("VARAPPLICATIONID") ENABLE, 
     FOREIGN KEY ("VARIATIONTYPEID")
      REFERENCES "VCMS"."VARIATIONTYPE" ("VARIATIONTYPEID") ENABLE, 
     FOREIGN KEY ("CAPTUREUSERID")
      REFERENCES "VCMS"."SECURITYUSERS" ("USERID") ENABLE
   ) ;

  CREATE TABLE "VCMS"."SELECTEDSECTION" 
   (    "VARAPPLICATIONID" RAW(16) DEFAULT NULL NOT NULL ENABLE, 
    "SECTIONIDKEY" RAW(16) DEFAULT sys_guid() NOT NULL ENABLE, 
     CONSTRAINT "PK_SELSEC_ID" PRIMARY KEY ("VARAPPLICATIONID", "SECTIONIDKEY") ENABLE, 
     FOREIGN KEY ("SECTIONIDKEY")
      REFERENCES "VCMS"."LEGISLATIONSECTION" ("SECTIONIDKEY") ENABLE, 
     FOREIGN KEY ("VARAPPLICATIONID")
      REFERENCES "VCMS"."VARAPPLICATION" ("VARAPPLICATIONID") ENABLE
   ) ;

And the class hierarchy/relations as follows:

class VcmsApplicationEntity
{
    SelectedSectionCollection;
}

class VcmsCaseEntity : VcmsApplicationEntity;

class SelectedSectionEntity;

Edit: I have the inheritance set as "One target (view/table) per entity type" for VcmsCaseEntity and VcmsApplicationEntity. The VcmsCaseEntity 'extends' the VcmsApplicationEntity with additional information. The VARAPPLICATIONID on VCMSCASE is unique, so a 1:1 relationship with VARAPPLICATION. SELECTEDSECTION is an n:1 relationship to VARAPPLICATION/VCMSCASE.

The error occurs in the query generated to fetch the just saved entity. It indeed should use F0, F1, F2 etc.

In a test I can reproduce this though. Looking into it. Seems like a bug.

Will be fixed in the next build of 1.0.2005.1. Also present in v2.0. Bug in Oracle DQE.