Odess писал:На таких объемах в лучшую - вряд ли. Тормоза будут просто офигительные. На некоторых вариантах замедление будет в десятки раз. Будут, но не везде (всё зависит от того. как было написано приложение)
Odess писал:Кроме того многие работающие в акцесе запросы выдавали совершенно другие результаты! Это врядли. Скорей всего проблема из за непропатченного Jet.

Odess писал:Можно, конечно большинство запросов переписать как запросы к серверу, но времени это займет не намного меньше, чем переезд под ADP.Нет, не больше. ADP - переписать всё с нуля, MDB - переписать критичные вещи. Конечно, для нашего программиста всегда есть особый соблазн переписать всё это нафик с нуля и правильно (особенно если писали прогу до него другие), но не всегда это оправдано.

Но ещё раз повторюсь - многое зависит от того, как написано существующее приложение, поэтому в твоём случае правильный ответ на вопрос даст лишь тестирование твоего приложения в новых условиях. Дерзай.

Odess писал:Если использовать DAO, то тормоза будут в любом случае. Вытаскивание, к примеру, 1 млн записей из таблиц на SQL по сетке будет однозначно дольше, чем через JET. C ADO в таком варианте я не работал - врать не буду. Я и грю - многое зависит от приложения, ну яж не знал что тебе надо млн. записей таскать. Врядли же случаи, когда это необходимо составляют больше 80% случаев работы с базой?! Да, в тех случаях, когда надо обрабатывать большой объем данных - надо будет переписать это на SP. Но это как раз те критические места, о которых я говорил, и которые выявятся в процессе тестирования решения.

Odess писал:Так вся проблема в том, что запросы ПРАВИЛЬНО работали до пропатченого JET и после оного. А при работе с подключенными таблицами через ODBC выдавали абсолютно неверные результаты! Я таки разобрался в ошибках - неправильные объединения (с точки зрения скуля) и т.п. - но в акцессе они работали! Объединения из Access SQL в SQL Server SQL транслирует драйвер ODBC. В нем также могут быть проблемы. Почему я сказал про Jet - вот одна из известных проблем: LEFT JOIN работает как INNER JOIN
На своём опыте скажу что да, вынужден признать что были пару запросов которые просто отказались работать, хотя были абсолютно корректны, ошибка была в том, что ODBC драйвер их некорректно транслировал (забывал некоторые табл. в ключать в выражение FROM и т.д.). Эти запросы пришлось переписать.

Odess писал:переход от хранения данных в MDB файле к SQL серверным таблицам в лоб может не только замедлить работу проекта, но и привести к ошибкам в результатах. Т.е. к этому нужно быть готовым и не видеть в SQL сервере панацею от всех бед... Согласен, может затормозить (большая вероятность) и привести к ошибкам в результатах (допускаю), и вдвойне согласен что об этом надо знать, начиная перевод, но само знание не может являться категоричной причиной совсем не использовать данных подход. Определять это надо тестированием.

Odess писал:В моем случае оказалось проще переписать с нуля, хотя проект изначально делал я. Согласен, яже и говорю - случаи разные бывают.
И ещё раз скажу - многое может показать тестирование .

Про таймер.
А никто не натыкался на глюк, когда при использовании такого рода таймера изредка Access печатает эту форму с таймером вместо отчета, когда печатаешь его из режима предварительного просмотра?
Acc97.