I was trying to create a hold file to be used in another report. I have created hold files before and been able to report off them. Not sure what I'm doing wrong this time. After I run the fex, and create a new fex, I can't see or use the hold file.

Fex1 to Create Hold File

DEFINE FILE CAR ADD
Date_Updated/HYYMDS=HGETC(10, 'HYYMDS');
END
TABLE FILE CAR
SUM SEATS
BY Date_Updated
BY COUNTRY
BY CAR
ON TABLE HOLD AS DAILY_HIST FORMAT ALPHA
END

After running, this is the message:

quote:

0 NUMBER OF RECORDS IN TABLE= 18 LINES= 10

I assume this means the output is 10 rows of data.

Fex2 for report in GUI not able to see DAILY_HIST. If I manually type into text view, get an error

quote:

0 ERROR AT OR NEAR LINE 1 IN PROCEDURE ADHOCRQ FOCEXEC *
(FOC205) THE DESCRIPTION CANNOT BE FOUND FOR FILE NAMED: DAILY_HIST
BYPASSING TO END OF COMMAND

fex 2 manually typed to look like:

TABLE FILE DAILY_HIST
PRINT Date_Updated
COUNTRY
CAR
SEATS
END

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

If you want to keep a hold file, then you should probably use APP HOLD

FOCCACHE is another option of you only need to retain the HOLD data temporarily for a short period of time.

Doesn/t FOCCACHE only work for a session ?

It does, which is often exactly what you need for temporary data.

If it only were a bit easier to use hold-files in FOCCACHE with embedded procedures (html launch pages). HTML Composter doesn't allow to select such files, even though they should be in the same session - it doesn't look in FOCCACHE at all! After you hack the HTML to add foccache to the path ("ibiapp_app" attributes) it can find such hold-files just fine, so it can work

Not sure if this will work for you. But we have resorted to doing is creating a "tmp" sub-directory under ibi/apps, and then creating a sub-directory under this per user (based on the userID).
This was implemented prior to the introduction of FOCCACHE, and is now so embedded in our applications that we have not yet thought of converting to FOCCACHE.
So, as an example, if your UserID is sxschech, then there would be a directory called ibi/apps/tmp/sxschech.
That is the first step.
The second step is that in the site profile we then MAP to this directory with the same app name e.g.
APP MAP TMPUSER DISK D:\ibi\apps\sxschech

Then, where we want HOLD files to be persistent between sessions, we would use e.g.
ON TABLE HOLD AS TMPUSER/DAILY_HIST FORMAT ALPHA

That creates both the FTM and MAS file in the user's TMP directory.

Oh, and obviously the TMPUSER mapped directory needs to be in the PATH e.g.
APP PREPENDPATH TMPUSER

If I'm reading this correctly, sxschec is running a FEX and creating a hold file. Then running a separate FEX and trying to access that hold file. I think this is a no-no. The FILEDEF for the hold disappears when the first FEX terminates.

The second TABLE request has to reside in the same FEX as the first one - or you have to create a FILEDEF back to the hold file before running the second table in a second FEX.

Forgot to turn notification on. Thanks for the suggestions. What I'm looking to do is to create a table file that will be appended to on a daily basis and then run a report off of that data.

If data is only needed temporarily, FOCCACHE avoids the necessity of using APP HOLD and FILEDEF because the FOCCACHE folder is appended to the front of the APP PATH for each user session.

@ Twanette - FOCCACHE won't work in your situation because it is single folder common to all users - unless you incorporate a method to uniquely name files stored in FOCCACHE for each user.

Hi Dan,

FOCCACHE is actually unique to each user session and therefore doesn't have the Problem you suggest. Each user session will create a sub-folder within the main FOCCACHE folder (same parent folder as edatemp if I remember). You are correct in stating that the FOCCACHE folder is app mapped and prepended to the app path but it is the sub-folder in FOCCACHE that is prepended and not FOCCACHE itself. This negates the requirement that we used to employ differing hold file names generated by utilising the mre userid or time stamp etc. such that a file held as FOCCACHE/filename is unique to each user because of the folder per user per session situation.

I harness FOCCACHE often but will check for the existence of the source in FOCCACHE first just in case a new session is in existence. If the source file exists, I will skip the creation otherwise I will allow its recreation - much like we did in "days gone by" .

So Twanette (remember you from foclist(?) days?), you should be able to proceed with a move to FOCCACHE usage fairly confident that it will match what you currently do without having to go to the effort of testing for the existence of the tmp/user folder first - just use FOCCACHE.

T

@ sxsChech,

To achieve a daily (or periodic) appended file, you need to identify your base requirements first.

What RDBMS do you need to use (if any)?

If a flat file will suffice, then utilise filedef using the (append option on a permanent file existent on your SAN or network device.

If you need a structured table but do not have a RDBMS then look at using FOCUS format (XFOCUS is a licence implication). However, you will need FOCUS MODIFY knowledge but your local IB professional services might be available to assist if necessary?

There are many previous posts on Focal Point that may provide suggestions on how to achieve this.

Good luck

T

Thanks Tony for correcting both my mistaken post and my mistaken understanding of FOCCACHE.

Hi Tony A,
Agreed. FOCCACHE would largely be a suitable replacement! It has just been a factor of time, and the age old "if it aint broken ..."

I think the only advantage to our method was that it could in fact be even more "persistent" than FOCCACHE i.e. even between browser sessions.
But the biggest disadvantage of our mechanism was that we had to build all the functionality to check/create the subdirectories, and then to clean up all the files that we didn't want to keep.

quote:

even more "persistent"

Absolutely, and very useful in many situations - I am sure that many sites use this sort of processing.

My only concern is, in a near real time environment, using files lurking from previous days (weeks, months?) and the end user (bless them ) believing that what they saw in the report was current data. Do you clear out your temp folders nightly or is your reporting environment not required to be near real time?

@ Dan, I must admit that it took me a while to read through how FOCCACHE was meant to work and get my few grey cells to comprehend the workings. Once I did, it has proved invaluable many times.

T

@ Tony - My misunderstanding of FOCCACHE came from my own observations in the few instances where I had used it. When searching for my FOCCACHE session entries in Dev Studio, I found only one FOCCACHE folder. So my assunption was that every users' data would be stored in the same FOCCACHE folder. After your post I searched IBI's tech site and eventually found documentation that confirmed your explanation. Dev Studio must somehow limit my "view" of the FOCCACHE folder to only those entries I have created. A brilliant implementation that had me confused from my viewpoint.

quote:

eventually found documentation

Hi Dan,

Oh so true and I now have an external hard drive (pen drive too small ) of the PDF documents that I have found to be useful.

I know that I can get them from the web anytime but that's not worth anything when I do not have internet access! I just have to remember to keep them current when there's a new release.

T

quote:

external hard drive (pen drive too small ) of the PDF documents

I've done the same, but I've got all the documents, get them all for the release we are on/going to. Its easier that having to go get one when its needed.