1. На сервер базы данных из клиентской программы, написанной на VFP посылается через SQL pass-through (команда SQLEXEC) пакет, состоящий из команды вставки одной записи в таблицу BOOKS.
2. Для отсылки команды используется дескриптор соединения nCON
3. Автор реализовал собственный обработчик результата работы команды SQLEXEC через функцию ErrServ, которой передает в качестве параметра результат работы команды SQLEXEC - nAnswr и саму команду - StrSQL.
4. Вставляемые в таблицу значения передаются в команду SQLEXEC через параметры, о чем свидетельствуют знаки '?' перед переменными. Для собственного обработчика ошибок это не очень удобно.
Лучше бы строку StrSQL "собирать" прямо:
StrSQL=[INSERT INTO BOOKS(ID, Author, Edited) VALUES (] + CAST(NewID AS V(10) + [, '] + ALLTRIM(zAuthor) + [', '] + ALTRIM(zEdited) + [')]
Тут я полагаю,что NewID - INTEGER, а zAuthor и zEdited символьные поля и работа ведется в VFP 9.0.
В этом случае в функции ErrServ, при ошибки, в ЛОГ-файл можно будет записать полный текст команды, которая привела к ошибке, а не очень информативный текст типа "..?NewID..."
5. Если SQLEXEC настроена на работу в асинхронном режиме, то это все в корне не верно. Надо после SQLEXEC проверять, а закончилось ли выполнение команды SQLEXEC... , и только при ее окончании уходить на обрабтоку ошибки.

С уважением, Алексей
P.S. Совсем не факт, что SQLEXEC выполняется именно на SQL Server, т.к. не известно, как был получен дескриптор соединения nCON.

FM32YO aka KID Вы ни в коем случае не должны вот так вставлять в таблицу....
уникальный номер должен сервер генерить???
И, тогда не будет у вас проблем с констрейнтами
А откуда вы знаете, что ID - это PK таблицы BOOKS?!
Скорее всего, это ссылка на какой-нибудь справочник, а ее (BOOKS) cобственный ID генерится через, например IDENTITY (UNIQUEIDENTIFIER, триггер и пр.) при INSERT.
С уважением, Алексей.