Hi Sean,
Thanks for your reply.
Regards
Johan de Klerk
Hi Sean,
Thanks for your reply.
Regards
Johan de Klerk
no I would expect it to be slightly slower, as there will be some overhead at the start while it does some thinking about which key to use. Usually it would not be noticeable but I do remember years ago a situation with tps where the delay at the start of a view meant I went back to getting rid of the view.
Also with a tps view you can never be 100% sure that it will use the key you expect whereas with Set/Next on the tps file you are in control of the key that is used.
Having said that, if you are writing for tps now but expecting to go to SQL later then going the view route seems sensible.
Hi Geoff,
Thanks for the information.
Very informative.
TPS at this stage but maybe SQL at some stage.
Regards
Johan de Klerk
You can be sure if you SET(Pre:Key) before the OPEN(View) as noted in the View Help.
Either a SET statement on the VIEW’s primary file before the OPEN(view), or a SET(view ) statement after the OPEN(view), must be issued to set the VIEW’s processing order and starting point, then NEXT(view) or PREVIOUS(view) allow sequential access to the VIEW.
This is the way the Legacy Templates generate code for Browse, Report and Process if a KEY is selected for Primary, else it does the SET(View). ABC does also, but it is more hidden in the classes.
Something like this for the previous code:
SET(MRF:CustNoExtra_Key ) !<**** Add: Set(Key) ***********
OPEN(MyRefFile:View)
IF ERRORCODE() THEN ... etc
LOC:Filter = '(MRF:CustNo = ' & MMF:CustNo & ') AND (MRF:Exstra = '''AAA''')'
MyRefFile:View{PROP:Filter} = LOC:Filter
!No use, SET(Key): LOC:Order_Sprak = 'MRF:SomeColumn'
!No use, SET(Key): MyRefFile:View{PROP:Order} = LOC:Order
IF CLIP(MyRefFile:View{PROP:Order}) THEN !<*** Add: if there is an Order
SET(MyRefFile:View) !<*** then use SET(View) so may not use Key
END
LOOP
NEXT(MyRefFile:View)
From a SQL point of view, the View structure is a lot faster than a File structure.
However for the new drivers i’ve retro-fitted View functionality to the SET/NEXT loop. So things like prop:Project, prop:Filter and so on can now apply to File loops as well as View loops.
This approach allows for improved File performance for those who dont go the whole hog to changing to a View.
None of this applies to TPS of course.
thanks Carl.
Strange I had a problem with it back last century so I cannot remember the details now, but it had a filter and it seemed like the view engine thought it “knew better” and used a different key to the one I wanted, resulting in the records coming out in the wrong order. I didn’t really trust it after that but perhaps I was just doing something wrong…