Conference ilbbak::ibi_focus

346.0. "Rdb db and FOCUS - several segments" by ISLNDS::RYAN () Tue Jun 12 1990 13:25

    HELP!!
    
    I have read all of the former notes about the Rdb/FOCUS interface.
    Sorry to start another topic about it, but I am stumped.
    
    I am trying to report off of an RDB database which contains three
    relations.  Using SQL or RDO queries, it works great.  When I try
    to layer on a .MAS file to it, I can only report off of one segment
    at a time.  I got error messages about declaring keys for the .MAS
    segments.  My Rdb database does not contain any.  I have included my 
    command stream which sets up the RDB database in RDO, the .ACX access 
    file, and the .MAS masterfile description.  Is there something special
    I have to declare about the segments so they will acknowledge each
    other?
    
    ANY help is greatly appreciated!
    
    thanks in advance,
    Katie


$ RDO
DEFINE DATABASE 'DISK$ALLIN1:[RYAN.TEST_AREA]AIDE_RDO' .
INVOKE DATABASE PATHNAME 'CDD$TOP.DTR$USERS.RYAN.AIDE_RDO' 
DEFINE FIELD USERNAME
DATATYPE TEXT SIZE IS 20. 
DEFINE FIELD NODENAME
DATATYPE TEXT SIZE IS 20. 
DEFINE FIELD CL_ALIAS
DATATYPE TEXT SIZE IS 20.
DEFINE FIELD LOAD_ID
DATATYPE TEXT SIZE IS 80.
DEFINE FIELD APPLNAME
DATATYPE TEXT SIZE IS 30.
DEFINE FIELD DCL_COMM
DATATYPE TEXT SIZE IS 132. 
DEFINE FIELD LOAD_KEY
DATATYPE TEXT SIZE IS 80. 
DEFINE RELATION USERS.
USERNAME.
NODE BASED ON NODENAME.
END USERS RELATION.
DEFINE RELATION CL_TABLE.
NODE2 BASED ON NODENAME.
CLUS BASED ON CL_ALIAS.
LOAD_ID.
END CL_TABLE RELATION.
DEFINE RELATION APPLTBL.
APPLNAME.
CLUS2 BASED ON CL_ALIAS.
DCL_COMM. 
LOAD_KEY.
END APPLTBL RELATION.
COMMIT;
EXIT
------------------------------------------------
    
SEGNAME=USERS, TABLENAME=USERS, $
SEGNAME=CL_TABLE, TABLENAME=CL_TABLE, $
SEGNAME=APPLTBL, TABLENAME=APPLTBL, $

------------------------------------------------    

FILENAME=AIDE_DB,           SUFFIX=RDB, $     
SEGMENT=USERS, SEGTYPE=S1, $
 GROUP=USERS_KEY, ALIAS=KEY, USAGE=A20, ACTUAL=A20, $
      FIELDNAME=USERNAME, ALIAS=USERNAME,USAGE=A20, ACTUAL=A20,$
      FIELDNAME=NODE,  ALIAS=NODE,  USAGE=A20,    ACTUAL=A20,   $  
SEGMENT=CL_TABLE, SEGTYPE=S1,$
 GROUP=CL_TABLE_KEY, ALIAS=KEY, USAGE=A20, ACTUAL=A20, $
      FIELDNAME=NODE2,  ALIAS=NODE2,  USAGE=A20, ACTUAL=A20,$  
      FIELDNAME=CLUS,  ALIAS=CLUS,  USAGE=A30, ACTUAL=A30,  $  
      FIELDNAME=LOAD_ID,  ALIAS=LOAD_ID,  USAGE=A80, ACTUAL=A80,   $  
SEGMENT=APPLTBL, SEGTYPE=S1, $
 GROUP=APPLTBL_KEY, ALIAS=KEY, USAGE=A30, ACTUAL=A30, $
      FIELDNAME=APPLNAME, ALIAS=APPLNAME,USAGE=A30, ACTUAL=A30, $  
      FIELDNAME=CLUS2,  ALIAS=CLUS2,  USAGE=A30, ACTUAL=A30,   $  
      FIELDNAME=DCL_COMM,  ALIAS=DCL_COMM,  USAGE=A60, ACTUAL=A132,   $  
      FIELDNAME=LOAD_KEY,  ALIAS=LOAD_KEY,  USAGE=A80, ACTUAL=A80,   $

    You may want to take a closer look at the FOCUS interface to RDB users
manual as it looks like you are defining your master file as if FOCUS was
reading an RMS file.  You don't use the keyword GROUP when defining
an RDB .mas file and the segments are S0 or U.


                                          KC

"Keys" are the fields that define unique occurences of records in a relation. 
Traversal between relations is performed by matching values of keys (primary 
to foreign).  I'm guessing but it looks like your relations have the 
following model and keys:

	CL_TABLE       Each CL_table record has many occurences of Users and
	|      |       many occurences of APPLTBL
	V      V
      Users   Appltbl

(Primary key = P	Foreign Key = F)

	CL_TABLE
		Node2		P
		CLus		P
	
	Users					
		Username	P
		Node		P,F

	APPLTBL
        	APPLNAME	P
		CLUS2		F
		LOAD_KEY
	
Generally there are index's defined for keys to improve performance and/or
enforce uniqueness, but the index's are not absoultely required. 
I generally have to have the model and key list in front of me before doing 
the MAS/ACX for Focus as it can be very messy.

I have previously included a Focus MAS/ACX that joins rdb data in note #330.1
Why don't you check it out, model your relations and relationships and try it
again.  It does work.

A comment, there is no real reason to give the the same fields 
different names in the various relations.  In fact doing this makes it harder
to determine the relationships of the data.  You can use the same field name
where ever the meaning of the field is the same.     For example:

  User_list
	Username
	Node

  Cluster_table	
	Node
	Cluster_name

  Application_table
	Application_name
	Cluster_name
	DCL_Command
	Load_key

Using the above field and relation names makes the relationships obvious. To me
it also points out that you may have a problem.  Should the User_list have
Username and node or Username and cluster_name?  Do they log into specific 
nodes, or onto a cluster?.  
	
Have fun,

	Stu