>> Я сам пишу на MSSQl 7.0 + Access 97
>Мне бы MSSQl 7.0 + Access 2, чтобы меньше переделок.

Не принципиально, хотя разница, конечно, есть.

>> Болею преходом на MS VC
>VC - это Visual C? А почему именно этот переход?

А я вот болею переходом на "тонкого" клиента. Вооще не нужен на клиенте специальный exe'шник. Все можно сделать в IE.

>>Про вопросы.
>>Как уже правильно сказали все селекты надо делать на сервере. Скарости возростают. Правда есть некоторые тонкости:
>Как сделать все селекты на сервере, если Access-2 может на сервере хранить только свой mdb-файл? Но если это возможно, то в каком виде этот селект возвращает результат: текстовый файл, mdb-файл, таблица для Access-2?

Видимо имеется ввиду не файловый, a SQL сервер. Это программа такая. Причем их много разных бывает - MSSQL, Oracle, Interbase, Informix, DB2, MySQL... Не просто селекты надо на SQL сервере делать (Select просто что-то возвращает тому, кто его вызвал). На сервере надо делать логику и бизнесс-правила приложения, реализуемые связями, проверками, ограничениями, триггерами, функциями, процедурами, транзакциями - все на сервере. Хотя естно клиенту какие-то данные отображать неприменно нужно. Другое дело что отображать: 5000 записей в поле со списком - крайне не рационально, и я уверен - реально и не нужно. Нужно очень тщательно подходить к вопросу закачки на клиента данных. В идеале нужно качать только ту их часть, которая действительно необходима на текущий момент. Возникнет потребность в других - только тогда к другим и обращаться. Акссессу (mdb) селект возвращает или источник данных формы, или обьект Recordset, или просто результат запроса в табличном виде на экран.

>>1. Индексы. Особенно кластерные.
>Не понятно, о чем речь. В Access-2 вроде "кластерных" проблем нет.

Не знаю о чем вы тут. Просто дам определение - кластерный индекс - это индекс, согласно которому данные ФИЗИЧЕСКИ сортируются и хранятся в таблице.

>2. Написание запросов через INNER JOIN
>> В Access-2 это вроде совсем без проблем.

Снова не понимаю, о чем речь. На всякий случай: Jet (это ядро управления данными Access 2,97 и 2000 - кроме проектов ADP) только частично поддерживает ANSI SQL 89. Там вообще много "своего", о чем ANSI'шники и не догадываются. Есть и приятные вещи, есть и не приятные.

>> 3. Железки серыера и объем ОЗУ. Из истории: Процедура по закачиванию информации построчно PIII 400 RAM HDD 20 IBM 5400. Ну так надо было. 4 часа. Ставлю рейд конроллер - 60$ и результат - 1 час. Рейд просто как переходник. Без зеркалов ип прочих примочек.
>У меня был как сервер PII-350 и 128 RAM HDD UDMA-33, поменял на PIII-866 256 RAM HDD UDMA-100. Никакой разницы - так же шустро работает, все запросы измеряются секундами. Выборка для архивирования, правда, сократилась с 20 мин до 7. Но у меня БД маленькая - 35 МБ и больше 50-70 не будет.

А затык не в процессоре, памяти или дисковой подсистеме. он в сетке. См. "селекты на сервере". Хотя если все устраивает, зачем этот сабж?

>> 4. Acceess 2.0 не сковсем корректно работает с датами более 2000 года. Пришлось брать 97.
>В начале 2000 года скачал update с сайта Микрософт - три DLL-файла. Все работает. Могу прислать.

Это хорошо.

> 5. Сам Access еще та штучка. Очень любит блокировки. Берешь Форму в которую возвращаются 5000 записей и смотришь как на сервере лочатся таблицы. Это обходимы штуки. Если интересно напишу на мыло.
> 6. Берем комбо бокс из 2000 записей. и та же песня с блокировками. Тоже обходится в параметрах запроса пишишь (NoLock) И все работает.
Я так давно и сделал не только в комбо-боксах, но и в формах и в запросах. Это рекомендуется в KnowledgeBase в Микрософт.

Есть 2 типа SQL серверов: "блокировочники" (MSSQL) и "многоверсионники" (Oracle, Interbase). И у тех, и у други есть свои преимущества и недостатки. Могу сказать только про MSSQL - все очень не просто. Применение блокировок требует глубокого понимания. Если есть понимание - все решаемо и в Access.

> 7. Access 97 очень любит увеличиваться в объемах. Делаешь сжать и файл уменьшается раз в n.
Есть такое дело, как и в других БД (как я понял из описаний). У меня стоит на сервере ночное сжатие, каждое утро - небольшая БД.

Так и надо. Еще и резервирование организуй, если нет.

>>Про отчеты.
>>1. Очень я люблю за это Access. Просто. В других языках с этим сложнее. Правда в VB есть quickreport а в Delphi CristalReport или наоборот.

Не могу не согласиться. Хотя в Paradox, например, тоже ничего.

>Как я понял из описаний, В Delphi отчет нельзя на ходу (при распечатке) менять: показать/скрыть что-то, вставить какой-то текст или значение в зависимости от кнопки в какой-то форме, выдать второй экземпляр отличный от первого и т.д. В Access-2 - без проблем. Как теперь все это делать в Delphi - ума не приложу.

Как и опытный разработчик на Delphi не сможет влет состряпать сложный отчет в Access, если раньше с этим не сталкивался.

>>2. Есть допольнительные ActiveX компоненты под VB с готовыми бланками отчетов.

Насколько я понимаю, ActiveX везде ActiveX, а не только в VB

>Мне-то надо мои, нестандартные.

Да любой мало-мальски расчирканый водоль и поперек отчет - нестандартный. Были бы все стандартные - был бы и один за всех - универсальный.

>>3. В Delphi можно в списке уакзать несколько столбцов и будет так как ты привык видеть в Accesse. У Microsoft с этим проблемнее, но решаемо.
>Спасибо за подсказку. Посмотрел, да, очень похоже, но, конечно, намного проблематичнее нарисовать (как-то через ж... сделано).

В Ассеss, если не упираться в тонкости пользовательского интерфейса разрабатывать формы просто удовольствие. Но иногда попадается какая-то досадная и важная деталь, которую ну никак не решить стандартными средствами. На это есть масса ActiveX компонентов.

>>4. На C делаешь все сам ручками. НО если тебя страшит написать цикл и если нужна группировка, то и вложенный тут уж изинятес.
>Уже не хочу. Тем более, что в программе у меня сотни три-четыре запросов, да ещё их текст зависит от условий в форме. Как делать это в Delphi - непонятно.

Ну как-то же делают! Или у тебя самая навернутая прилада из всех существующих? А перелопачивать такую кучу запросов никто тебя и не заставляет - повторяю, если все устраивает, зачем этот сабж?

>>Итого.
>>Если тебе надо через каждые 5 минут разворачивать проект перпендикулярно, то Access само то. По скорости можно залечить более крутыми процами. Если необходимо открывать 2-4 Accessa и с каждым работать, то лучше брать PII, PIII или Aslonы. Celeron & Duron не справится.

Ну развернуть перпендикулярно можно любой проект. Все зависит от квалификации разворачивающего и его знания проекта. А вы бы еще предложили двупрцессорную тачку для 16-ти разрадного Access 2...

>>Если ты готов потратить время на написание именно "системных" вещей и ТЗ более менее устоялось и закостенело, то бери C Bilder или MS. Программа (точнее, комплекс программ), бывает, меняется несколько раз в месяц, т.е. что-то исправляется/добавляется в соотвествии с ТЗ. Вплоть до смены структуры БД на сервере. Скорость работы устраивает - все измеряется секундами (как я проверял на своих данных - другие программы работают медленнее, даже в разы, тот же SQL-server просто листает данные на экране раз в 5 медленнее). Да, конечно, скорость проца играет роль, но у нас в основном стоят Celeronы и разница с PIII невелика (речь идет о работе Access-2 runtime у операторов). На скорость больше влияет тактовая частота и объем памяти.

Ну что тут сказать? Если у Вас SQL сервер "просто листает данные на экране", да еще "раз в 5 медленнее"... Я уже жалею, что вообще стал сюда писать. С вами, ребята, свихнуться недолго. И чем он их листает?
Больше всего на скорость влияет оптимальность кода. И не только того, который Вы скармливаете интерпритатору/компилятору, но и того, который обеспечивает доступ к данным. Проследим, что происходит, когда вы выполняете запрос к SQL серверу по сети и получаете данные (источник записей формы, например) из mdb:
Access - Jet(определение - компиляция - оптимизация) - ODBC - client_native_dll - OSI - server_native_dll - SQL_server_kernel - server_native_dll - OSI - client_native_dll - ODBC - Jet - Access
И на каждом этапе "часики тикают", причем связка Access - Jet - ODBC и обратно - наиболее тормозная. Если ее обойти (ODBC Direct) скорость выполнения запроса возрастает во много раз. Кроме того данные кэшируются и ODBC и Jet. И нафига, спрашивается?

>У начальства - фикс-идея: надо SQL-сервер, потому что у других так.
А как на нем (и на Delphi) сделать связь с филиалами внутри города и иногородними (сейчас я отправляю/принимаю mdb-файл по модему или через Интернет)?
Как соединить несколько БД в одну (структуры одинаковые, данные разные) и положить в какой-нибудь из бухгалтерских компьютеров, чтобы они её "причесали" (сейчас я просто делаю селектом выборку в mdb-файл, копирую его и устанавливаю ту же программу на Access-2)?
Как делать запросы с изменяемым текстом и куда (в каком виде) возвращается результат (в Access-2 это делается элементарно, а результат возвращается в виде таблицы внутри Access2)?
Как делать измененяемые при распечатке отчеты в зависимости от условий в формах (в Access-2 это делается через ссылки на формы)?
В Access-2 у меня под сотню внутренних (и временных) форм и, соответственно, таблиц. В Delphi под каждую таблицу нужен DBF-файл, т.е. сотня файлов для одной программы? А если программ несколько? Жуть какая-то.
В Access-2 я использую "прекрестные" соединения таблиц, когда нужно одной программой забрать данные из другой БД или загрузить настройки (установки). А тут как быть?
И к тому же SQL-7.0 работает только под NT или Win-2000 - проверено.

А зачем сабж, раз все устраивает? Вы, видимо, хотите все это дело распечатать, и отнести начальству? Можно и так. Вот только если у других SQL сервер, это не значит, что они идиоты а вы Д'Артаньян. Много всего есть в SQL серверах - и мощные механизмы репликации, и надежность хранения и защиты данных, и системы анализа и потдержки принятия решения... Вы сами то определитесь, нужно все это Вам, или нет. Если нужно - начните с проектов (ADP) Access 2000 + MSSQL. Поскольку Вы уже работаете с Access, Вам там многое будет знакомо и понятно. Сможете построить систему на базе этих продуктов - поймете, что в этой связке главный не Access, и его есть, при желании, чем заменить. А если возникнут конкретные вопросы, а не сопли на тему "А на кой мне это надо" - многие в конференциях этого сайта с радостью Вам ответят.

P.S. MSSQL Personal Edition 7.0 работает даже под Win95. В том числе и в сети. Плохо проверяли.

Удачи!