авторКхм... Какой такой поток?

типа этот.
если я что не так называю - скажи как надо.
...

что-то мне надо было срочное про таймстамп глянуть - посмотрел, на всем
сайте практически пусто. А у самого руки никак не дойдут до нужного места.

ЗЫ
Это я к тому, что пусть бы было место про таймстамп более или менее
внятное в полноте своего охвата...

Темный - ты автор, тебе и карты :))

Темный BOL: timestamp

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

ТемныйНизафто :) Вот он всплыл, может кто-нить ответит
на какой вопрос-то ответа ждешь?

ТемныйНа оба :) Но второй интереснее.
на второй вопрос на форуме отвечалось много раз.
поиск наверно, по "линкованным таблицам" вести.
приблизительно ответ будет такой.

повторное подключение организовывается для того, чтобы гарантировать
выполнимость MoveNext на на открытом рекордсете.
( То есть в момент, когда MoveNext понадобился, подкючение не заблокировано фетчингом для другого набора данных).

Это общее поведение для линкованных таблиц, и распространяется оно не только на ОДБС- подключения, а вообще на все виды линкованных таблиц.
По этой же причине размножаются подключения в АДП-проектах.

применительно к первому вопросу
так ты как будто сам только что показал, как БОЛ сыскать...
:))
таймстамп - поле специального вида - 64-битное целое, фактически глобально нумерующее апдейты/инсерты по крайней мере для тех таблиц, в которых присутствует поле этого типа. Сервер берет на себя ответственность самостоятельно производить изменение этого поля при любом изменении записи, и гарантирует, что изменение значения поля типа таймстамп будет произведено.
В стратегии оптимистической блокировки - проверка ранее вычитанного значения этого поля с текущим для записи с указанным ключем -это самый эффектвный, по существу единственный универсально поставляемый сервером "встроенный" механизм проверки факта неизменности записи с момента ее последнего чтения.
В АДО-рекордсете есть динамическое свойство "Update Criteria", которое как раз управляет механизмом обнаружения конфликта записи. Одно из значений - adCriteriaTimeStamp=3 - как раз и заставляет использовать timestamp как метку синхронизации.
При наличии такого поля в таблице клиентскому слоя как правило хватает ума использовать его для решении вопроса о синхронизации.
однако для решения вопроса об обновляемости набора данных этого может быть недостаточно, поскольку в решении вопроса о том, удалена запись или нет, клиентский слой предпочитает опираться на первичный ключ. И, если для линкованной таблицы ключ не указан в момент линковки, и ОДБС не может определить его самостоятельно, то, скорее всего, набор окажется необновляемым независимо от присутствия поля таймстамп.


ЗЫ
что умел - сказал.
пусть другой скажет лучше.

ЗЫ2
может и для меня чего хорошего напишут...
:))

ТемныйБуковок много. Вечером почитаю внимательнее.
НО! По второму вопросу: 2 соединения - это еще ничего. Но когда их 4 - это уже перебор.
И про АДП мне совсем не понравилось.

Применительно к ОДБС - фактически подключения кешируются самим ОДБС.
Количество фактически открытых тобой наборов в данный момент может (и как правило) быть меньше.