I have an existing DB2 database I have to work with, they have many tables where the "key" is the combination of one or more fields. How can I accommodate this design using SF?



The BO mapper lets me define multiple fields as primary keys via "Override Primary Key Specification", it then shows them as FIELD1,FIELD2. It is going to use the concatenation of these two fields as the primary key?



If not I should just be able to control the assignment of the two key fields manually right? Its more work but I did it before as a work around before I got my auto incrementing key fields working.



Thanks.

Keith Chisarik

Also having problems with field names that have the # sign in them (FIELDNAME#), how might I fix that?



Project wont compile after partials are rebuilt due to these errors (too many to list).



Here is an example of one error:



Bracket identifier is missing closing ']' for:



'''

''' MNXSTYL#

'''

'''


BusinessFieldDisplayInEditor(), _

Description("MNXSTYL#"), _

DesignerSerializationVisibility(DesignerSerializationVisibility.Hidden)> _

Public Property [MNXSTYL#]() As System.Decimal

Get

Return CType(Me.CurrentRow.Item("MNXSTYL#"), System.Decimal)

End Get

Set(ByVal value As System.Decimal)

Me.CurrentRow.Item("MNXSTYL#") = value

End Set

End Property




Keith Chisarik

I got things to work by manually removing the # sign from the field names in the designer file of the BO for the properties, enums, and descriptor classes, the field names are enclosed in quotes when referencing the data tables so it seems OK so far, but my concerns are:



1) anything I'm not seeing here that will break

2) Every time I rebuild a partial for a BO with a field that has an "#" in the name i will have to manually change the designer code in each = yuck. Any way to alias the field names in the mapper or another technique to get me out of the soup?

Keith Chisarik

On your first question, yes, the two fields are considered part of the PK.  Any time the record is uniquely referenced, both fields are included in the where clause, just like a compound primary key in SQL Server.

As for the second problem (the # signs)... I cannot think of a way to make it work off the top of my head.  If you manually remove the # signs, then you might have problems binding to those fields because the property descriptor is going to be looking for a different field name.  As far as I know, I cannot think of any compiled language that allows you to place # signs in the variable identifiers.  So, if you change the name completely within the business object, then it won't be able to reference the field correctly through INSERTs and UPDATEs, but if you leave it alone, then it won't be able to correctly compile in .NET.

I think the recommended workaround would probably be to create a view for the table and alias the names differently.  You could then build the business object from the view and the business object would no longer think there are # signs in the identifiers.  This option would require that the view be the DB2 equivalent of a SQL Server indexed view (to be updatable).  If the view cannot be indexed, then you would need to create sprocs for the INSERTs, UPDATEs and DELETEs. 

The updateable view using aliases for the "bad" field names worked, thank you.

Keith Chisarik