Cool VFP stuff – Field repositories (by John Koziol)

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.

Comments (3)

  1. This is much the same as SQL Server’s user-defined types, correct?

    <PRE>USE model

    EXEC sp_addtype ssn, ‘VARCHAR(11)’, ‘NOT NULL'</PRE>

  2. Bob Archer says:


    Yes and no. With SQL UDT once you use it, you can’t change it. So the ‘all are the same’ is there, but the ‘change it in one place and the change is propogated’ is not in SQL. It would be nice if SQL worked that way though.


  3. andrew says:

    John- what are the products?

    there is no shame in naming names on a blog.