Conference ulysse::rdb_vms_competition

438.0. "Oracle -> Rdb conversion tools, how are these ?" by TYFYS::MUNNS () Wed Sep 27 1989 20:40

    I work in the Center for Migration Services in Colorado Springs. 
    Having just returned from a visit to a small California company by the
    name of Trifox, let me tell you what I discovered.
    
    Trifox developed Oracle's SQL*QMX which gives forms and report 
    interfaces to Oracle databases.  Now they have developed
    some Oracle -> Rdb conversion tools.  Actually these tools will allow
    conversions between Rdb, Oracle, Sybase, Nucleus, and DB2.
    
    I had the chance to see these tools.  I would like to briefly describe 
    what these tools do.  I am looking for feedback from you: is this 
    functionality sufficient for getting customers off of Oracle and
    onto Rdb ?
    
    Keep in mind that these tools require only the Rdb run-time license
    and VMS.
    
    Trifox has a data unload utility that takes data out of an Oracle
    database and stores it in a file.  They have a data load utility that
    loads Rdb.  If the user wanted to disable field and table constraints
    during the load process, this would have to be done manually, then the
    constraints would have to be reapplied.  
    
    My question: how different is an Oracle schema definition from an Rdb 
    definition (can Oracle's schema be directly used by Rdb or is some 
    type of conversion in order) ?
    
    Another tool is called TRIM/APP which translated SQLFORMS applications
    from Oracle into a neutral form specification.  This neutral form can
    access data from Rdb (or from other supported databases).  The secret 
    for doing this trick is to isolate all database or operating system 
    specific code in "control block" modules, the unchangeable main code
    uses these control blocks to access the target hardware/software.  When
    Trifox wants to support another target system, it just creates control
    blocks.  No porting nightmares like Oracle faces. Real smart.
    
    TRIM/REPORT translates Oracle reports (generated from SQL*QMX) to a
    neutral report specification.  This neutral specification can generate
    reports from Rdb data.
    
    TRIM/DICTIONARY is a data dictionary that stores data descriptions and
    trigger information.  By the way, Oracle's poor implementation of
    triggers which results in awful performance is solved in the Trifox
    implementation of triggers.  Also, the dummy table DUAL is no longer
    needed !
    
    Is this functionality sufficient for handling any Oracle -> Rdb
    conversion requests that you have encountered ?  I am not familiar with
    what Oracle customers do to meet their database application needs.  For
    instance, is SQL*QMX the tool of choice for developing applications ?
    Are 3rd & 4th GL tools used (how much) ?
    
    -Dave.
                                           

    Ok, what's the poop here. I have a copy of .0 pulled off the conference
    by my trusty AVN and just came in to add my 2 cents worth.
    
    Who can I talk to about the company an tools mentioned in .0

    Note 417, has a little more scoop!  You might want to contact Chuck
    Stata.  If there is interest in these tools, Phil Cudia needs to be
    told.  Chuck keeps running into "why do we need these type of tools"
    and  RIB people need to understand why ORACLE is simply a virus on a
    VAX system.
    
    
    

    My name is Jan Aronson, and I work in Sweden with VIA support. 
    I worked for Trifox in Sunnyvale, CA during 1987. I was involved
    in the development of SQL*QMX (porting yo VMS and a lot of testing).
    
    I have talked to them "over there"" and know about the discussions
    that you have had. 
    
    SQL*QMX is not an application generator. For that Oracle users use
    SQl*Forms, which is a lot like ours Rally. 
    
    					
    							Jan