Documentation of the original Pick Application

Pick is a extremely flexible environment from both a programming *and* data structure point of view. The data structures and the software that manipulates the data comprises the "application". In a good number of Pick systems the application is it's self the design document. While this is fine for a experienced Pick developer, it offers little help to a experienced VB developer.

I have seen a lot of Pick software that has no design document of any type. Simple tools such as ER editors in the Pick world is only now starting to be used. Since many Pick systems are more than 10 years old it should not be a surprise. However, to start a conversion, a design document is needed.

Considerable effort will be required to "map" out the existing table structures and relationships.

You have two choices here.

  1. Carefully map out the table structures and relationships of the Pick application. Then "re-map" these table structures and designs to a non MV data model (read: SQL relational model). You need a good understanding of Pick to do this.

  2. Simply write out the requirements of the original system, and use those requirements as the master design document. (i.e.: don't use the tables as a design document at all. Write a new specification from scratch)

#1 is my preference *IF* the original product has a good design. This is important since a program with rotten code and a *good* data design is FAR superior to super code, and horrible table design. You must get table design correct for a good application. Ask any good programmer what they need to know about a application. The answer will be "show me the data".

With a good data design, the application practically writes it self.

In addition, the work in option #1 is required if data is to be transferred from the old system to the new. Hence if RELATIONAL data is to be transferred from Pick, then the structures of existing data needs to be known. I emphasized the word relational here. It is not a big deal to transfer a client file. However, if we are to transfer a client file *and* past "invoices" (with detail), then we have re-structuring and re-formation of our data model. This can be quite bit of work. One has to ask how important is the need is to transfer data, and how "relational"  is that data. The more relational the data, the more work required to transfer.