Conference ilbbak::ibi_focus

    
    Hmmm... depends on the application.
    
    If it's an online TP system, then RALLY would probably be better for
    the customer (as they already have the relevant skills) but will involve
    throwing away the FOCUS code and developing again from scratch.
    
    However, if it's a reporting application I'd stick with FOCUS for the
    following reasons:
    
    	1.	RALLY (to the best of my knowledge) is not exactly reknowned
    		for its reporting application capabilities,
    	2.	if DEC thought they had a superior reporting product, they
    		wouldn't buy in and use FOCUS themselves !!
    
    If you wish to press the customer to use a DEC product, then I'd
    suggest you offer them TEAMDATA (...which hasn't exactly set the world on
    fire -) ...), or good old DATATRIEVE, or maybe even COBOL (now I'm
    being silly !)
    
    Regards  -  David
    

    
>>    How much effort is required to convert from Focus to Rally ?
  
	If they don't have any Focus expertise, wouldn't they be
	building a new Rally application which has similar functionality
	to the existing appl.
    
>>    They are looking at pruchasing alot of consultancy from somebody.
  
	Is this because they don't have any Rally experience either, or
	shortage of resources?

	I agree with the previous reply on type of application.  
	From a programming perspective I feel that Focus is easier to 
	maintain (code oriented(Focus) vs. menu/object oriented(Rally);
	and for a data access appl. there is no contest.

    	(you might want to check the Rally notes file, and please don't 
    	 cross-post this reply.. I don't want any hate mail from the 
    	 Rally people)
-richard              

Having consulted extensively for a customer who uses RALLY, Uniface and
FOCUS, I would have to disagree on the maintainability of FOCUS re RALLY,
depending on the programmer. Screens seem to me to be a real bear in
FOCUS compared to almost any other 4GL. And FOCUS still has not released
a version with the read-only/read-write paradigm for use with Rdb.

Peter

    RE .3
    
    The Focus Screen Painter can be used to build new and maintain 
    existing screens.  What do you mean by 'the read-only/read-write
    paradigm'?
    
    Richard

Richard,

>    The Focus Screen Painter can be used to build new and maintain 
>    existing screens.  What do you mean by 'the read-only/read-write
>    paradigm'?

The typical and recommended method for handling screen input applications
is to read the record in a read-only transaction, preserving its dbkey
and then after the user has modified the record on the screen, to reread
the record in a read-write transaction using the dbkey (minimal locking)
and compare the current record with the original (to make sure no one
else has modified the record) - and then to actually update the record.
This is sometimes called optimistic locking and is the only real way
to avoid locking problems. RALLY (and Uniface) has this built-in, but it
is very! difficult to do with FOCUS.

Re Screen Painter, my experience (5.2?) was that you could not maintain
screen with "arrays" of records, a very common need and easy to do with
RALLY.

Peter

	Peter,

	You are correct in that Focus does not have the read/read-write
	transaction handling built in for RDB.  As a multi user transaction 
	processor Focus is not the best choice, and with higher volumes
	neither is Rally.  You can build your own read/read-write transaction
	with Focus using a read master and a write master for the same 
	relation(s) and a scratch file.   

>>Re Screen Painter, my experience (5.2?) was that you could not maintain
>>screen with "arrays" of records, a very common need and easy to do with
>>RALLY.
  	Use the REPEAT and NEXT features to build 'arrays' into a CRTFORM.


-richard