|
| Re: Temp-file(temp-table) |
| Débuté par guest, 16 juil. 2008 09:56 - Aucune réponse |
| |
| | | |
|
| |
| Posté le 16 juillet 2008 - 09:56 |
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 th
at 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 |
| |
| |
| | | |
|
| | | | |
| | |
|