I've been working with the LLBLGen Pro tool for a couple and haven't found a thing that didn't work as expected until today.

I have two entities that have a single element primary key with Identity set to Y; Sql Server, ASP.NET, VB.NET environment.

In the example below the entity key is ChassisNotesId. When I debug to and through the Save method nothing is saved in the database and no error condition is raised.

Dim NewChassisNote As New ChassisNotesEntity Try NewChassisNote.ChassisNo = Me.ChassisNo NewChassisNote.DealerTruckPurchaseOrderYr = Me.DealerTruckPurchaseOrderYr NewChassisNote.DivisionCd = Me.DivisionCd NewChassisNote.ChassisNotesTxt = ChassisNotesTxt NewChassisNote.LateResponsibilityInd = LateResponsibilityInd NewChassisNote.SeverityLevelNo = SeverityLevelNo NewChassisNote.Save() Catch ex As Exception . .

.

And thoughts or suggestions? I imagine this should work and I'm missing something REALLY obvious.

Does the execution reach the UpdateEntity or InsertEntity methods in teh entity class? If so, if you debug through those methods, when will the execution end? Could you please take those steps for me? Also, what does Save() return? True or false? Thanks.

Ok, I think I see the problem and I hope there is a solution.

Here's the other table that I didn't show you before.

CREATE TABLE [dbo].[tb_Audit] ( [AuditID] [int] IDENTITY (1, 1) NOT NULL ) ON [PRIMARY]

As you can see it only has one attribute; the primary key.

I've encountered problems inserting rows into this table with straight SQL. I had to do the insert as such:

INSERT tb_audit DEFAULT VALUES

Could LLBLGen Pro have a similar issue with single attribute tables?

Right now I only have the LLBLGen Pro DLL's. I will have to get the source code tomorrow to be able to step into the Save method.

Paul wrote:

Right now I only have the LLBLGen Pro DLL's. I will have to get the source code tomorrow to be able to step into the Save method.

No you don't have to, you can set a breakpoint in the InsertEntity method of the ChassisNotesEntity class. Save will do some internal checks and then call InsertEntity if the entity is new or UpdateEntity if the entity is not new. THe save itself is controlled by InsertEntity and almost completely done in generated code (well, at the end a call to a base class method is done in the DAO class, but by then you have the query already.

I think it is indeed a problem, as the query will have no values nor fields set. As a workaround, add a dummy column with a type of char(1) which is nullable, and refresh the catalog, re-generate the code and you should be able to save the values.

As a tip, I think a better key in such a table would be of type GUID (UniqueIdentifier). GUID's survive backups and replication issues. Just a thought

Paul wrote:

CREATE TABLE [dbo].[tb_Audit] ( [AuditID] [int] IDENTITY (1, 1) NOT NULL ) ON [PRIMARY]

As you can see it only has one attribute; the primary key.

I've encountered problems inserting rows into this table with straight SQL. I had to do the insert as such:

INSERT tb_audit DEFAULT VALUES

I also have a similar table that LLBLGen doesn't seem to want to insert into. It needs the "INSERT tablename DEFAULT VALUES" command. Has this been fixed yet? Or do I have to add the char(1) column, then add logic to dirty the field so the record will save?

Thanks

TonyAlderman wrote:

Paul wrote:

CREATE TABLE [dbo].[tb_Audit] ( [AuditID] [int] IDENTITY (1, 1) NOT NULL ) ON [PRIMARY]

As you can see it only has one attribute; the primary key.

I've encountered problems inserting rows into this table with straight SQL. I had to do the insert as such:

INSERT tb_audit DEFAULT VALUES

A table with just an identity field isn't insertable by LLBLGen Pro. Not only does it require a weird query, such a table also doesn't really make sense, because the PK is artificial (which is OK), but at the same time the only information in the entity, and thus the entity doesn't contain any information.

I also have a similar table that LLBLGen doesn't seem to want to insert into. It needs the "INSERT tablename DEFAULT VALUES" command. Has this been fixed yet? Or do I have to add the char(1) column, then add logic to dirty the field so the record will save? Thanks

Yes, you have to add information to the entity. I might sound like a stubborn <censored> to not fix this, but I never could think of any sole reason why a table with solely 1 artificial PK field would have any reason for being there. Could you give you such a reason why the table is there, please?

Otis wrote:

A table with just an identity field isn't insertable by LLBLGen Pro. Not only does it require a weird query, such a table also doesn't really make sense, because the PK is artificial (which is OK), but at the same time the only information in the entity, and thus the entity doesn't contain any information.

That is correct -- My table is used to link records together. It has no information, and the PK is artificial.

Otis wrote:

Yes, you have to add information to the entity. I might sound like a stubborn <censored> to not fix this, but I never could think of any sole reason why a table with solely 1 artificial PK field would have any reason for being there. Could you give you such a reason why the table is there, please?

I have a diagram at

A family is made up of spouses (parents), children, and facts (notes) about the family. The "Family" table only has an identity field. "Spouse" and "Child" are many-to-many tables.

The "Individual" is the main table here -- the "Family", "Spouse", and "Child" tables exist to link individuals together.

TonyAlderman wrote:

Otis wrote:

A table with just an identity field isn't insertable by LLBLGen Pro. Not only does it require a weird query, such a table also doesn't really make sense, because the PK is artificial (which is OK), but at the same time the only information in the entity, and thus the entity doesn't contain any information.

That is correct -- My table is used to link records together. It has no information, and the PK is artificial.

So in other words, just a counter with no real meaning.

Otis wrote:

Yes, you have to add information to the entity. I might sound like a stubborn <censored> to not fix this, but I never could think of any sole reason why a table with solely 1 artificial PK field would have any reason for being there. Could you give you such a reason why the table is there, please?

I have a diagram at

A family is made up of spouses (parents), children, and facts (notes) about the family. The "Family" table only has an identity field. "Spouse" and "Child" are many-to-many tables.

The "Individual" is the main table here -- the "Family", "Spouse", and "Child" tables exist to link individuals together.

Ok, but why are 'Family' and 'FamilyFact' different tables? And what's the difference between FamilyFact.ID and FamilyFact.FamilyID ? isn't FamilyFact.FamilyID an FK to Family and thus unique, and which thus makes FamilyFact.ID redundant?

The point is: if you create a NIAM/ORM diagram of entities and attributes of your model, the 'Family' entity will never end up in its own table, as it's part of FamilyFact.

a singlr family (familyid) can have many family facts associated with it (familyfactid), but none of the information (other than it's id) about the family is stored in family.

arschr wrote:

a singlr family (familyid) can have many family facts associated with it (familyfactid), but none of the information (other than it's id) about the family is stored in family.

Ah, ok, but that doesn't mean the entity 'family' actually exists, simply because it doesn't hold any data, there aren't any other attributes besides an artificial ID field. IMHO the analysis is not complete and Family should have more attributes, for example some which are meant to be stored in the facts table (though it might be the facts table is for something else).

Note: I understand that by using such a table, you can define an fk field in the other tables, but what does '5' semantically mean in such a case for example?

arschr wrote:

a singlr family (familyid) can have many family facts associated with it (familyfactid), but none of the information (other than it's id) about the family is stored in family.

That is correct.

Otis wrote:

Ah, ok, but that doesn't mean the entity 'family' actually exists, simply because it doesn't hold any data, there aren't any other attributes besides an artificial ID field. IMHO the analysis is not complete and Family should have more attributes, for example some which are meant to be stored in the facts table (though it might be the facts table is for something else).

No, there is no data from the Facts table that can be moved to the Family table. I can get into why (for one, duplicate facts from different sources are necessary), but that is not the point of this post. Beleive me, I have no additional information for the Family table. This is a working database.

Otis wrote:

Note: I understand that by using such a table, you can define an fk field in the other tables, but what does '5' semantically mean in such a case for example?

You are correct -- it doesn't mean anything. It is a mechanism to group records together. There is no real-world key for Family.

OK, having to work with a database which can't be altered is a reason for me to fix it. I'll add the proper code to 1.0.2005.1

Otis wrote:

OK, having to work with a database which can't be altered is a reason for me to fix it. I'll add the proper code to 1.0.2005.1

Thanks! I think you have a great product -- I have recommended to it my friends.

TonyAlderman wrote:

Otis wrote:

OK, having to work with a database which can't be altered is a reason for me to fix it. I'll add the proper code to 1.0.2005.1

Thanks! I think you have a great product -- I have recommended to it my friends.

It's added, it turned out to be 5 lines of code