DevForce supports the use of composite keys, and we have many customers who use this strategy.  Furthermore, we never (or at least almost never) tell our customers that they need to redesign their database.

For our own work, we prefer single-part keys (when we have the option of choosing the key type) --  simply because they are more convenient to work with than composite keys. For that matter, we also prefer “artificial” keys – those with no meaningful connection to the other information in their record.  That avoids many problems that occur when factors external to the database force that other information to change.

To make your code work with a composite key, you would simply add additional clauses to the query to specify the value of the remaining column(s) that participate in the key.  For example, immediately following the statement where you instantiate the query, and before using that query in the GetEntity() method call, you could add a statement like the following:

      empQ.AddClause(Employee.IdPart2EntityColumn, EntityQueryOp.EQ, idPart2);

The Developers Guide says:

“Most of the time an object’s key consists of a single identifier and so the words “key” and “identifier” are used interchangeably. Multipart keys are possible and sometimes necessary but we prefer single part keys.”

How do you accommodate those in DevForce?  For example, how would you do the equivalent of the following for Employee object with a composite key?

[DataObjectMethod(DataObjectMethodType.Select)]

    public BindableList<Employee> GetSelectedEmployee(string sort, Int64 id) {

      EntityQuery empQ = new EntityQuery(typeof(Employee), Employee.IdEntityColumn, EntityQueryOp.EQ, id);

      Employee emp = this.PersistenceManager.GetEntity<Employee>(empQ);

      BindableList<Employee> blist = new BindableList<Employee>();

      blist.Add(emp);

      CreateEmployeeBitMap(emp);

      return blist;

    }

Also, why do your prefer single-part keys?