>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...
>
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?
>
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?

>If the String PK/FK approach is really ugly and just a BAD idea,
non-generated/non-artificial PK's are a bad idea IMHO. You heard some opinion on I and GUID,
here's my take: it should not matter that much.
As long as you stay traditional vfp table,
Int should give you slightly more space for the rest of the record on tables crowding 2GB
and better speed across slow LAN, but perf should not rule out GUID.

On true servers GUID have even less points against them and are the better choice there IMHO
(or at least 8 byte LongLong so not to worry for the next dozen years) and that brings me to the next point:

>The issue is that BO tool under consideration requires Integer PKs,
I'd be weary if a tool forces you to "my way or the highway"
in areas which can clearly be argued both ways and where there might be end customer decision -
sooner or later you wish for the highway and you have invested too many manH.
But I'd contact the tool dev - perhaps GUID's are not totally ruled out.

my 0.02 EUR

thomas