On Wed, 30 Apr 2008, Sulyok Péter wrote: > I tested the fpt memofile, but the problem doesn't will be correct. > If i used an memo width fpt format, and modify a record, or delete, then the > size of .fpt file didn't change.
Yes it is. When you change the memo FPT or SMT field putting smaller value then the previous one the FPT and SMT size is not reduced but the used area is marked as free inside memo file and will be reused on next update. Deleting record does not change anything. Deleted DBF records still accessible and all fields have to be valid so area allocated by memo fields cannot be freed. If you want to mark it as free then you will have to assign "" to each memo field in deleted record. > This is a program, witch become more record, and gives to operators, after > that updating in the base. > One timer makes the corrections in a base, but the memo file doesn't will be > more litle. And it won't be but it will also not grow if inside memo file is free continuous area long enough to store new value. If not then new value will be added at the end of memo file. It's expected and documented behavior compatible with other languages which uses memo files with garbage collectors, f.e. Flex3 (CL53 CDX RDD), SIX3 FPT and SIX3 SMT. Only PACK and/or MEMOPACK reduce the memo size but such operations are time expensive. It's also the reason why they are not done automatically during each memo field update. MEMOPACK after each update will cause huge speed overhead for big files because all data in memo file located after removed block will have to be moved and all corresponding DBF records holding memo block address updated. Only last memo block (it does not have to be bound with last DBF record) can be easy removed by simple memo files cutting and our FPT and SMT memo drivers does it. > I made a module, witch can handling this problem, but i hopped, it is > implemented in compiler. > If you can use it, than i send to you. I do not think it will be necessary. I know how it works (it was implemented by me) and it cannot be changed without rather unacceptable speed overhead. > Thanks for the help, and sorry my bad english! Don't worry. It's not worser then mine. best regards, Przemek _______________________________________________ Harbour mailing list [email protected] http://lists.harbour-project.org/mailman/listinfo/harbour
