Is there any justifiable reason why one would use "ON TABLE HOLD AS HOLDFILE FORMAT ALPHA" instead of "ON TABLE HOLD AS HOLDFILE FORMAT FOCUS", when HOLDFILE isn't being used for anything other then a subsequent "TABLE FILE HOLDFILE" request? After all, the is WebFOCUS, isn't it?
Inquiring minds want to know…

This message has been edited. Last edited by: Doug,

Actually I would just use "ON TABLE HOLD AS HOLDFILE".

The main reason for me is overheads.

FORMAT FOCUS will generate a FOCUS file, a hold file and then load all the records into the FOCUS file.

The HOLD FORMAT ALPHA or just HOLD, only writes out the data to a file.

Simply its quicker.

We started to use

ON TABLE HOLD AS H01

instead of

ON TABLE HOLD AS H01 FORMAT FOCUS

to speed things up.

FOCUS format will 'segment' the data for faster retrieval, but it will take much longer to make such a HOLD file.
If the HOLD file is only used in the same procedure ( e.g. temporary and not a saved HOLD file ) it's faster to not use FORMAT FOCUS.

In some cases ( large HOLD-files, which you have to try to avoid ) XFOCUS is faster.

Good luck,
Dave

Isn't there a SET command to copy the internal matrix (which is nothing but an on-the-fly in-memory Focus file) directly out when you HOLD FORMAT FOCUS, bypassing all the extract processing? That should be more efficient than HOLD [FORMAT ALPHA].

I go for FOCUS format, in case of using SQL translator. Also when I have a single large data file and I need to have index on particular column which I hit multiple times down the flow with different filter conditions.

Thanks,
Ram

Jacob, I think you're thinking of the DIRECTHOLD parameter, which is set to ON by default. It does not create an intermediate file and a MODIFY procedure, it just makes WF to dump the internal matrix on disk.

/Håkan

I use HOLD AS FORMAT ALPHA all the time when the next step in the process is a MODIFY with a FIXFORM statement.

Thanks for all the input...

So, IF all I want to do within a single procedure is to do a TABLE FILE request, then the FORMAT FOCUS is not necessary. However, IF I am doing an APP HOLDDATA … APP HOLDMETA… (so that these HOLD files are available to other fexes) then a FORMAT FOCUS would be a better choice then FORMAT ALPHA, right?

No.

Also, if you need to JOIN to/from this HOLD file, FOCUS DBs cannot join with more than one column.

quote:

FOCUS DBs cannot join with more than one column.

Yeah, What's up with that? This is FOCUS... So, why limit the JOINs to ONE?

They'll catch up to NOMAD one of these decades.

BUT, I recently successfully did a multi-column join with FOCUS dbs using SQL.

Can't a condition-based Join be utilized?

It seems that conditional joins do work, but not from a hold file to as FOCUS file.

But FOCUS to FOCUS works, bizarre !

Multi field joins can be accomplished on FOCUS/XFOCUS files using the MDI feature. The MDI build is fast, and subsequent retrieval also fast.

quote:

It seems that conditional joins do work, but not from a hold file to as FOCUS file.

But FOCUS to FOCUS works, bizarre !

How about if the HOLD file is the results of a "ON TABLE HOLD AS MYFILE FORMAT FOCUS" line?

Hi Alan,

What is the MDI feature?

quote:

How about if the HOLD file is the results of a "ON TABLE HOLD AS MYFILE FORMAT FOCUS" line?

That will work, it is flat file to FOCUS db that is not supported.

quote:

What is the MDI feature?

Multi Dimensional Index. A (paid for I believe) feature of the FOCUS/XFOCUS database. It allows an index to be create from more than 1 dimension and in different segments. Quite cool really and v. rapid. Joins can be constructed onto all or part of an MDI.

Ah, so its like joining to primary key fields in a DB.

If you need to join on multiple fields you could choose to add a surrogate-key field ( combined / concatenated ) which is unique.

This way you can always join on one field.
Added bonus : index that key!



...or use match.

Getting more answers here, live, at Summit 2014.

Networking at the Focal Point Booth with Kathleen Butler! Lots of excitement here at Summit 2014