[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference ulysse::rdb_vms_competition

Title:	DEC Rdb against the World

Moderator:	HERON::GODFRIND

Created:	Fri Jun 12 1987
Last Modified:	Thu Feb 23 1995
Last Successful Update:	Fri Jun 06 1997
Number of topics:	1348
Total number of notes:	5438

199.0. "Oracle and All-in-1" by DEBIT::DREYFUS () Wed Sep 21 1988 23:52

Oracle has recently announced a product that integrates their DBMS and
All-in-1.

Has anyone run into this product?  Does it work well?  What does it cost?

I have been told that an All-in-1 user who wants access to an Oracle
DBMS requires three VMS processes (so a MicroVAX 3600 can support only 6 users).

	1 process for All-in-1 (per user)
	1 process for Oracle (per user)
	1 process that connects the two.

Rdb has All-in-1 connection capability through TEAMDATA.  This approach should
support more users since only two processes are required.

	1 process for All-in-1 (per user)
	1 process for TEAMDATA & Rdb (per user)

T.R Title User Personal
Name Date Lines

199.1 U can do that already. TRCO01::BROWN Ian Brown @TRC 9/5 637-3339 Thu Sep 22 1988 01:43 22

T.R	Title	User	Personal Name	Date	Lines
199.1	U can do that already.	TRCO01::BROWN	Ian Brown @TRC 9/5 637-3339	`Thu Sep 22 1988 01:43`	22
	Don't know of a specific product... integration using 3 processes is not very tight. Currently, a customer can do this himself as described below. We "integrated" ALL-IN-1 and Oracle SQLForms on a project here in Toronto. It used the ALL-IN-1 sub-process to set job-level logicals to communicate with another (3rd) user process running SQLForms. The processes simply attached back and forth. The sub-process code was eventually written as an ALL-IN-1 SDF (Site Defined Function) and linked in with ALL-IN-1 reducing the process count to 2 per user. The issue was more to do with ergonomics; FMS forms with command stacking work quite differently from SQLForms, (and more!). Beware! Demand that Oracle's forms look and feel as much like ALL-IN-1 as possible right from the start. It would also be possible, using the ORACLE PRO precompilers, to write modules that could be linked directly into ALL-IN-1, which could access the database using scripts as the intermediary and thereby only use 1 process per user. -ian

  Don't know of a specific product... integration using 3 processes
  is not very tight. Currently, a customer can do this himself as described
  below.
  
  We "integrated" ALL-IN-1 and Oracle SQL*Forms on a project here in
  Toronto.  It used the ALL-IN-1 sub-process to set job-level logicals to
  communicate with another (3rd) user process running SQL*Forms. The
  processes simply attached back and forth.  The sub-process code was
  eventually written as an ALL-IN-1 SDF (Site Defined Function) and
  linked in with ALL-IN-1 reducing the process count to 2 per user.
  
  The issue was more to do with ergonomics; FMS forms with command stacking
  work quite differently from SQL*Forms, (and more!).  Beware!  Demand that
  Oracle's forms look and feel as much like ALL-IN-1 as possible right
  from the start.
  
  It would also be possible, using the ORACLE PRO* precompilers, to
  write modules that could be linked directly into ALL-IN-1, which could
  access the database using scripts as the intermediary and thereby
  only use 1 process per user.
  
-ian