Rene, thank for your help. However, the code you suggest is not behavioring for me as i expect - suppose you have version cycles 1 and 2, and you want to replace the version 2. Using your code i get the same results as before: cycle 2 and a new cycle 3 is on the disk. I am using version 3.10/02 and i cannot upgrade to version 4 for project rules. Can i implement the code changes in version 3.10/02? Many thanks Guido >Hi Guido, > >Thanks for reporting this problem that is now fixed in CVS. > >In your case, instead of your statement > rootInquire->Write(rootInquire->getName().c_str(),TObject::kOverwrite); >you can do, eg > const char* name = rootInquire->getName().c_str(); > delete gDirectory->GetKey(name); > rootInquire->Write(name); > >Rene Brun > > >Guido Gagliardi wrote: > >>> >>> Hi all, >>> >>> i am using the key versioning of objects in TFile. I would like to >>> replace objects written with a definite cycle using kOverwrite, like this: >>> >>> rootInquire->Write(rootInquire->getName().c_str(),TObject::kOverwrite); >>> >>> Where rootInquire->getName().c_str() returns something like: >>> "application;1" or "application;2" >>> Everyithing is working fine when the cycle number is 1 and there is only >>> one iteration of the object in the TFile, and i got my object in TFile >>> replaced as desired. If the number of iterations present in the TFile is >>> two, i get this behavior: >>> >>> before the overwriting of object of cycle 1, in the directory: >>> >>> application;1 >>> application;2 >>> >>> after the overwriting: >>> >>> application;2 >>> application;3 >>> >>> That is, the key cycle 1 is deleted, but the object is written with key >>> cycle 3 (which is, i think, the expected behavior for the kOverwrite >>> option in the method Write()) >>> >>> Since the key cycles gymnic is mandatory for my project, i have to >>> obtain the desired behavior. How can i do that, even not using the >>> kOverwrite option and instead using lower level instructions? >>> >>> Many thanks, >>> >>> Guido Gagliardi
This archive was generated by hypermail 2b29 : Sun Jan 02 2005 - 05:50:08 MET