For a project at work, I recently downloaded and was messing around with a third-party tool. While this is not a review, I wanted to comment on the field repository concept. A field repository is kind of like domains in other databases or parent classes in OOP terms. You can create and maintain a repository of fields with attributes that are maintained by linking table fields with the repository fields. Any change in the repository get implemented in tables using the shared fields.
This can be really useful in situations where you have a large number of tables in a database and a large number of common fields amongst those tables. For example LastName is probably used in virtually every table that tracks people. If you’re designing the tables by hand, you might make the field C(30) in one table, C(35) in another, or use the fieldname LName in another. This can make coding applications around the data a PITA as there’s no standard.
Using a field repository, though, LastName C(30) would be a shared, common field and guarantees the attributes are exactly the same from table to table. So, as I said before, you gain in your data some of the RAD pros you get from using object parent classes. Kind of a data structural inheritance.
Several VFP tools, commercial and public domain, incorporate this concept under a variety of names. Cool concept.