>>>>Hi Asif...thanks for your answer..
>>>>What are compressed character surrogate keys?
>>>
>>>Surrogate keys are Primary keys with no underlying meaning. They are especially usefull if you plan to use record-recycling in your database design. This means that you will never have to pack a table, the table will most often reach a terminal size, and the table will not require any periodic maintenance schemes.
>
>To get a compressed character representation of an integer you must first decide on a BASE that you want to work with. I work with base 249 - that is - 249 out of a possible 256 characters in the available character set. I take care to exclude characters such as single and double quotes since I want to be able to pass these strings as parameters. I exclude the '-' character since I want to be able to represent negative integers. I can't quite remember what I do with the other characters that I don't include in my base 249 character set - its been 4 years since I invented this contraption.
>
>Supposing for instance that I decide to use a consecutive set of 249 characters ( CHR(1) -> CHR(249) ) in my character set; A character string made up of CHR(12) + CHR(61) for instance would equal ASC(CHR(12)) * 249^1 + ASC(CHR(61)) * 249^0 = 12*249 + 61 = 3049.
>
>To reconstruct the above character string:
>
>3049/249 gives an integer result of 12 with a remainder of 61
>12/249 gives an integer result of 0 with a remainder of 12
>
>We take the CHR() of the remainders above in reverse order to get our base249 compressed character string : CHR(12) + CHR(61)
>
>>>
>>>>what are tables related via surrogate key?
>>>
>>>They are child tables with the surrogate key identifying records which have a relation to one record in the parent table. Whenever, a record in the parent table is marked for deletion, the child tables are also marked for deletion. When a new record has to be added, a Stored Procedure will first try to recycle a record marked for deletion without over-writing the surrogate key in the parent table. The surrogate key(s) in the child tables may be over-written as required.
>>>
>>>Keep in mind, that you may still need Primary or Candidate keys in your parent table which do have meaning.
>>>
>>>>I am new at writing programs for networks. I need to know how
>>>>to use data from a network drive in a way that gets the best performance.
>>>>Can you suggest ways I can learn? I thought VIEWS would be fast, since they
>>>>work in memory. thanks --rob
>>>
>>>To access data over a network, store the data path either in the PATH statement or in a table. If you choose to do the latter, then everytime you use a table, you must build a string on the fly with the path preceeding the table name. For example, if the CUSTOMERS table was on drive H:\123\DATA, you would call something like USE 'H:\123\DATA\customers' IN 0 SHARED
>>>
>>>The best way to learn is to experiment.
>>
>>
>>Hi Asif:
>>How do I learn about record-recycling in my database design? I like that idea
>>that I would never need to pack a table. thanks..rob
>
>Record recycling is really quite simple. Whenever you want to add a new record, first locate a deleted record. If one exists, lock and insert new values into it, then recall and unlock the record. If the record is in a parent table, you must be carefull not to over-write the surrogate key. The reason for this is that the surrogate key is assigned a unique value when a fresh record is created. Ofcourse, this value must have a limit. You must choose the max value for a surrogate key during your design phase. It must be sufficiently high so that there will always be enough deleted records available for recycling. You must create a test in your key generation routine to make sure that its value does not go over this value. If it does go over, do not allow the user to add more records. If no deleted records exist and the surrogate key is less than its maz allowed value, insert a new record and assign it new values together with the unique surrogate key.
>
>You can use record recycling techniques in child tables also. However, in this case it does not matter if you over-write a surrogate key.
>
>You must keep track of your surrogate keys in a separate table. This way you don't have to check if a generated key is unique. To be absolutely safe though, make the surrogate key in the parent table a primary or candidate key. If a uniquness error is generated on a surrogate key, don't allow an insert.
>
>VFP3 CODEBOOK uses a similar scheme - I believe they use base 62 with compressed strings that are at most 5 characters in length..
>
>Check out the May 97 FoxPro Advisor magazine article: Real Programers Use Integers - by Malcolm Rubel. He is a lot more eloquent than I. The article is about using integer surrogate keys to increase query speed.

Hi Asif...Thanks for answering and for the information... rob