Re: How will I adapt from Pick to Oracle?

While I was working around Pick's we either had sole Pick OS and developments done in compiled Basic no cross-platform connectivitiy. We did some convertions from EBCIDIC to Pick data and vice-versa. Oh well, I may be able to make easily transition then to Oracle or even MySQL. To my surprise I just learned at least two Linux boxes running in my work site running MySQL I thought we only have Oracle and M$ SQL.

ysi wrote:

> Yes, I use both of D3 NT server and Oracle(Oracle server and Oracle
> developer 2000). I would like to clear somethings.
>
> 1) Pick and Oracle are different things. Pick system, like D3 NT server, is
> an integration of operation system, programming language and database. While
> Oracle server is a database server (may be a web server too). You can use D3
> server to create the whole application but you only use Oracle to create
> your "back end" of your client/server application. You need to create a
> visual presentation as the "front end" with a programming language like VB,
> Java or C++ ... etc. When you use D3 as a back end you have to face database
> accessing problem because the D3 data file is created under Pick operating
> system and Pick Basic language. D3 ODBC supposes to explor D3 Data to other
> Windows/Unix applications but not all kinds of D3 files can be converted
> into D3 SQl tables. VB D3 library allows VB to access D3 data but it is too
> slow and with a bounch of complicated extra syntex. While Oracle data can be
> easily reached by VB, J++, Visual C++ and Java. Actually, if a programming
> language can use (windows)Oracle Driver, it can access Oracle database. In
> one word, cuurently D3 is not good enough to be a back end database of a
> client/server architecture.
>
> 2) VBA, VB application and Oracle are different things too. When you work
> with MS Access, use VBA inside Access is more convenient than use VB. That
> is true. But in many cases VBA/Access is not the right choice. For instance,
> huge number of concurrent users, N tier ActiveX Server architecture and
> heave data transaction. VBA/Access does not work at all and that is why VB,
> java, Oracle and SQL server are required for. By the way, Oracle developer
> 2000 or design 2000 do the similar job as VBA/Access does and may have a
> higher efficiency and better performance.
>
> 3) Any logical design experience will help you to learn new software but not
> the syntex.
>
> YS
>
> Jimmy Navarro <bc984_at_lafn.org> wrote in message
> news:3AC16DFB.E0A44455_at_lafn.org...
> > At least someone else does use both Pick and Oracle.
> >
> > Albert Kallal wrote:
> >
> > > 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
> >
Received on Fri Mar 30 2001 - 18:59:30 CST