Re: How will I adapt from Pick to Oracle?

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 Wed Mar 28 2001 - 12:05:35 CST