4D's UUIDs function as globally unique row *serial numbers*. That's great for backups and convenient for physical relations, but it has exactly zero to do with a real "primary key" or relational integrity. I would have preferred to see UUIDs implemented as a virtual field:
[Customer].UUID() or Get record UUID ([Customer]) ...and let 4D manage them internally, automatically, and invisibly. But that's not how it worked out. Yeah, UUIDs are impossible to type and I'm still not 100% clear on how you search for empty ones. I've seen the tech tips etc., and still get some really eerie weird results at times. In my own code, I tend to run verification methods that check for real (logical) keys. Namely, the field or combination of fields that uniquely identifies the *data* in the row. A UUID-as-physical-key very easily masks duplicate rows because it is, by definition, unique. You row might be unique, but your data might not be, if you know what I'm saying. Anyway, I tend to scan for duplicate data, orphan records (a child record that *requires* a parent and doesn't have one is an orphan. Not all child records require parents, but 4D's diagrams, etc. don't distinguish between the two.) Oh, an widows. Mostly, I find lurking duplicates and orphans. Widows? Not so often. Not sure if that's just me. In theory, none of these things should ever happen. But then again, a whole lot of things work out better in theory... ********************************************************************** 4D Internet Users Group (4D iNUG) FAQ: http://lists.4d.com/faqnug.html Archive: http://lists.4d.com/archives.html Options: http://lists.4d.com/mailman/options/4d_tech Unsub: mailto:4d_tech-unsubscr...@lists.4d.com **********************************************************************
