>>>>Hi,
>>>>I have an FPW 2.6 application that works fine as a stand-alone on o local drive running NT 4.0 Workstation. After moving it to a Novell LAN drive, I get the error message 'Not enough disk space' when trying to ZAP a file. The Help contents for this error state that Novell may return this message erroneously if a file has no owner, but checking the files with NDIR shows me as the owner. Does anyone know how to fix this?
>>>
>>>There are a couple of causes for this, and more than one sure-fire workaround.
>>>
>>>The causes relate to how Novell computes free space, and how much free space is available. FPW uses a Win16 call to get the amount of free space from the server, and stores the amount of free space as a signed integer; if the free space is >2GB, it gets a negative number.
>>>
>>>The sure fire workaround is not to use ZAP; DELETE ALL followed by PACK will accomplish the same thing and rebuild your indexes automagically (albeit, slowly.) If you know how all the indexes for the table are built, COPY STRUCTURE can duplicate the DBF structure to another file; erasing the table (and any .FPT and .CDX associated with it) followed by renaming the temporary copy made with COPY STRUCTURE and rebuilding the index files from scratch is faster.
>>>
>>>I haven't used FPW in quite a while; if the WITH PRODUCTION clause is supported under FPW, the following will work, too:
>>>
>>>

>>>cMyTableToZap = 'MYTABLE'
>>>USE (cMyTableToZap)
>>>COPY STRUCTURE TO TEMP WITH PRODUCTION
>>>USE TEMP
>>>COPY TO (cMyTableToZap) WITH PRODUCTION
>>>

>>Better yet
>>USE yourtable
>>COPY STRU TO tempfile PROD && Copies table structure and cdx
>>USE
>>RENAME FILE yourtable.dbf to oldtable.dbf
>>IF FILE('yourtable.cdx')
>> RENAME FILE yourtable.cdx to oldtable.cdx
>>ENDIF
>>IF FILE('yourtable.fpt')
>> RENAME FILE yourtable.fpt to oldtable.fpt
>>ENDIF
>>
>>RENAME FILE tempfile.dbf to yourtable.dbf
>>IF FILE('tempfile.cdx')
>> RENAME FILE tempfile.cdx to yourtable.cdx
>>ENDIF
>>IF FILE('tempfile.fpt')
>> RENAME FILE tempfile.fpt to yourtable.fpt
>>ENDIF
>>
>>*Then delete old* after verified
>
>I'm just curious how this is 'better'. What verification steps do you perform to check the integrity of the new, empty data table and structural .CDX? Any exhaustive check means you have the table structure and index definitions, in which case, CREATE TABLE followed by a set of INDEX ON statements is appropriate, and failure of the ZAP operation is completely non-disasterous, since if a bad table resulted, you'd know how to build a new, empty one from scratch. There's no data to check; ZAP creates an empty table, and there's no .DBC metadata to protect, since it's FPW. If the COPY STRUCTURE...WITH PRODUCTION fails in the first step, then when you go to USE the created table and index in the next step, the USE statement or the second COPY statement will fail.
>
>If you wanted to verify the results of the COPY STRUCTURE...WITH PRODUCTION operation, you could do the exhaustive checks after each COPY copy completes, and repeat the COPY operation or back out as appropriate. In your code, I'd want to do the verification before the RENAME operations to ensure a valid table and indexes before adding RENAME into the equation; checking before renaming means that there's no need to RENAME back afterwards if the initial COPY STRUCTURE...WITH PRODUCTION failed.
>
>I would assume that anyone who issued a ZAP had already determined that they wanted the data to go away, since ZAP isn't reversible.

Ed,
I was responding to your suggestion to DELE ALL and PACK. That, in itself, requires available disk space, that apparently John did not have available, and as you noted it can be very slow for a large file. Also, I must've not seen the second suggestion that you posted. I guess that it must have been off screen and I thought that the previous paragraph was the last in your msg so I didn't bother to scroll on down. In anycase, by renaming the files before deleting them, the files can be easily recovered (for whatever reason) using NOVELL's utilities (assuming that a netware purge files has not been issued). I don't know about you, but there have been times that I wished that I had not ZAPped a file. As to the verification of the data structure and index integrity...of course you can create checks to do that, but that was not the issue here.
//:^)