There's also the api implementation of md5. For larger strings (and files) this outperforms the vfp implementation

local obj

   if( !md5Bits_Object(@m.obj) )
     ? 'problem Version windows'
     return
   endif

   local Digest
   =m.obj.DigestString("message digest", @m.Digest)
   ?ath(m.Digest)
   && f96b697d7cb7938d525a2f31aaf161d0

   && OR
   =m.obj.Update("message ")
   =m.obj.Update("digest")
   =m.obj.Final(@m.Digest)
   ?ath(m.Digest)
   && f96b697d7cb7938d525a2f31aaf161d0

Program attached (zip)



>Just the relevant parts as SWAG to give you an idea :
>
>Select F1, F2, F3, F4, Sys(YouhavetoLookupTheNoAsIAmLazy, F5) as F5MemoGrp, Cast(Min(F5) as M) as MinMemo;
>from whatever;
>Group by 1,2,3,4,5;
>order by 1,2,3,4 ;
>into cursor blabla
>
>
>There is a MD5 implementation on Ed Leafe's site which has better performance - not sure which function has theoretically more overlap.
>Or you can combine both functions as in Sys(asAbove, F5) + MD5(F5) as F5MemoGrp - need perhaps to cast the results into Char-Types.
>
>The hash function transforms the memo into a groupable "distinctability" and Min is used to make sure SQL syntax is observed at vfp9 compatibility.
>Minimal danger of hash collisions can be combated either via different hash functions in series or scanning the table once for true identity at different Hash results - hashing is a multiedged tool which can cut you but just not realizing it is there leaves out one of the most potent tools available in programming.
>
>
>>How would this look klike in the given situation?
>>
>>TIA
>>Gerhard
>>
>>>>>
>>>>If the information in the memo is less than 254 characters, then you can use these 254 chars and use distinct. Otherwise there is no way without a primary key.
>>>
>>>Coming in late and realizing that in another thread you argued for the cleaner solution of a PK: "No Way" is simply not true. Hashing is typically used in such situations.