Conference ulysse::rdb_vms_competition

    The only DB_Vista I know of used to be a PC "database". It was written
    in C, so would probably be quite portable. It was really a file
    management system that made mutiple ISAMs appear to be a relational
    database. It could well have migrated up to the VAX market by now.
                      
    They used to advertise frequently in PC Magazine and others of that
    nature.
    
    ---- Michael Booth 

    I appriciate your information on DBVISTA!
    I guess my other question is that I'm not quite comfortable with
    the term IN-MEMORY database systems and this is how DBVISTA is
    implemeted. Can you define that for me? and looking for a VAX/VMS
    alternative I'm recommending VAX Rdb at this time since they are
    looking for a SQL based front end and few other criteria that the
    customer had!
    
    Thanks,
    Ali

    DB_VISTA is, as Michael said, a DBMS that has migrated up from the PC
    world to Unix and VMS.  They are based here in Bellevue, WA. Also, they
    claim to be a pointer-based (e.g., CODASYL) approach.  Their ads seem
    to stress performance. 
    
    They have been reasonably successful in the PC and Unix space but have
    never done well on VMS.  My guess is that it's because the VMS Database
    niche is very competitive.  They also don't supply any end-user or 4GL
    "tools", which I think is a problem is VMS-land.  They position
    themselves as a "developer's" database. 
    
    I don't think they would be competitive with Rdb - what is your
    customer looking for that Rdb doesn't provide?
    
    	Al

    Actually I am not counting out Rdb by any means, specially since
    the customer has asked for the distributed database capabilities,
    SQL interface, decision support tools and 4GL environment, I'll
    be hard pressed not to go with our own VAX/Rdb. However there are
    two other things that I sort of unsure, first the customer has a
    lot of PCs (IBM, Compaq) that they like to utilize as their frond-end
    to a VAX based back-end at least initially since they utilize
    tremendous amount of graphics, imaging and windowing. I am not clear
    how we(digital) handle PC-VAX database applications since we don't
    offer PC database product, any suggestion please?? Is VAX XWAY going
    to be any help? maybe a third party product on top of VAX/Rdb?
    Second (less important) since DB_VISTA being a CODASYL product,
    going to a relational (Rdb), there will be some performance trade
    off! wouldn't it? Also can you give a pointer to any DB_VISTA
    information in this notes file?
    
    Many thanks,
    Ali

Rdb/VMS already outperforms CODASYL systems for many kinds of
applications, and the next version will eliminate most of the remaining
cases.  So, I wouldn't worry too much about performance.

For PC connectivity there are a number of choices.  First of all, one
could use TEAMDATA on a VAX in conjunction with XWAY to extract data
from an Rdb/VMS database into a format usable by LOTUS, DBASE III, etc.
Then the PC could access the data via the MSDOS Services.

If there are users who never want to directly log on to the VAX, a
company called Network Innovations (now an Apple Subsidiary) markets a
product for MSDOS called Multiplex that can pull data from VAX Rdb/VMS
databases into whatever format you want on the PC.

There are other potential 3rd party solutions as well, and you can
expect more from DEC in the future.

    re .5
              
    I would really appreciate some more info on the MULTIPLEX product
    mentionned; especially in the way it interfaces with the VAX (using
    DECNET/DOS, VMS Services for MS/DOS or other means ?)
    
    Tks

    
    re .5
    
    If I got it right the way to use RALLY and XWAY means:
    - login to a VAX as a interactive user
    - make to db extract and put it out into a RMS file (eg WKS)
    - run the XWAY interactively or run a application (customer written)
      to convert the file
    - logout
    - got out and use your PC
    
    I'd say that the need to have an interactive session to the VAX
    invalidates the whole idea.
    
    One could create a program that extracts RDB contents (eg DTR+RDO+
    Cobol or SQL+Cobol) and writes it in a format that can be described
    to XWAY. And XWAY, used by it's callable interface, writes the file
    straight into the virtual disk. Here you would not need the interactive
    session into a VAX. But it sounds complicated, eh?
    
    I've been involved with a PC application that sends out SQL requests
    (queries, updates etc). The VAX SQL interpretes these strings with
    it's 'dynamic interface' routines. A nice idea but you must create
    the comms protocol, the SQL interface and the PC application.
    
    There's a product called EXEL (spread sheets) that can access a
    local or a remote VAX RDB database. As far as I know it uses SQL.
    Maybe DECnet also. When would we have such functionalities?

    
    -- Olli