Vlad Khorsun wrote:
Может у мну (с) крынка резиновая, но никогда на это не напарывался.
Может я не тяну сотни тысяч на клиента (отчёты делаются другими ср-вами) ?
Единицы и, возможно, десятки тысяч пролетают без заметных проблем (редко,
но иногда бывает и такое).
Десятки тысяч не проблема. У меня в филиальской briefcase справочной
подсистеме десятками и тягается. С тех пор, как наладил репликацию
изменией в базовых справочниках и сборку визуализации на месте из
засасываемых оперативных числовых данных и названий в локальной базе,
вполне шустренько так летает. А вот спервоначалу, когда отправлял туда
резалтсет джойна из центра, в какой-нить Тюмени на модеме минут 40 могло
грузиться. То есть, к работе с кеширующими фулл фетч датасетами в общем
случае надо технологически подходить не как к клиент-серверу. А это не
всегда хорошо. Про работу с миллионными архивами, которые в
клиент-сервере до конца вообще практически никогда не дофетчиваются, я
уж молчу. И никаких специальных приседаний с IBX/FIBPlus для этого не
надо, технология на это и заточена. Наоборот, надо приседать, когда
нужны отступления от этой технологии. Мы с тобой приседаем при помощи
CDS, а Серж строит настраиваемые гибриды с локальными
сортировками-фильтрациями. Мне кажется, что правильней иметь и молоток и
гвоздодёр отдельно и хвататься за то, что нужно в конкретный момент.
парцайками тягать муторно. Правда меня это тоже отродясь не волновало,
ибо с малолетства разделял пишущие и читающие транзакции. Лично мне
У меня это тоже две разные тр-ции. Но только для того, чтобы дать им
(возможно)
разный набор параметров, а не для обхода проблемы закрытия датасетов.
У меня этой проблемы вообще никогда не было. Основное чтение в
единой транзакции по умолчанию r_c read, открывающейся на запуске
приложения и закрывающейся на выгрузке, запись в коротких по месту
снапшотах, с прдварительным рефрешем в них именно модифицируемых данных,
если нужно. И фсё.
текущее поведение внучков Грегори представляется более логичным и
простым в использовании чорным ящиком, нежели борьба с недофетченными
курсорами, невалидными дбкеями и, пожалуй, для человека неискушённого,
отсутствием конфликтов модификации там, где они должны быть. Может,
конечно, дело привычки...
Поведение _может_ быть настраиваемым, но не _должно_ быть железобетонно-
непробиваемым в стиле : "ты туда не ходи, ты сюда ходи... и только сюда"
См. выше про молоток и гвоздодёр :)
Я, с точки зрения пользователя компонент, не вижу ничего логичного и
простого в
закрытии всех датасетов по окончании тр-ции. Наооброт - это приводит в
недоумение
и заставляет _бороться_ с компонентами\сервером вместо решения моих
собственных
прикладных задач.
Не вижу в упор борьбы, если разделять транзакции. И Серж в плюсах это
сделал, и Алекс для нас в IBX, причём ещё более радикально, можем на
каждый ...SQL отдельную закатать. А раньше мы просто не пользовались
технологией Edit-Post, а выполняли модификации автономными запросами. Да
и сейчас преимущественно так.
--
Regards. Ded.
