Hi!

>>>As about the updatable ID, you require to query it properly. ID used to find the record on SQl Serevr when updating data, so when it is incorrect, you will not be able to update record, or will update incorrect record because incorrect ID.
><<
>
>When I requery the view, I get the VFP Update Conflict error message. Once again, the ID number field contains the value of the ID of another table!
>

You will not be able to require until there are pending changes in the view. In addition, when you browse the table, record pointer changed, and with Buffering=2 or 3 the tableupadate() is issued by VFP automatically as soon as you do cartain thing such as record pointer move. Thus you cannot browse or requery until the update will be successful, or you tablerevert() the changes in the view.

>>> In addition, when you add new records, ID require to be corrcetly generated or should be downloaded from server. For example, you insert record, update, SQL Server generates a new value for ID. Than, next time you try to update, ID field is emty on the local computer, so you cannot update or delete that record any more, because you do not know the ID. In such case you can requery the view, or get th last ID number from the SQl Server. This is a long complex story and you can read about this here at UT in many thred or somewhere else.
><<
>
>Hmmm... I am going to study what you said. I am not sure I understand it The ID field in the Remote View is an integer identity field I created in SQL Server Enterprise Manager. So SQL-Server is doing the updates to it.
>

Yes, but these updates are not visible by VFP, until you query them from SQl Server. Usually, query from SQl Server like 'SELECT @@IDENTITY' is enough to get the ID value of the identity field from the last INSERT command in the SQL Server connection session. For example:

Select MyView
if '3' $ GetFldState(-) or '4' in GetFldState(-1)
  && new record
  m.lResult = tableupdate(...)
  if m.lResult
    && get the identity key value
    select 0
    SQLEXEC(CursorGetProp('ConnectHandle','MyView'),'SELECT @@IDENTITY as IDValue','ID_Cursor')
    if used('ID_Cursor') AND !IsNull(ID_Cursor.IDValue) AND !empty(ID_Cursor.IDValue)
      select MyView
      replace MyView.ID_Field with ID_Cursor.IDValue
      && if ID_Field in the view is not marked as updatable, there are no other changed fields in 
      && the view for following tableupdate(), so real update command is not sent to the
      && SQL Server, we just assure by it that GetFldState(-1) returns all '1' for all fields.
      tableupdate(...)
    else
      && we were not able to get correct ID value, so we just can requery and hope
      && that the last record in the requery result is our new record added, that is not true 
      && often
      requery('MyView')
      go bottom in 'MyView'
    endif
  endif
else
  m.lResult = tableupdate(...)
endif

Above way you assure each new record added after successful updating will contain correct ID value. It is not a reliable way though. When you have an Insert trigger for table on SQ Server, and that trigger do other INSERT commands into other tables, @@IDENTITY variable value on SQL Server will be spoiled, so you will get incorrect ID for another INSERT. In such case you require to use another approach for records identification, such as GUID (unique identifier) field type, or your special SP, or common identity-generating table queried from the client or used by insert trigger for each SQL Server table.

HTH.

>Thanks,
>
>-pw