Hi Roxanne,

>Its a weird problem to understand. I dont really have a problem creating surrogate primary keys, thats actually the majority of the Pre-processing work my System has to perform. My real problem is that I have no control over data input, we use a Unix Software/hardware Service provider to perform all transaction processing, billing, initial data entry, etc. My System has to take the data we get out of these Unix Systems as-is... meaning I have to deal with the table structures and business rules of a System I do not support. No big deal you would think, except that we have 7 independent Unix Systems that supply the data for One Warehouse System (my apps). So each of my Source Tables takes in data from 7 independent sources. And the primary keys used in each of these 7 systems are only unique to that one System, plus the field values (like Account Number, Serial Number, etc.) are not standard lengths. Plus 4 of the 7 Systems gets broken down into 2 or 3 subsystems based on a
>Store Number field.
>
>So what happens to me is I feed all this data into my system, and to uniquely identify one Account, I have to Join on Account Number with a double equal sign condition, plus a code for which of the 7 Unix Systems that the data came from, plus a Store Number. I've looked at creating my own interger primary keys, but the overhead is tremendous because my Data Warehouse does no permanent storage. All this data I'm feeding in work on a Purge-and-Dump basis... I purge out the old data either daily/weekly/bi-weekly/monthly, Dump in the new data, and then run all my processing. I dont have any good way to get incremental data from these Unix boxes so therefore I do alot of repetitive processing. Then to make matters worse, the Unix System is truly a RDBMS and the fields I need for reporting purposes is usually spread across 2 or 3 tables minimum. Its not pretty but resuls in perpetual job security for me :D)
>
Once again were are reaching a level where email is not the best medium for this type of discussion. I get the impression you understand the problem well enough to have attempted any obvious solution I could come up with. And in this day and age maybe perpetual job security is more valuable than a brilliant solution :-))

>>Cool Event Objects??? Why haven't I been informed of this. What are they, where do I dind out more ?
>>
>I'm just diving into understanding these Event Object myself, so I cant be alot of help here... See Kevin McNeish's thread under the category "Third Party Products - Mere Mortals Framework" from about a month ago.

Ok, Thanks.

>Thats fine, I would really only have a use for it when doing importing. Can you tell me where I can go for more info on this? My research and design hasn't gotten me to the point yet where I'm looking into ODBC drivers, but I would really like to know more about how this works and do some pre-development testing with it.

Errr. Trial and error. I don't even remember finding any docs on the OBDC driver. I just played with the ODBC driver manger. Created a data source based on the text driver which is automatically installed. Then if you kick it around enough you can get the define format button at the bottom of the driver screen to enable and that screen allows you to setup the fields widths and the field names.

I'll try and do it again so that I can be a bit more specific.

Darrel