Давай сразу определимся: как ты коннектишся к серверу - через ODBC или через OleDB провайдер (можно из Асеss 2000 или Delphi 5.1)? Если через ОDBC то продолжать смысла нет, технология медленная и устаревшая. Если через OleDb, то будь добр, вынеси логику на сервер, и размышления по поводу скорости разных версий Ассеss'oв отпадут. А вот интерфейс у А2K тормозит сильно. И памяти просит много. А насчет примитивности MSSQL - ну я понимаю когда подобные реплики бросает сертифицированный специалист по нескольким SQL серверам (как правило Oracle или DB2 против MSSQL). А тебе могу сказать только одно: изучай продукт.

Для тех, кто есче не понял: проект Access 2000 это не СУБД, а клиент с интегрированными средствами разработки баз MSSQL Server 6.5 - 7.0. Собственно этот самый MSSQL (или MSDE - его порезанная весия) и является СУБД. А клиент бывает тонким, толстым, но про игрушечный впервые слышу.

Согласен.

Именно. Медленная из-за своей универсальности ('открытости'). Устаревшая из=за того, что есть OLE DB. Хотя честно говоря самый быстрый способ общения с сераером - через его собственный (native) API.

Если дергать на С ODBC API то можно получить очень шуструю приладу. Но процесс разработки такой системы сложен и долог и сравним по сложности с работой напрямую с native API. А насчет скорости - попробуй поработать с данными посредсвом любого средства разработки, потдерживающего оба стандарта (Delphi>=5.1 или A2K). Вопрос снимется сам собой. И причем тут прослойка ODBC драверов? И ODBC и OleDB (исключая провайдера для ODBC источников - он оставлен только для перспективы перехода с ODBC на OleDb источник) являются 'обертками' вокруг native библиотек и никак между собой не взаимодействуют. Давным давно Borland'овцы придумалb SQLLink в пику ODBC, а теперь использует и OleDB. Или это не показатель?

Похоже что наша дискуссия теряет смысл. В Books Online указывается, что и ODBC и OleDb драйвера для MSSQL native. Логично предположить, что вызовы аналогичных функций происходят со сравнимой скоростью. НО! Мне, например, никуда эти вызовы не упираются. Мне MSSQL нужен для создания, ведения и сопровождения корпоративной базы. И нет у меня времени, чтобы играть с ODBC или OLEDB API. Сами бизнесс-процессы, логика приложения отнимает такую кучу времени и сил, что мне по сути до лампочки насколько у меня оптимизированы низкоуровневые вызовы. И опять НО! Встает закономерный вопрос: а как быстро разрабатывать клиентскую приладу, не вникая в дебри (если во все вникать, то и С не нужен, теоретически можно писать все на азме или прямо в кодах) и не получить на выходе слабоработоспособную и тормозную поделку?. И тут мелгомягкие и разродились на ADO. ADO базируется на OleDb, предоставляя с одной стороны скоростной доступ к серверу, а с другой - достаточно простые и функциональные средства для разработчика. Для ОDBC аналогичной по скорострельности и функциональности 'обертки' мне неизвестно.

2 AlexeiAN:

>Скорость работы SQL-server-7.0 проверял НЕ по сети, НЕ через ODBC

Сильно. А я, как и команда разработчиков MS SQL наивно пологал, что существует понятие клиентской и серверной net-library, в том числе и Shared memory, через которые осуществляется АБСОЛЮТНО ЛЮБОЕ взаимодействия клиента и сервера. Доступ к клиентской net-library можно получить ТЛЬКО ТРЕМЯ СПОСОБАМИ: используя DB-library, ODBC или OleDB провайдер. Но Вы умудрились обойтись без этого. Поздравляю.

>а напрямую открывал таблицу в SQl-server

Т.Е. клиенту данные не отсылались... А как Вы скорость то мерили тогда? Ну удалось, так удалось. Снова поздравляю.

>Попробовал конвертнуть программу из Access2 в Access2000 и подключить к SQl-server; скорость выборки данных оказалась ниже раз в 15-20, т.е. то, что Access2 делает за 2-3 сек. Access2000+SQL-server делает за 30-60 сек.

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

>Читаю книгу по SQL-server-7.0 (1999 года издания) и чем дальше, тем хуже. Например, написано, что для проведения каскадных изменений в связанных таблицах надо писать триггеры (вообще-то Access2 делает это сам)

Купите книгу по MsSQL2K 2001 года издания.

>Хранимые процедуры надо каждый раз перекомпилировать (добавлять with compile), если в таблице удалены, добавлены или изменены данные (пардон, но это и есть работа в БД!).

Выкиньте эту книгу. Если конечно там прямо так и написано. Хотя я сомневаюсь.

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

Нет, Вам вовсе не недо делать это ежедневно или ежечасно. Можно вообще не Backup'ить. Только при грамотном построении плана резервного копирования (заметьте, полностью автоматизированого!) можно очень быстро откатываться к данным, измененным хоть месяц, хоть час назад (а при желании и 5 мин. назад)

>В Access2 у меня нет таких проблем. Особенно сейчас, когда сменил сетевые карты.

Не надо быть провидцем, чтобы с уверенностью сказать - если вы пытаетесь создать серьезную систему - БУДУТ. По крайней мере никто из мне известных разработчиков на Ассеss без проблем в этом отношении не живет. Ну а если Ваши проблемы заключались в используемых сетевушках, не расслабляйтесь! Еще есть память, процессор, жесткий диск, материнская плата, тупой пользователь и Господь Бох.


2 vitaly:

>Кстати какой размер базы - у меня к примеру 1.5 Gb

В данном случае, на мой взгляд, логичнее говорить о количестве таблиц и количестве записей в них. Хотя от типа и даже расположения полей в записи размер сильно зависит.

>Насчет IDE о вкусах не спорят но я думаю ты к нему привык

Абсолютно с Вами согласен!

2 AlexeiAN:
Неожиданно дшло: А Вы пробовали проекты ADP Acctss2K? Если нет, то обязательно посмотрите! Презабавная вещь! Вот тут А2K + MsSql действительно отрывается!