I just looked at the master-files for some HOLD-files I created, and noticed that fields that I specified with DEFINE are NOT stored as such, but are instead stored as full-fledged fields with their data in the FOC-file? I kind of expected those to be only added to the masters, and not to the FOC-files.

Is there a switch to chose which of the two (DEFINEs in the master, or data in the FOC-file) will be used?

Not a big deal really, disk-space is cheap, but I wouldn't be surprised if simple calculations would perform better than traversing a larger FOC-file, at least in some cases.

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

This is normal behaviour, and it is so for every relational database I've come across. DEFINE fields are "virtual fields" on input and become real fields on output, just like reading a MS SQL Server or DB2 view - virtual on input, real on output.

quote:

Can hold files store defines as defines

So, no, hold files cannot store defines as defines.

Actually that's not entirely true.

Views in DBMSes are just queries, so columns that are only defined as an expression in the view remain just that, an expression. The WebFOCUS equivalent of that is a master-file describing a database-table, with DEFINE's (or virtual fields) added to the master for the expressions.

However, in reporting you'd probably store several so-called "materialized views" with aggregated data in your DBMS, like what WebFOCUS does with HOLD-files.

My question is whether I can get WebFOCUS' masters about HOLD-files to behave the same as DBMS views or masters about database tables, so that it doesn't store redundant data (results of expressions based on other columns in the record) in its HOLD-files if not necessary.

The feature seems entirely possible, I'm just wondering if it's there yet?

adding a noprint to a field might do that
or the SET HOLDLIST=PRINTONLY is probably an option

If you not want the computed or defined fields to be sored in teh hold file you should add the DEFINES after you created the HOLD file.

TABLE FILE XXX
PRINT fields
ON TABLE HOLD
END
DEFILE FILE HOLD
defines
END
TABLE FILE HOLD
PRINT fields 
defines
END

There is a way to get the define'd fields in a report.
Maybe with some creative thinking this could be usefull

-Fred-

-* --- Define fields on CAR-database
DEFINE FILE CAR
  CNAME1/A12 = IF COUNTRY EQ 'ITALY' THEN 'Y' ELSE 'N';
  CNAME2/D5  = IF COUNTRY EQ 'ITALY' THEN  0  ELSE  1;
  NEWDATE/YYMD WITH COUNTRY='&DATEYYMD';
END

SQL FMI SET TEMPDEFINES ON
-RUN

SQL FMI SET MFDNAME CAR
-RUN

TABLE FILE SYSCOLUM
  PRINT
     COLUMN_NAME
     DEFTEXT
  IF DEFTYPE EQ 'P' OR 'T'
END

Smart Fred

Wonder how you could use this
And does it also work for defines and computed fields in the Master.

Is this documented somewhere?

quote:

Originally posted by FrankDutch:

DEFILE FILE HOLD

Haha, nice one!

Yeah, I could just define the fields again every time I need them, but in many cases I need them more than once (the hold files are created by the reportcaster in many cases) or they're going to be used by someone else.

The latter is precisely why I want those fields to be available from the hold-file (or rather, the master file), as those people are just too damn lazy (or just incapable) to try and define them themselves! They're usually just trying to get their work done, which isn't writing WebFOCUS reports - they just happen to need one for it.

Most of the extra defines I need are related to report readability. For example, we have reports that use numbers like 1110401 for a date, or 11114 for a week number - you can imagine people other than the report author are having trouble interpreting those.
My job here is to set a standard for how reports are created, but the report owners won't follow that standard if that involves too much work (too complicated for them to understand right away, for example) or if they don't agree with how that goal is accomplished (by increasing the size of FOC-files with extra fields more than they think necessary, for example).

@Fred; I'm not really sure what part of your example is relevant to this issue and I can't really verify as the SQL FMI command is unknown to WF's help system (booh!). I suppose you could put the results of retrieving those defines in an ALPHA file and include them before a TABLE FILE, but that's not really the kind of solution I'm looking for.

You can create a masterfile with the defined fields that overrules the masterfile that was created on the fly.

If you are sure the created holdfile is always the same structure, just make that new Masterfile .

If you do a SAVE and not a HOLD there will be a FTM or FOC file, but there is no MAS file created.
That might do it for you