PC SOFT

FORUMS PROFESSIONNELS
WINDEV, WEBDEV et WINDEV Mobile

Accueil  |  Messages récents  | Connexion  |   | Français  FR
Accueil → WINDEV 2024 → Strange behaviour HF (Windev 7)
Strange behaviour HF (Windev 7)
Débuté par Albert Buitenhuis, 06 déc. 2004 10:44 - 5 réponses
#1
Posté le 06 décembre 2004 - 10:44
We're -rather suddenly- confronted with two strange HF problems.
1) After closing the HF table (hClose({tablename}) and start reading again (HreadFirst({table},{key})) no records are found. When using HDeactivateFilter before reading the records, the search will be successful. Shouldn't HClose deactivate the filter?? Anybody experienced something like this?
2) Now read this one. This is the code:
HFilter(CPRICORK,ORDERNR,99)
HReadFirst(CPRICORK,ORDERNR)
IF H.Out THEN
HReset(CPRICORK)
CPRICORK.ORDERNR™
CPRICORK.ORDERTYPE=2
HAdd(CPRICORK)
....
(CPRICORK.ORDERNR = integer, not automatic id)
(single user, no independent HF context in the wdw or anything like that)
* Whatever I try, the ordernr remains 0 -as also seen while debugging.
* When using HClose(CPRICORK) and HDeactivatefilter(CPRICORK) before this diplayed code, the CPRICORK.ORDERNR is actually set to 99, but is reset to 0 in the next line (CPRICORK.ORDERTYPE=2).
* Exactly the same code is performed correctly in a previous version of the project, while the datamodel has not been changed.
Does anybody have an idea (Already tried to get red if of my cpl dir... ;-))
Greetz,
Albert


MSG Netherlands NV
#2
Posté le 06 décembre 2004 - 11:09
G'day Albert
Problem 1
The help in WD8 states that "When the file (the query or the view) is closed (HClose, HOpenAnalysis functions for example), the filter is deleted." I think you could assume that was also the case in WD7. I never had occassion to test it though because I never had to issue an HClose() I just let Windev manage all the file open and closes for me. The solution may be to always use hdeactivatefilter() even if you are going to close the file.
Problem 2
I have had some odd problems with files that were corrupted and managed to fix some by opening them in WDMap and adding and deleting a record. This must have reset the header I presume. Have you tried the code on a newly created file ?
You can alleviate most file and index problems by setting your HSecurity to 2 regardless of how good you think your hardware and OS is performing. We have not noticed any degradation in speed running at level2
Regards
Al
#3
Posté le 06 décembre 2004 - 12:30
Hi Al,
Thanks for your reaction.
Problem 1: that's indeed a solution. It's just that our main project is about 40 Mb in executable... We can handle the problem for about 90% of the cases by deactivating the filter, leaving a huge 10% to handle. It's kind of eery that HF7 seems to manage the HF data in such way.
Problem 2: the file in question is created using HCreation just before. The file does really exist, giving extra time to create the file does not help. We already use HSecurity(2) in the project. Setting cpricork.ordernr to 99 is actually the same as declaring a variable; but -in one way or another- Windev does not change the value in this case. And it might be clear that there's no other (global) variable with the same name...
We'll see. Maybe there are more suggestions....\
Albert


MSG Netherlands
#4
Posté le 06 décembre 2004 - 13:18
G'day Albert
Problem 2
Have you checked HVersion to see if the record is actually being written without error ? In WD8 the HAdd() also returns true/false to indicate that the record was added properly, not sure if this is the case in WD7
If all else fails you could try something illogical
What happens if you add a blank record, then modify an existing record with the real values.
Regards
Al
#5
Posté le 06 décembre 2004 - 13:26
We tried everything. We even deleted all windows and project code to try to tackle the problem. The problem remained.
We just renamed the project dir and started the program again. Windev warned ("Your project had moved blabla...") end we continued. Thereafter the problem was gone.
We did try a recompile before, that did not work. In one way or another Windev has made an internal, -in code- irresolvable mistake. I'm glad the problem has gone, but this is something that -according to my view- should not be possible!!! Besides recompilation, is there any other action one could take to overcome such problem without renaming the physical project dir???
We're going on...
Albert

MSG Netherlands
#6
Posté le 06 décembre 2004 - 13:29
END we continued... I'm sorry... The key's aren't even next to each other on my QWERTY. Unforgivable mistake...
Last but not least: the problem ANDed ;-)
Albert
→ Revenir à WINDEV 2024