I kind of asked this question previously (http://www.llblgen.com/TinyForum/Messages.aspx?ThreadID=3285) but it's been a while now and have come across the problem all over again!

We have a table with a "surrogate key" and need to generate code for the relationships between it and its relations as defined in SQL Server.

PK PK SK (UC) 1------m FK

Is this supported yet and if not (as we need it...) what would be you suggestion to implement?

[EDIT: also asked here: http://llblgen.com/TinyForum/Messages.aspx?ThreadID=9461&HighLight=1]

Marcus

A workaround is to generate the code according to a a dumy table schema.

Temporarily rename or drop the existing table and create another one with the UC as the PK. Generate your code and then go back to the original schema.

Walaa wrote:

A workaround is to generate the code according to a a dumy table schema.

Temporarily rename or drop the existing table and create another one with the UC as the PK. Generate your code and then go back to the original schema.

Thanks Walaa, but not very maintainable...

We have just hacked the various containers into place using partial classes for now and will write our own fetch logic.

I never really understood why these kind of relations were not support especially if they have been defined in SQL Server...

Marcus

Well you may also use a view on that table and map the view to an entity where you set the UC columns as the PK in the Designer.

I never really understood why these kind of relations were not support especially if they have been defined in SQL Server

Please have a look at the following thread where such discussions were made: http://www.llblgen.com/TinyForum/Messages.aspx?ThreadID=9564 http://www.llblgen.com/TinyForum/Messages.aspx?ThreadID=3459

(Edit) ANother thread: http://www.llblgen.com/TinyForum/Messages.aspx?ThreadID=11832

It was a tremendous amount of work to add, so we skipped it. It seemed simple at first, so we started working on it in v2.5, but the checks required to make this 100% fail safe when things CHANGE was a bit of a problem, because logic for relations is based on a PK side and an fk side, which isn't the case here.