Failure of RETRY after error 1

[AbleA]

In FoxPro 2.6 for Windows running under Windows NT4, I've noticed that issuing the RETRY command after certain errors doesn't seem to do anything.&nbsp;&nbsp;Execution continues as if the retry had worked, but the program line which caused the error is not re-executed.<br><br>The specific situation encountered is when adding a data record fails due to a lack of disk space (error 56).&nbsp;&nbsp;Typically, the CDX gets saved but not the DBF.&nbsp;&nbsp;Choosing the Retry option from my error handler's dialogue box causes the program to continue as if everything is OK, but subsequent examination of the files shows that the situation remains unchanged (e.g. new CDX with old DBF, which then gives error 5 (record out of range)).<br><br>Can anyone confirm my observations and offer a solution?<br><br>Note that the FoxPro DISKSPACE function always reports more space than is really available on our network drives and so cannot be used as a check before saving (it seems to ignore the space restrictions applied on our network, as does Windows NT Explorer!).<br><br>Any help would be greatly appreciated.<br><br>Andy Blay

 

[dgrewe]

Yes , I have found the same thing,&nbsp;&nbsp;The Retry command does not always work after a <font color=red>DOS I/O Failure</font>.&nbsp;&nbsp;If the error is caused by a record lock or file in use, the command works as required.&nbsp;&nbsp;You may also want to look at the setting of your SET REPROCESS command.<br><br>DISKSPACE problem.&nbsp;&nbsp;Remember Ver2.6 is now over 10 years old.&nbsp;&nbsp;&nbsp;NT did not have space limits in thier operation system back then.&nbsp;&nbsp;Also at one time FPW could not read a hard drive large then 2gig.&nbsp;&nbsp;The new drives have on Board BIOS systems that tend to fake out the older programs.&nbsp;&nbsp;The formula DiskSpace used back then to get the diskspace does not apply to the new larger hard drives. <p>David W. Grewe<br><a href=mailtoave@internationalbid.net>Dave@internationalbid.net</a><br><a href= > </a><br>

 

[AbleA]

David - thanks for your prompt response.&nbsp;&nbsp;So no solution, I guess.&nbsp;&nbsp;Does VFP also have this RETRY problem?<br><br>In reply to your question, I use SET REPROCESS TO 5 SECONDS so that there is a chance of the system sorting itself out before the user has to make a decision whether to retry or abort.&nbsp;&nbsp;However, I believe this only affects behaviour when a lock is in place and so isn't an issue here.&nbsp;&nbsp;Correct?<br><br>Thanks again for your help. <p>Andy Blay<br><a href=mailto:a.d.blay@talk21.com>a.d.blay@talk21.com</a><br><a href= > </a><br>

 

[dgrewe]

VFP has the same problem with the retry command.&nbsp;&nbsp;I have been able to bypass the problem with<br><br>procedure errortrap<br>gnerror = error()<br>return<br>******<br>in main app<br>gnError =0 <br>on error do errortrap<br>copy xxx to yyy<br>if gnError &gt; 0<br>*****<br>endif<br><br>I have not tried this with 2.6 yet.&nbsp;&nbsp;Let me know the outcome<br>My REPROCESS is set to 10 because I do a lot of FTP transfers <p>David W. Grewe<br><a href=mailtoave@internationalbid.net>Dave@internationalbid.net</a><br><a href= > </a><br>

 

[AbleA]

David - thanks again for your response.<br><br>I'm not sure your solution is easily applied to my situation.&nbsp;&nbsp;To undo a failed, and possibly partial, record save due to lack of disk space, I would presumably need to restore a table's files from previously-saved backup copies.&nbsp;&nbsp;This sounds like a clumsy process, with the possibility of disk space errors and other users' record locks interfering at every stage.&nbsp;&nbsp;Maybe I've overlooked something?<br><br>I suppose the real solution is to prevent a lack of disk space from occurring in the first place.&nbsp;&nbsp;Does VFP6 have a disk space function that works with modern space allocation regimes?&nbsp;&nbsp;Note my previous comment that even Windows NT Explorer ignores space restrictions (on both Novell and NT servers).&nbsp;&nbsp;Interestingly, I'm pretty sure that Windows 3.1 File Manager DID recognise Novell space restrictions!&nbsp;&nbsp;Could our network or workstation setup be incorrect?<br> <p>Andy Blay<br><a href=mailto:a.d.blay@talk21.com>a.d.blay@talk21.com</a><br><a href= > </a><br>

 

[dgrewe]

I'll bet you have spent more Dollars fighting the problem instead of fixing it. Go compare the amount of your time times Dollars Per Hour of your salary to the cost of a new hard drive.&nbsp;&nbsp;The new WD 30gig hard drives are only $200 and I heard a new 40gig Drive by Seagate was released and goes for $225.&nbsp;&nbsp;This is IDE prices,&nbsp;&nbsp;SCSI are more.<br><br>VFP diskspace function does seem to be more accurate then the FPW version on NT File Allocation Tables.&nbsp;&nbsp;It still seems to have a problem with Novell. It still like to only say there is 2gig free when in fact there could be 25gig free.<br> <p>David W. Grewe<br><a href=mailtoave@internationalbid.net>Dave@internationalbid.net</a><br><a href= > </a><br>

 

[AbleA]

OK, I can live with that.&nbsp;&nbsp;As long as it reports accurately if there is less than 2Gig!<br><br>The space issue itself is quite easy to fix, since it is remote disk space allocated on a network as opposed to free space on a local disk (so I just have to put in a request for more space, and wait!).&nbsp;&nbsp;The real problem is in making my application behave robustly when space inevitably does run low.<br> <p>Andy Blay<br><a href=mailto:a.d.blay@talk21.com>a.d.blay@talk21.com</a><br><a href= > </a><br>

 

[dgrewe]

OK, I See Now.&nbsp;&nbsp;Call it a short circuit between the ears.&nbsp;&nbsp;I failed to pick up on why you were so interested in the Novell disk space limit. <p>David W. Grewe<br><a href=mailtoave@internationalbid.net>Dave@internationalbid.net</a><br><a href= > </a><br>