I am glad to hear that. There are two things I did - and I think I may have been the real cause in the slowdown. 1. I mentioned before some "legacy" code. When reading records the code "loops" through each record to process them. There is an old Clarion statement called EOF that checkes when to exit the loop at "end of file". They had lef tthat in as "legacy" and wanted us rather to check for "errorcode()" and exit. Hitting end of file triggered the errorcode which I captured and exited the loop. So I got rid of all the EOFs and replaced them with the newer errorcode checks. This was the actual cause of the bugs mentioned that would erroneously delete an event in Rebuild. i think the old EOF allowed the loop to loop one extra time more than it should have. 2. I think this tweak was more of the cause of slowdowns that you saw. But I do not understand why some saw it and some didn't. Before compiling the program I checked the compile properties (which I didn't realize I had ever changed) and there is a check box for "Build Release System". This was unchecked, so I checked and recompiled. I think this also affected the file size as without the check I suspect the EXE contained a lot of internal debugging code. Thus checking the "Build Release System" optimizes the code without all the extra overhead dealing with debugging mode stuff. To tell you the truth, once you started saying what you did, I began to realize that recently I had noticed some small slowdowns in certain areas of my CFT also on my XP, although not as significant as you were reporting. So your report got me curious that the stuff I was seeing might be related to what you were seeing. Anyway, glad it has all worked out. I am going to update the program download today with the new CFTW.EXE without making a version change. Ira > I hurried in trying the revised CFT.EXE. > > It worked !!! > My database of 15000 persons is now exported to Gedcom in less > than 4 minutes. !!! > I am so releived, that this annoying problem is solved. > > I am just a bit curious. > Can Ira tell a bit more about the cause of this strange problem ? > How can it be that I seem to be the only victim? > Why is the size of new CFT.EXE so much smaller than the old one > (2885K against 4012k) ?

good to hear this (eof if more than legacy stuff). I suggest you read softvelocity newsgroups regulary, because with clarion 6 you will probably need to recheck the code again. There are lots of advices about speed connected with service packs, disk caching, using threads and using yield on the softvelocity.public.clarion6. There are lots of speed issues covered there vido ----- Original Message ----- From: "Ira J Lund" <ira.lund@cf-software.com> To: <CFT-WIN-L@rootsweb.com> Sent: Friday, February 27, 2004 2:39 PM Subject: Re: [CFTW] CFT Ver 3.14 and Windows XP > I am glad to hear that. > > There are two things I did - and I think I may have been the real cause in > the slowdown. > > 1. I mentioned before some "legacy" code. When reading records the code > "loops" through each record to process them. There is an old Clarion > statement called EOF that checkes when to exit the loop at "end of file". > They had lef tthat in as "legacy" and wanted us rather to check for > "errorcode()" and exit. Hitting end of file triggered the errorcode which I > captured and exited the loop. So I got rid of all the EOFs and replaced them > with the newer errorcode checks. This was the actual cause of the bugs > mentioned that would erroneously delete an event in Rebuild. i think the old > EOF allowed the loop to loop one extra time more than it should have. > > 2. I think this tweak was more of the cause of slowdowns that you saw. But I > do not understand why some saw it and some didn't. Before compiling the > program I checked the compile properties (which I didn't realize I had ever > changed) and there is a check box for "Build Release System". This was > unchecked, so I checked and recompiled. I think this also affected the file > size as without the check I suspect the EXE contained a lot of internal > debugging code. Thus checking the "Build Release System" optimizes the code > without all the extra overhead dealing with debugging mode stuff. > > To tell you the truth, once you started saying what you did, I began to > realize that recently I had noticed some small slowdowns in certain areas of > my CFT also on my XP, although not as significant as you were reporting. So > your report got me curious that the stuff I was seeing might be related to > what you were seeing. Anyway, glad it has all worked out. > > I am going to update the program download today with the new CFTW.EXE > without making a version change. > > Ira > > > I hurried in trying the revised CFT.EXE. > > > > It worked !!! > > My database of 15000 persons is now exported to Gedcom in less > > than 4 minutes. !!! > > I am so releived, that this annoying problem is solved. > > > > I am just a bit curious. > > Can Ira tell a bit more about the cause of this strange problem ? > > How can it be that I seem to be the only victim? > > Why is the size of new CFT.EXE so much smaller than the old one > > (2885K against 4012k) ? > > > ==== CFT-WIN Mailing List ==== > To unsubscribe from CFT-WIN, send an e-mail message to: > CFT-WIN-L-request@rootsweb.com (for individual messages) > CFT-WIN-D-request@rootsweb.com (for Digest mode) > Subject: unsubscribe > In the body include only one word: unsubscribe > (Turn OFF your signature file when sending this command) > > ============================== > Gain access to over two billion names including the new Immigration > Collection with an Ancestry.com free trial. Click to learn more. > http://www.ancestry.com/rd/redir.asp?targetid=4930&sourceid=1237 >