Hi Fabio,

I always believe that it's bad idea to use zero or empty as a valid key value. It's a problem with your design not VFP handling of null values in the remote views.

>Hi Sergey,
>
>Table1
>
>id TINYINT identity(0,1)PRIMARY KEY -- I WANT USES FULL SQL RANGE NUMBERS
>tx VARCHAR(40)
>
>Table2
>
>id TINYINT identity(0,1)PRIMARY KEY -- I WANT USES FULL SQL RANGE NUMBERS
>tx VARCHAR(40)
>
>Table_Data
>id INT identity(MININT,1)PRIMARY KEY
>....
>id_Table1 tinyint NOT NULL -- NEED VALUE !!! SQL DATABASE STRONG NATIVE RULE
>id_Table2 tinyint NOT NULL -- NEED VALUE !!! SQL DATABASE STRONG NATIVE RULE
>....
>
>I EXEC "SELECT*FROM Table_Data" FOR BUILD LOCAL CURSOR.
>On local, i append new row for user editing:
>INSERT ... ...
>id ???? don't have value, any new value can be mistaken.
>id_Table1 ???? don't have default value.
>id_Table1 ???? don't have default value.
>
>I want one intrinsic coherence.
>If I do not have a value, then it is NULL.
>I do not want trick/track/truck....
>Any trick is one logical lie, any logical lie is the seed of a bug.
>
>fabio