Re: Pick to Oracle conversion

In article <39h171$rf2_at_ixnews1.ix.netcom.com>

           chuckh_at_ix.netcom.com "Chuck Hamilton" writes:

> I'm interested in hearing any stories of users that have converted
> corporate databases from Pick (or any of the Pick-like DBMSs) to Oracle.
> How did the performance of Oracle compare to Pick in speed, disk
> requirements, system administration, application development time,etc.
>
> TIA.
>
> ========================================================================
> Chuck Hamilton <><
> work: 73361.3356_at_compuserve.com
> play: chuckh_at_ix.netcom.com
> ========================================================================

Hello Chuck!

I don't know anybody who has done so without a complete redesign of the application because typically the Pick application is a decade old and any business changes in that time.

Certainly you have to know a lot more things to be able to run Oracle. But I find that a _good_ Pick techie makes a good Oracle techie. Eventually. But Pick techies can be intransigent. They convinced themselves of Pick's superiority when Pick was the best so they don't _want_ to move to Oracle.

Essential to good performance is good design of the database. The on the fly changes to database structure you have been familiar with in the Pick world are a little more difficult with Oracle. Although adding an extra column to a table is never a problem this cannot be done except DELIBERATELY. And with Oracle you can choose to index columns or to remove an index without changing the application code or halting the application.

Disk requirements are higher. Without the building of indexes I would guess that you will need 25% more disk space if your Pick files are correctly sized. Indexes add to that. And you will need indexes.

System admin? Are you moving from a native Pick machine or from UniVerse/Unidata? Because Unix system admin is _different_ and more complicated. And someone will have to adopt a database admin role.

But for all the added complication the benefits are many. The clincher for me is data and database integrity. Proper transaction boundaries means that any _data_ integrity problems are only caused by bugs in application code. I have been lucky enough never to see a loss of Oracle _database_ integrity. Both I suffered from under Pick (native and UniVerse).

Speed of development. With Oracle you can code up your own front end in C using the Pro*C precompiler or the OCI library calls. But, unlike Pick, writing your own front-end screen programs is very unusual in Oracle. A number of vendors provide tools for building user input & enquiry screens and reports. I have only used Oracle's and would say that Oracle SQL*Forms development is much quicker than coding in Pick Basic and nearly as quick as System Builder. Forms results in much flashier and easier to use apps than either, typically. SQL*Reportwriter is a much better report writer than any I have seen in the Pick world. It is quick to develop in too.

-- 
Paul Beardsell                          SAM Business Systems Ltd
~~~~~~~~~~~~~~                          21 Finn House, Bevenden St,
pbeardsell_at_cix.compulink.co.uk          London, N1-6BN, UK.
psb_at_sambusys.demon.co.uk                (+44 or 0)71 608-2391