On 2016-04-15 15:28, Ted Roche wrote:
On Fri, Apr 15, 2016 at 2:57 PM, Gene Wirchenko genew@telus.net wrote:
Of course, if you were to create GUIDs, the universe would likely end first.
GUIDs are not that bad, are they?Oh, indeed they are! The Entropy Heat Death of the Universe is not far behind the exhaustion of the GUID space. Perhaps they should be considered a Fifth Horseman of the Apocalypse.
Just to reiterate, I was only thinking about going back to INTs for the size and efficiency. For large tables, I'm told by the corporate gig boss that GUID keys don't do as well and I was just thinking more could be held in memory with integer keys.
At least I'm glad I chose the 16-byte GUID instead of the alternatives:
FUNCTION CreateKey(tiLevel as Integer) as String * Returns newly created GUID using class from VFP2C32. LOCAL lcKey as String * 0 = ansi human readable (38 wide) * 1 = unicode (76 wide) * 2 = binary (16 wide) IF VARTYPE(tiLevel) <> "N" THEN tiLevel = this.iDefaultKeyLevel ENDIF IF NOT ("vfp2c32.fll" $ SET("Library")) THEN && mjb 04-16-14 minor tweak. Happy birthday, Bob! :-) SET LIBRARY TO vfp2c32.fll && mjb 05-17-14 took out LOCFILE ENDIF lcKey = CreateGUID(tiLevel) IF NOT this.ValidKey(lcKey) THEN && try again..don't like those as it caused issue with cboJobType this.TrackBadKey(lcKey) lcKey = this.CreateKey(tiLevel) ENDIF RETURN lcKey ENDFUNC && CreateKey(tiLevel as Integer) as String