>I'm considering a certain Business Object tool that I've been reviewing, but I may have a potential problem with my existing data tables as far as the PK/FK matter between my Parent tables and the related Child tables...
>
>The issue is that BO tool under consideration requires Integer PKs, and many of my tables use String PK on the parent and String FK on the child records pointing back to the parent. For instance, on my Job parent table, a typical JobNo string PK might be "UR-56342A" or "4033X-01", "4033X-02" etc., and the child JobItems table records will have a String FK JobNo field also that contains the same value. Although there is an AutoInc integer (ipkey) assigned to each parent record, I generally navigate the forms and map the children by way of the string JobNo field. It would be easy to add and ifkey field to the child tables and update it to match the parent ipkey. However, I must allow the users to enter the String value, and then I'll have to do an intermeditate lookup to get the real ipkey value. Is this a common scenario?
>
>If the String PK/FK approach is really ugly and just a BAD idea, I could use this as an opportunity to refactor over to an Integer based approach. I believe I can still use this tool and work around the matter with some reasonable coding, since my current home-grown BO handles this already, and I have seen the source code, and I believe I can make the necessary adjustments and move right along. The question is... should I change my data PK/FK approach for a long term benefit, or make the necessary mods to the BO classes to handle the Strings?

Others have probably already said this but you really should have a non-meaningful PK, for which Integer is fine. (Except for huge tables where you might need a GUID, which is a slight performance hit). That way you don't have to worry about uniqueness at all. Set it to be an autoincrementing field and forget about it.