Using Selfservicing against an SqlExpress2008 database (containing very little data), .Net 3.5 VS2008.

While trying to solve another issue (Linq related), I downloaded the latest build of the application (Build - April 15th, release May 12th 2009) from your website and installed it over the existing installation, also installed the runtime libraries (2.6.09.0512), and also the dll you attached to my earlier post with the Linq fix.

I made a minor change to my database and tried to run LLBLGen against it (which I have done thousands of times before). I received this message:

Message: An item with the same key has already been added.

Stack Trace: -----[Core exception]--------------------
   at System.ThrowHelper.ThrowArgumentException(ExceptionResource resource)
   at System.Collections.Generic.Dictionary`2.Insert(TKey key, TValue value, Boolean add)
   at SD.LLBLGen.Pro.ApplicationCore.Entities.EntityRelationCollection.Add(EntityRelation relationToAdd)
   at SD.LLBLGen.Pro.ApplicationCore.Entities.EntityContainer.ConstructRelations(EntityDefinition entityToUpdate, Int32 recursionDepth)
   at SD.LLBLGen.Pro.ApplicationCore.Entities.EntityContainer.Add(EntityDefinition definitionToAdd)
   at SD.LLBLGen.Pro.ApplicationCore.Project.AddRawEntitiesToProject(ArrayList rawEntitiesToAdd)
   at SD.LLBLGen.Pro.Gui.Forms.ProjectExplorer.RetrieveEntitiesFromCatalogs(EntityMapTargetElementType typeOfTarget)
   at SD.LLBLGen.Pro.Gui.Forms.ProjectExplorer._menuItemEntitiesGetEntitiesOnTablesFromCatalog_Click(Object sender, EventArgs e)
   at System.Windows.Forms.ToolStripItem.RaiseEvent(Object key, EventArgs e)
   at System.Windows.Forms.ToolStripMenuItem.OnClick(EventArgs e)
   at System.Windows.Forms.ToolStripItem.HandleClick(EventArgs e)
   at System.Windows.Forms.ToolStripItem.HandleMouseUp(MouseEventArgs e)
   at System.Windows.Forms.ToolStripItem.FireEventInteractive(EventArgs e, ToolStripItemEventType met)
   at System.Windows.Forms.ToolStripItem.FireEvent(EventArgs e, ToolStripItemEventType met)
   at System.Windows.Forms.ToolStrip.OnMouseUp(MouseEventArgs mea)
   at System.Windows.Forms.ToolStripDropDown.OnMouseUp(MouseEventArgs mea)
   at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks)
   at System.Windows.Forms.Control.WndProc(Message& m)
   at System.Windows.Forms.ScrollableControl.WndProc(Message& m)
   at System.Windows.Forms.ToolStrip.WndProc(Message& m)
   at System.Windows.Forms.ToolStripDropDown.WndProc(Message& m)
   at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
   at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
   at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)

Source: mscorlib

I then removed all the entities from the project and tried a 'Refresh this catalog..', which succeeded, but when I tried to add all the entities back (selected them and pressed ok), I got the error.

I created a new project from scratch and tried again, but same problem. Screenshot attached.

I suspect that possibly some library is out of sync? Can you suggest a process whereby I could fix this problem?

Problem solved - a table had a 1:1 relationship against itself. No idea how that happened. I deleted the relationship and everything works again.

Meteor wrote:

Problem solved - a table had a 1:1 relationship against itself. No idea how that happened. I deleted the relationship and everything works again.

Could you describe the 1:1 relationship for me please? Was it a buggy FK on the PK (so pk referred to itself) or was it a normal 1:1 relationship with an FK field and a UC ? Because this error occurs inside a piece of code which was recently changed to optimize the creation of large numbers of relationships between a small group of entities.

Frans,

I didn't take much notice. I decided to go through the database and see if anything was funny, so the first thing I did was open a diagram I'd created a while back. I browsed the tables and noticed that one table had a line coming off it and back again in a kind of square shape. I realised this was completely wrong (because I designed the database and I know that table only has one relationship) so I just deleted the line, saved the diagram, then re-ran LLBLGen against the db.

Sorry I can't give you more info, but I reckon it should be pretty easy to reproduce. The table has an integer type identity column as the pk, called [key], and a couple of varchar columns. It is referenced by one other table using the pk.

I can send you the script for the table if you like.

Meteor wrote:

Frans,

I didn't take much notice. I decided to go through the database and see if anything was funny, so the first thing I did was open a diagram I'd created a while back. I browsed the tables and noticed that one table had a line coming off it and back again in a kind of square shape. I realised this was completely wrong (because I designed the database and I know that table only has one relationship) so I just deleted the line, saved the diagram, then re-ran LLBLGen against the db.

Sorry I can't give you more info, but I reckon it should be pretty easy to reproduce. The table has an integer type identity column as the pk, called [key], and a couple of varchar columns. It is referenced by one other table using the pk.

I can send you the script for the table if you like.

The thing is that sqlserver allows you to define a foreign key on a field F which points to itself if it's the PK (so an unusable FK), which might be the cause, also because you say the table has just a set of varchar fields so if it has an FK to self, it would need an int field to be the FK field as well. I'll see if I can repro it with a simple FK/UC setup.

Reproduced. Scenario: - first create a 1:1 relationship between an FK field and the same table's PK field and place a UC on the FK field - create project, refresh if you will, works - then remove the UC (so the relationship becomes 1:n) - refresh -> crash.

(edit) it is caused by the PK->PK constraint, created by the sqlserver management studio or something:

CREATE TABLE [dbo].[FKToSelfTest](
    [ID] [int] IDENTITY(1,1) NOT NULL,
    [FKField] [int] NULL,
 CONSTRAINT [PK_FKToSelfTest] PRIMARY KEY CLUSTERED 
(
    [ID] ASC
)WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY],
 CONSTRAINT [IX_FKToSelfTest] UNIQUE NONCLUSTERED 
(
    [FKField] ASC
)WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]
) ON [PRIMARY]

GO
ALTER TABLE [dbo].[FKToSelfTest]  WITH CHECK ADD  CONSTRAINT [FK_FKToSelfTest_FKToSelfTest] FOREIGN KEY([FKField])
REFERENCES [dbo].[FKToSelfTest] ([ID])
GO
ALTER TABLE [dbo].[FKToSelfTest] CHECK CONSTRAINT [FK_FKToSelfTest_FKToSelfTest]
GO
ALTER TABLE [dbo].[FKToSelfTest]  WITH CHECK ADD  CONSTRAINT [FK_FKToSelfTest_FKToSelfTest1] FOREIGN KEY([ID])
REFERENCES [dbo].[FKToSelfTest] ([ID])
GO
ALTER TABLE [dbo].[FKToSelfTest] CHECK CONSTRAINT [FK_FKToSelfTest_FKToSelfTest1]

This of course goes wrong, the unique marker for this relationship is not 'unique'. It's also a useless FK.

This is caused by the fact that when you click 'Add' on the FK creation dialog in SSMS (sqlserver management studio), it automatically adds an FK with PK->PK, which of course is not what you want. If you then not change the fields, you keep this around and it will cause problems. I'll add code to check for this and ignore it.

The table 'Lines' is a top level table, in that it doesn't reference any other tables.

I just noticed (because I'm not at work) that you can create a 1:1 relationship with for example the Categories table in Northwind from CategoryId to CategoryId in the same table. I'm positive that that's what happened, and that's what caused LLBL to crash.

Meteor wrote:

The table 'Lines' is a top level table, in that it doesn't reference any other tables.

I just noticed (because I'm not at work) that you can create a 1:1 relationship with for example the Categories table in Northwind from CategoryId to CategoryId in the same table. I'm positive that that's what happened, and that's what caused LLBL to crash.

Exactly, I now see that too (see my edit above ). Not a regular case but crashes are not nice, so I'll add code to check for this. Thanks for the heads up!

Fixed in next build.