>Hi Sergey,
>>You know Fabio, it gets annoying that you call a bug anything you don't like
>
>This is a your opinion.
>
>> or don't understand.
>
>This is false, and this is generic way to liquidate the problems.
>
>********************
>
>On specific:
>
>On SQL Server the ALTER TABLE for IDENTITY field it works like I waited for to me.
>
>OK, VFP it is not comparable with SQL Server,
>but if one implements one new functionality, it would have at least to complete it at least in the basic functions.
>
Fabio,

I must agree with Sergey and the others. The autoincrement field was designed to emulate the SQL Server identity column. Simply because it doesn't completely match the behavior of SQL Server doesn't make it a bug.

I don't want the VFP team to be working on things like this. This is something I can fix for myself. To me, comparing native VFP tables with SQL Server tables is like comparing apples and oranges. They're simply not the same. VFP is ISAM based, SQL Server isn't.

What the VFP team has done is allowed us to more transparently port existing VFP applications to an SQL Server backend. One of the most important things in doing so is the concept of surrogate primary keys. Additionally, there's the concept of dealing with a data set as opposed to a file. These are the reasons that the autoincrement field exists in the first place. If I design to a ISAM type data file, and then have to change it over to a set based system, then resolving issues like these are my problem. I shouldn't expect the VFP team to resolve them for me.