What a coincidence! Exactly this problem yesterday caused an error in an application and I did the repair today.

However, it is not a bug. Read what the Help text says about ALTER TABLE:

ALTER TABLE may not produce consistent results when used with Visual FoxPro cursors created using the CREATE CURSOR command. In particular, you can create a Visual FoxPro cursor with features (long field names, for example) that would normally be available only with tables that are part of a database container. Because ALTER TABLE saves a temporary copy of the cursor, the rules that apply to free-tables then apply, and any features requiring database support are lost or changed in an unpredictable manner. Therefore, as a general rule, you should avoid using ALTER TABLE with Visual FoxPro cursors unless you have tested and understood the outcome.

The problem indeed arises if it's a cursor and any fieldname is longer than 10 characters.

My workaround is that I copy the content of the cursor to a temporary table, then do the ALTER TABLE, then copy the table back to a cursor and delete the remains of the table.

I guess, it's also safe to copy the content of the cursor to a temporary table, then copy the table back to a cursor, then delete the remains of the table and finally do the ALTER TABLE.

select * from [cursor] into table [temppath+tempname]
alter table [tempname] alter column field1 C(10)
select * from [tempname] into cursor [cursor]
use in [tempname]
delete file ( [temppath+tempname] + '.*' )

or

select * from [cursor] into table [temppath+tempname]
select * from [tempname] into cursor [cursor]
use in [tempname]
delete file ( [temppath+tempname] + '.*' )
alter table [cursor] alter column field1 C(10)

>Hi All,
>

>*** this is the first bug *********
>CREATE CURSOR test (shortf c(1))
>
>ALTER table test add long_field_name c(1)
>
>***** this is the second bug *******
>CREATE CURSOR test (long_field_name c(1))
>
>ALTER table test add shortf c(1)
>