By Daniel Essin - 12/14/2005
I have a 2 database tables defined as in erd.jpg. In the mapper (see jpg's) each table has only one field flagged with the key icon. I am confused.
|
By Daniel Essin - 12/14/2005
Also, if the relationships are not captured in the mapper, what keeps the apps in sync with the way the constraints are defined in the database?
|
By StrataFrame Team - 12/14/2005
StrataFrame is only plumbed to handle single-part primary keys. So, when you define the table in the database, and the Business Object Mapper checks the sysobjects table for the primary key, it will only pull the first column defined in the primary key. A great deal of functionality in StrataFrame would become infinitely more complex with complex primary keys (SeekToPrimaryKey, NavigateByPrimaryKey, parent-child relationships, etc.) A large portion of the latest update was aimed at abstracting the data access to facilitate easier changes and allow a StrataFrame developer to write their own data access, so StrataFrame could certainly be designed to support it.
|
By StrataFrame Team - 12/15/2005
I think your best bet is to add an ID column to your table as an integer or guid type. Set the primary key on it, and let it be a the index. Then, define a UNIQUE constraint on your combination of 3 columns. The INSERTs, UPDATEs and DELETEs will be faster with the single part primary key and you will still have the UNIQUE constraint on the current 3-part primary key setup.
|
By Daniel Essin - 12/15/2005
I can do that. Most of my tables use a string guid as the key. There are only a few that have multi-part keys. Converting them will not be too big a deal.
Thanks.
|
By StrataFrame Team - 12/15/2005
Not a problem 
|
By StrataFrame Team - 12/15/2005
When you configure your tables with a guid primary key, are you using a Char(32) data type and putting the guid in that, or are you using the UNIQUEIDENTIFIER data type and storing the guids there? Because if you're using the Char(32) type, you might consider changing them to the UNIQUEIDENTIFIER because it's half the size and optimized for guids. Also your field properties on the business objects would return a System.Guid rather than a string. Just a thought.
|