Вновь прошу помощи.

при сбросе подключения пропадают записи, счетчик тикает с учетом пропавших записей.

Microsoft SQL Server Management Studio 9.00.3042.00
Клиентские средства служб Microsoft Analysis Services 2005.090.3042.00
Компоненты доступа к данным (MDAC) 2000.086.3959.00 (srv03_sp2_rtm.070216-1710)
PHP Version 5.2.17

Ситуация следующая (проект рабочий), везде заходим из под одного и того же пользователя, в системе присутствуют модули работы с данной таблицей, которые работают нормально, при этом обращение к таблице идет через один и тот же класс (подключение, выполнение запроса, отключение):

1. PHP скрипт отрабатывает обращение к базе инструкцией INSERT,
2. после чего в том же скрипте выполняется проверка существования записи (так на дурака), которая показывает, что запись существует, при этом возвращает ее ID, скрипт завершен.
3. Далее соединение разрывается.
4. В другом скрипте, формируется соединение, производится попытка поиска сформированной строки - результат строка не найдена.
5. Входим из под Microsoft SQL Server Management Studio - формируем точно такой же запрос, который выполнял проверку на 2 шаге - результат строка не найдена.
6. из под Microsoft SQL Server Management Studio формируем запрос INSERT, который отрабатывался на 1 шаге
7. из под Microsoft SQL Server Management Studio просматриваем базу - строка шага 7 существует, ее ID на 1 более нежели результат на шаге 2.
8. разрываем соединение и выходим из Microsoft SQL Server Management Studio
9. Входим из под Microsoft SQL Server Management Studio, просматриваем базу - строки созданные на всех вышеописанных шагах отсутствуют, при этом их индексы не посчитаны не в общем количестве записей, не в порядковом коде, при этом очередное добавление записи учитывает прирост индекса на всех описанных шагах.

попробую описать ситуацию примером:
исходное состояние таблицы, 1 запись с индексом 1
PHP > соединение => INSERT .... => SELECT id FROM ... => результат 2 =>разрыв соединения
PHP > соединение => SELECT id FROM ... => результат 1 =>разрыв соединения
Microsoft SQL Server Management Studio > соединение => SELECT id FROM ... => результат 1 => INSERT .... => SELECT id FROM ... => результат 3 =>разрыв соединения
Microsoft SQL Server Management Studio > соединение => SELECT id FROM ... => результат 1 => INSERT .... => SELECT id FROM ... => результат 4 =>разрыв соединения

голову уже сломал, конечно же в рабочей таблице не одна запись, а более 100 тыс. записей, пробовал все эти действия на развернутой копии, там все работает нормально, ненормального поведения не наблюдается. следовательно делаю заключение, что все та-ки это не логика, на таблицу навешаны триггеры, ключи, ограничения и индексы, все проверял. В ограничениях заданы значения по умолчанию (бред но это так), все записи ключей, касаемые создаваемых записей существуют, в триггерах операций удаления не присутствует, триггеры вообще не видоизменяют текущую таблицу, просто формируют записи в других таблицах).

подскажите что может быть, кто-то сталкивался с таким ?

Пока читал, появилось несколько вопросов (предложений):
1. Проверь количество записей до вставки и после вставки, в первом скрипте.
2. Проверь количество записей в таблице во втором скрипте (п.4 у тебя).
3. Проверь триггеры вставки, что именно они возвращают. Прямо по тексту триггеров смотри. Они должны вернуть, насколько я понимаю, вставляемую строку. У тебя там нигде нету, случайно, RETURN NULL? В то же время должно быть, как я понимаю, RETURN NEW (по аналогии с другими БД сужу) или что-то подобное.
4. MSSQL - платная БД. Если ты купил ее законно (или твоя организация) , то пинай мелкософт А если не купил, то переходи на бесплатную БД, например PostgreSQL.

_____________
* Хэлп по PHP
* Описалово по JavaScript
* Хэлп и СУБД для PostgreSQL

* Обучаю PHP, JS, вёрстке. Интерактивно и качественно. За разумные деньги.

* "накапливаю умение телепатии" (С) и "гуглю за ваш счет" (С)

sergeiss,
Количество записей до и после вставки в обоих случаях показывает, что запись вставляется. И такое впечатление, что запись теряется после сброса подключения.

триггеры: они вообще с текущей таблицей не работают, в них нет оператора RETURN (я так понимаю, что в отношении текущей таблицы это и будет RETURN NULL)