<>Клиент: win xp prof, access 97, odbc драйвер от 31.01.2006
Сервер: freebsd, postgresql 8.1

Прилинкована таблица, след структуры:
таблица на сервере' ...
' datetimerec timestamp without time zone NOT NULL DEFAULT ('now'::text)::timestamp(6)
...

При прямом тыке в прилинкованную таблицу, возможно только добавление новой записи, при редактировании (или удалении) получаю ошибку:
errorThe Microsoft Jet database engine stopped the process
because you and another user are attempting to change
the same data at the same time.


1. Если отказаться от использования поля datetimerec (служебное, по умолчанию пишется now()), то проблема пропадает.
2. Если работать не на прямую с таблицей, а чере запрос (исключить это поле)
тоже все ок.
3. Программно через дао, также все хорошо

Пока остановился на создании запросов. Но мне кажется, что вопрос в недокрученных настройках odbc и есть более прямой путь. Может быть кто сталкивался, или сможет проверить данную связку у себя?

Спасибо.гм. поиском вы найдете мои (ass/4321) изыскания на эту тему. заменил тип таймстамп на старый abstime - так как он соответсвует по точности аксовскому datetime (float) - чтобы не переписыват имеющийся в аксе функционал. Боюсь, что проблемма может оказаться даже не в ОДБС, а в конверсии в аксовский тип в гриде и обратно. (потеря точности, и запрос типа АПДЕЙТ ... ГДЕ {весь перечень полей и значений} не попадает на таймстамп _точно_). Это надо смотреть очень точно кто из акса и одбс отвечает за OldValue (их точность).

<>...еще одна радость

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

Линковку в сад, только запросы к серверу

(ссори если офтоп)гм. ничего не понял.
распишите - что на стороне сервера, что - на стороне акса. (у меня линковка вродеба работает, хотя были некие проблемы поначалу).

<> assaгм. ничего не понял.
распишите - что на стороне сервера, что - на стороне акса. (у меня линковка вродеба работает, хотя были некие проблемы поначалу).
Похоже я погорячился немного и ф-я не виноватая нифига. А проблема была такая:
если открыть (кликом) одну из прилинкованных вьюшекмедленно начинаю понимать. Вы линкуете вьюхи. А нафигас (вычислять вычислимое можно и на клиенте)? Или вы их делаете обновляемыми? Впрочем , это вопрос, скорее, в сторону. Работать-то обязан, если уж подписался.

PS а "уникью" (эффективный ключ) для вью вы задавали!!!????

<> , то до тех пор, пока не отсортировать (отфильтровать) записи в ней, то кажет все корректно. После сортировки (фильтрации) по любому из полей, одно из полей содержит одно значение для различных записей, хотя реально в каждой записи свое уникальное значение, т.е. было:
id value (real)
1 1,23
2 2,34
3 4
4 3
2 5,55
3 12
фильтрую (сортирую) по id=2 получаю:
id value
2 2,34
2 2,34
кхм. забавная бага. можете ли привести тестовые простые скрипты, чтобы посмотреть на это замечательное поведение? (имхо, клиентская фильтрация/сортировка производится чисто джетом, где он теряет порядок полей в наборе - крайне неясно. разве что попробовать запустить лог ОДБС и попробовать почитать - не просылает ли акс через ОДБС новый набор запросов при требовании отсортировать данные вьюхи, и, если да - то каких именно.

<>если пробежатся по рекордсету прилинкованной вьюхи, типа
таже фигня ну это и понятно. тут джет точно также взаимодействует с ОДБС, как и при работе с гридом с линкованной таблой

<>если делать через запрос к серверу, типа

то все хорошо...гм. вопрос: а если в грид воткнуть "запрос к серверу" (к тому же вью) - то набор фильтруем? или уже нет? (простите, ленть проверять). (проверил, получилось что набор (не вью, а SELECT * FROM ф-я - SETOF, что не принципиально) сортируем, и видимо фильтруем (при попытке вызвать бланк фильтра 97 акс упал по системной ошибке. Но, судя по времени пересортировки небольшого набора - похоже сортировка производится не джетом а таки отправкой серверу повторного запроса (лог не подключал, но время сортировки великовато)).


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