Vlad,

These are very valuable points, but they are not 100% applicable in this situation. The table is part of Database and it contains 206 fields. It might be empty table or contain only 65 records, but neverless it crahes VFP each time. I'll forward you the message, Dragan sent me with the test table to try, if you would like to see this problem.

>Hi Nadya!
>
>This is indeed a strange problem that seems even MS do not know answer for sure.
>
>In certain threads (have no time to search now - the most recent was about SCAN ALL failing) there were posts about the weirdnedd of the VFP when processing a large data table within a single VFP command. For example, REPLACE ALL command can sometimes fail at some record or at some moment (first my personal experiense for such problem was with this command). The most weird is that table is not corrupted, there are enough memory for VFP and for system, and there were no reason to fail.
>
>When talking about your issue (changing of field to be not null), it seems it is the same kind of weirdness - failing when processing large number of records in a single command. Well, I see reason why VFP process all records of table when they're marked to do not accept nulls - it just check if any record in the table contains null values (when contains, uses default value, as far as I know). The fact is that it scans all records.
>
>There are a suggestions that this seems related to the VFP internal memory management functionality, because often "Out of memory" error is thrown in such case with no reason.
>
>The solution for all such kind of errors is to split long process to chunks, say, 5000 or 10000 records. In your case it will require instead of use of ALTER TABLE command create a table with the same structure (but required fields accept no null values), then use COPY command or APPEND FROM command with NEXT XXXX clause to copy by chunks in a loop "while !eof()". Between each chunk processing use FLUSH, sys(1104) and whatever else required to force all data processed to be written to disk and to make proces more reliable from the internal VFP memory management point of view. Sometimes, playing around memory management functions related to internal VFP buffers can help too.
>
>See if this can help.
>
>>Sergey,
>>
>> This whole idea started from the following. My colleague wrote a DeNull program. This programs opens table exclusively and if field allows NULLs, changes it to not allow them. It doesn't check, whether file contains NULLs or not. First of all, this process may be slow on the huge files. Secondly, all of the sudden I had VFP crash today several times when it was running this program. It worked just fine few days ago, so I had no idea, what may cause this crash...
>>
>>
>>Wait a minute! I think this file doesn't contain records, so ALTER table may cause crash. I'll check...
>>>>Hi everybody,
>>>>
>>>>Suppose, you have a file with 20000 records. Is there a way to check, if field contains NULLs or not for the whole file except for scanning through it and check each field, which would be time consuming...
>>>>
>>>>I just thought about another idea: select sum(iif(isnull(field1,1,0)) as Field1NullsCnt, etc.
>>>> but it would be slow too...
>>>>
>>>>Do you have other suggestions?
>>>
>>>

SELECT COUNT(*) As TotalRec, COUNT(filed1) As NotNullRec ...
>>>or
>>>SELECT COUNT(*) - COUNT(filed1) As NullRecCnt ...

This way you can even count nulls in more than one column.