Temp-file(temp-table)

Hi all,
How to implement and use temp-table (temp-file) in WINDEV. I found in Windev help this:
How can I describe temporary files?
To describe temporary files, you must:
1. Use File description, Item description and Link description type variables (if necessary).
2. For each file:
Describe the file characteristics using Hyper File properties.
Describe the item characteristics using Hyper File properties.
Validate the description of each item (HDescribeItem).
Validate the file description (HDescribeFile).
3. If necessary, describe the link characteristics using Hyper File properties.
4. Validate the description of each link if necessary (HDescribeLink).

I understand this and I create temporary file.

I fill in the temp-file by programming and then fill the table from the temp-file.
Before the fill in the temp-file of course I delete all records from the temp-file and I have procedure to add new record according to specific criteria.
When window is closed the HClose() and HCancelDescription() are called.

I have to solve this problem:
After creation of the temp-file how to implement that temp-file scope just for the window where it is defined? Because when I start the same window from two different sessions I get the error: "The file <file name> is already described".
For example the following case is possible to happen: When two or more users use the same temp-file (defined in window) and when they passed different parameters to fill in the temp-file, how to provide each user to see the correct data according to selected criteria?
Let say first user should view 5 records according to entered criteria, the second user run the same procedure and delete all records from the temp-file, after that the temp-file is filled by 10 records. Does the first user still see 5 records or 10?

In PROGRESS (4GL) for example there is no problem when temp-file defined in the window, and that window is called twice or more by the one or more clients.

TIA,
Regards,
Velkov Stojanco


Message forwarded from pcsoft.us.windev



Edited 1 time(s). Last edit at 07/15/2008 03:31PM by GuenterP.

Hi Velkov,

You can obtain a filename that in most cases will do:
1. Use the NetmachineName function.
2. Use fExtractPath(fTempFile(),fFileName)
Consult the help how to use these functions.


HTH, best regards,
Piet



Edited 1 time(s). Last edit at 07/15/2008 03:11PM by Piet van Zanten.

Temp-table in PROGRESS 4GL are created on disk but als unnamed with temporary random name, when procedure ends progress deletes the temp-file. You operate with them thru the LOGICAL name in the procedure.The scope is defined thru the definition
new shared, shared,or just for local purpose.
In WinDev when you define an file,structure,etc,you NAME IT,and therefore the file exists on disk als usual file with name,when you start another time the same window ,the file allready exists of course.Give them a some random name,or the better solution is to find in help something like Progress work-file.That is memory table for temporary calculations.


Best regards




Edited 1 time(s). Last edit at 07/15/2008 03:59PM by GuenterP.

Maybe "views" are good for you? Have a look at HCreateView(). You can use all H-commands on views, like HAdd, HModify. And that's all done in memory.
Note: autonumber fields are not taken into account when using HAdd()

Arie

I create temp files the usual way I create all files, in the analysis. Just before I use them, I do an hCreation which recreates the file. This is much faster than having to delete the records individually. In a networked or hfcs environment, make sure that the file will be created in a local folder or is not opened with hfcs to avoid conflicts with other users. This option will not work if you can open the window which uses this file more than once.

Of course it would have been better if WD had a hCreateTemp command which used a predefined file as its template (pcsoft are you there?).

issah

Hi,

You can also use

HDescribeFile
HDescribeItem
HDescribeKey
HDescribeLink

this way you can have real file access, but if you do not use declare external then it will not write to disc.

Regards.

Carlo

Hi Carlo
How do you manage to do this? I have tried using exactly the sequence you have described but it still creates the file on the disk. Because of this I have given up on temporary files in this type of situation and use either Views or memory tables, depending on exactly what I need to do with the data.

David

Hi Issah,

Thank you for your tip on HCreation just before you want to post data to an existing file. I must admit I have been doing it the hard way by deleting all existing records and compacting the file before re-populating it. It always seemed a messy way to do things and your tip has helped me considerably.

The good things are always simple (when you know how).

Milton

Hello

I use a variety of methods for temporary files.

Most times I create a view, either a blank view, to duplicate an existing file structure or one populated with required data.

Invisible memory tables on windows. These can be used by the current window and any subsequent window, as can views.

Actual temporary files with genericly named fields .e.g currenyc1, currency2 etc so they can be used for any purpose. These are mainly used to hold data for printing.
To handle multiple users in these actual files I generate a key from another process and write the key into the temporary file so I can extract each user's set of data using this key. I monitor the number of records in these files so that when they reach a predetermined size, users are prompted to clear them out, for which I use hcreation().

Regards
Al

Hi,

I see that you allready got some usefull pointers from people, but since I also made the switch from Progress 4GL to Windev, here is my experience.

Like you, I struggled with this issue. Progress' solution is actually quite fancy, offering a) work-tables which behave almost like real tables and are managed totally in memory, and b) temp-tables which behave exactly like real tables and are managed on disk. A strong feature in both of them (I feel) is that the temporary table will always be totally isolated from any other machine, user or session. Meaning that even if an end-user is running four instances of my app, all of them on the same workstation and all of them using the same logon, the temporary table will never interfere with that of another session. Even when two windows/procedures within the same session use the same temp-table, with identical name and structure, they will still be totally isolated from one another (if I choose so). That is because the Progress temporary table is truely NOT part of the database (which *is* shared among machines, users and sessions). Most of the implementations of temporary tables that I have seen, involve creating an actual table inside the database, and giving it some sort of special "temporary" status. And then issues such as uniqueness and scope must be addressed. Progress does not need to do that, since the table is not created inside the database to begin with. In fact, if my Progress app does not use any database at all, I can still use work- and temp-tables!

I did not find such a sophisticated mechanism in Windev. Since my apps do not use HyperFile at all (only SQL-based databases such as MySQL, SQL-Server, Oracle etc), I considered setting up some sort of temporary database using HyperFile, strictly for temporary data structures. But I would still have to address the issues regarding uniqueness, scope and lifetime. Databases such as MySQL and SQL-Server also offer temporary tables, but by nature these are also created inside the database itself, which is not what I want. I also rejected the use of memory tables, since they involve creating an UI element (a widget in Progress lingo) so they cannot be easily used outside the scope of a window, like in global procedures or class-methods.

In the end I chose for arrays of structures. It is actually quite similar to Progress work-tables. The structure declares the various fields of the temporary table, similar to the FIELD clause of the DEFINE TEMP/WORK-TABLE statement in Progress. You can add "records" to the table simply by adding (or inserting) elements to the array, using the ArrayAdd() and ArrayInsert() functions. Or delete "records" using ArrayDelete(). In fact, Windev's support of arrays is MUCH better than that of Progress, offering seek, sort, copy and various other operations. And very important: a Windev array can be passed between procedures just as easily as a "simple" variable. Unlike Progress, where only individual array elements can be passed. This enables you to share the temporary data structure between procedures while still controlling its scope. Similar to passing (the handle of) a temp-table in Progress. You will still require the declaration of the data structure in both procedures, but that is the same in Progress - just put it in a header file.

I found that using arrays of structures meets most of my temporary needs. I can declare them anywhere in the app, give them any scope I need, and pass them between windows/procedures as I wish. They give me the same level of isolation as a Progress work/temp-table. I admit that the syntax is a little less intuitive than in Progress, where I can simply use the same DML-statements for manipulating real and temporary tables. After all,

str_Customer is structure
	Cust_Name is string
	Cust_City is string
END

arr_Customer is array of 0 str_Customer

i is int = ArrayAdd(arr_Customer)
new_Customer is str_Customer dynamic = arr_Customer
new_Customer:Cust_Name = "PC Soft"
new_Customer:Cust_City = "Montpellier"

... is more code and less readable than

define work-table wt_Customer
	field Cust_Name is character
	field Cust_City is character.

create wt_Customer.
assign
	wt_Customer.Cust_Name = "PC Soft"
	wt_Customer.Cust_City = "Montpellier"

... but I got used to it.

Finally, to complete the comparison, I have to point out the differences. First, an array of structures is more like a Progress work-table than a temp-table. Windev arrays, like Progress work-tables and unlike Progress temp-tables, are completely managed in memory. Thus available memory can be a restriction. In my Progress days I used a work-table if I expected it to contain no more than 500 records, otherwise I made it into a temp-table. Similarly in Windev, if I expect the array to hold many records, I keep monitoring the memory usage when testing the app. I do not want my app to eat up much or all of the available system memory. Another difference to keep in mind is that arrays are not part of Windev's database engine, so they cannot be rolled back!

I hope this is of some use to you. Again, I have little experience in using HyperFile. Like some people have commented allready, perhaps using HyperFile temporary tables and/or views is the way to go for you. Especially when you are allready accustomed to using the H...* functions (I am not). Personally I prefer arrays of structures.

/sohan

Hi Milton,

Thats the good thing about this forum. I also used to do it the "hard" way till someone on this forum showed me the light. The honor goes to all those who contribute solutions and experiences as well as those with questions seeking answers. Helping each other to help ourselves.

issah