Sandy, ignoring the disk space problem, which Cetin and George et al. have addressed, why don't you append into an INDEXED cursor? That way your cursor would be ordered. You can then do a copy to, a SQL or other manipulation relatively quickly to get the final output ordered correctly but not indexed.

HTH
Barbara

>Cetin,
>What I didn't make clear is that in the load of the form, I use a
>CREATE CURSOR command. After the user selects a file name with
>GETFILE(), I use the APPEND FROM to imput the ascii file. After
>Some data manipulation, I have to decide if I can create an ordered
>table with an SQL command or simply create the table with a COPY
>STRU command and get the data inside the new table. I then close
>the new table and turn on another application with then uses it.
>
>The reason I need to order it is that the other application will
>use the table for 21 hours if unordered, if ordered, it cuts it
>down to 12 hours.
>
>By the way, the other app doesn't recognize indexes.
>
>>Sandy,
>>I want to warn you about a thing. Under FAT 32, (which is an option with win 95b and will be default for win98) sys(2022) and corresponding WinAPI call return wrong info and you may calculate 8 times more than actual diskspace.
>>There is a thing I couldn't understand in your question. You can first SQL to a cursor, then write to table if diskspace is enough ? In fact a cursor (if a true cursor) also use diskspace so it would also fail if diskspace isn't enough (of course with the assumption temp drive is same as table drive). And if "into cursor" finishes successfully you already have the table, you may not want to do a second pass. Table is kept on disk as dbf(tcCursor). Undelete and rename could save time on a table that much large. Secondly, if you think closing a cursor and reordering would be a problem with disk space, I would use a view. It wouldn't get lost until you drop it.
>>Cetin
>>>BRILLIANT!!!
>>>
>>>Thanks
>>>
>>>As for the what to do if I don't have the room to order the table, I guess I'll
>>>just have to scan - scatter memv insert into newtable - endscan
>>>
>>>Sandy
>>>
>>>>>Hello All;
>>>>>I'm having a problem with my table sizes. I'm dealing with tables that are up to or more than 1 gig. At one point I need to decide if I can order to the table i.e "SELECT * for mytable order by my keyfield into table new table"
>>>>>
>>>>>Since the table is a cursor, I cannot use FSIZE() to determine it's size, so I have a FOR loop that determines that size of 1 record and then I multipy it by reccount() * 3. This value I compare with DISKSPACE(SYS(5)). If DISKSPACE is greater, then I run my SQL.
>>>>>
>>>>>The problem occurs if the cursor size is too big. I need this data to sit in a table with a different name. If I close the cursor, the data is gone!! I can't SQL it into a new table.
>>>>>
>>>>>Any ides are welcome!!
>>>>>
>>>>>Sandy
>>>>Just an addendum to my other post. You can pre-calculate the number of records that will be returned using either COUNT()...FOR... or by using an SQL statement to determine how many records will meet the necessary conditions.
>>>>
>>>>Also, look at SYS(2022) which will return the cluster size for the drive in question. You should use somthine like:

>>>>* Note, pass the drive letter to SYS(2022)
>>>>* if it isn't the default
>>>>lncluster = VAL(SYS(2022))
>>>>lnsize = CEILING(lnsize / lncluster) * lncluster

>>>>to determine the actual amount of diskspace to be used.