Re: How will I adapt from Pick to Oracle?

I worked in the Pick environment for years and years. Good data design and understanding of how to relate data, and tables is a good skill. It is the number 1 skill you can learn, and it is transferable to sql, or other environments. My exposure to Pick did help me much in this regard. So, while SQL and the pick's Access/recall query language are different, having used a query language did help me a lot in my transition to from Access/recall to SQL. Many concepts do transfer from one system to another.

In fact, of all the many programming languages/environments I have learned, SQL seems to be the only one that I have kept. I started using SQL in FoxPro about 10 years ago. The addition of SQL to Foxpro was great leap forward. Having worked with Pick really did help me on the data side when I migrated to FoxPro. I still use SQL today (I always used a query builder, so I can't really say that I know the sql syntax that well, but sql certainly is my friend now). SQL is the universal means by which we access data in the non MV world (both desktop, and the web). I should add that my MV designs generally map quite well to a sql environment. So, your classic invoice in Pick, becomes a parent and child table of detail in sql. This conceptual mapping of tables comes quite easy when jumping to a new non mv environment .

I am currently re-writing a application in Pick to sql/VBA/ms-Access.....it is
a most fascinating change, and the parts that are creating difficulty are not
what I expected at all!.

So, from a data structure point of view, the change from Pick to a sql relational model is a easy change. At least it was for me. In my new table designs, their is little difference from Pick to the equivalent sql tables (expect that sql model has at least twice as many tables!). Of course I use a ER diagramming tool (Visio 2000) to cope with the increased number of tables, and relationships. This "map" of tables greatly aids me now that the coding part has started. If I ever do another large Pick project, I will certainly use something Like Visio 2000. In fact, I would love to do a Omnis project with pick.

While the table stuff was actually easy, you better be prepared for a drop in productivity. Simple little code routines that grab a record and do something to it can be a real pain in these new languages. There are lot of reasons why this is so, but what was a simple single read in pick code (say a invoice) becomes a real disco dance complete with spiked punch in sql, and vb. What was one record, now becomes 3 tables, and two of them are multi-records. YOU have to work out this relation stuff when doing updates. The sql engine might enforce RI for you, but that just stops your code from doing something wrong!

So, the big difference between Pick, and other systems comes in the area of coding, and how you get at the data from a program point of view (here is where implementation of business rules etc really starts to change). There is also the issue of event driving programming etc. I have never used the Oracle developer tools, but I suspect that they will result in a productivity
drop when compared to pick.

Right now, most VBA developers using ms-access are about 2x as productive as using VB to develop the same business application. And from them, I have heard that
Oracle takes even more time.

So, it is not the relational model that will kill you in the change...it is the programming
environment.

I am actually still looking for that great development platform somewhere out there.You, know...Omnus is starting to look like it would be the best choice! The reviews I have read about this product impress me much. It is a rad tool, and totally object driven. Anyone want to hire me for a Omnus project?...I will work the first month for 1/2 price!

--
Albert D. Kallal
Edmonton, Alberta Canada
kallal_at_msn.com