I would then recommend mapping the ACCOUNT_ID as your Id(), especially if that's what's used as a reference for other child tables. It won't affect your database structure, it's just a way to tell NHibernate what to use for a primary key during association fetching. If you use both GUID_ACCOUNT_ID and ACCOUNTID depending on the scenario, then you've probably got many other issues that you're going to run into down the road, this being one of the first that should raise the warning flag.
On Fri, Jun 19, 2009 at 11:46 AM, Allen Wilson <mookie75...@gmail.com>wrote: > > Thanks...I read through it again and I did see the PropertyRef > information you were referring to. Tried it and it still did not help > my issue...the way the tables are set up there is a one to many > relationshp...therefore i need the HasMany but without the field in > table A being the primary key I am not able to set the relationship up > correctly. And an additional hinder is if I used the Reference method > to get things correctly the portion of populating my test database > breaks..... > > So it has to be HasMany...and determine so way to specify which field > to in the parent table to use a key > > Thanks... > > > > > -- - Hudson http://www.bestguesstheory.com http://twitter.com/HudsonAkridge --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Fluent NHibernate" group. To post to this group, send email to fluent-nhibernate@googlegroups.com To unsubscribe from this group, send email to fluent-nhibernate+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/fluent-nhibernate?hl=en -~----------~----~----~----~------~----~------~--~---
