powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Microsoft Access [игнор отключен] [закрыт для гостей] / Масштабируемость связки SQL сервер+ADP
25 сообщений из 34, страница 1 из 2
Масштабируемость связки SQL сервер+ADP
    #32304270
Самовар
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Интересно насколько масштабируемо решение Сиквел+ADP.Видел ли кто нибудь крупный рабочий комплекс (80-150 интенсивно работающих пользователей и размер базы от 50 гигабайт). Вопрос о том,насколько эфективен будет клиент по сравнению с другими (ODBC и пр.) Какие подводные камни при такой реализации.
...
Рейтинг: 0 / 0
Масштабируемость связки SQL сервер+ADP
    #32304489
Hummer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Видел, сам работаю (около 300 пользователей).
Насколько эффективен - если логика вся на сервере, то эффективен.
Из подводных камней - тупость аксесав некоторых моментах.
...
Рейтинг: 0 / 0
Масштабируемость связки SQL сервер+ADP
    #32304499
Hummer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Тупость только в некоторых моментах, просто не до конца написал. Дело в том, что аксес при конекте выгребает кучу нужной ему информации о таблицых, вьюхах и ещё много чего.
Ещё периодически валится на выборке большого количества данных в форму. Хранимая работает быстро на серваке - а аксес не принимает данные. Если с условиями ту же хранимую, то всё нормально.
...
Рейтинг: 0 / 0
Масштабируемость связки SQL сервер+ADP
    #32304556
Фотография Latuk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Если проэкт большой не только по числу юзеров но и
по функционалу , то на Access начнеш быстро,
но потом дорабатывать и сопровождать запаришся.
Но это не беда. У нас например клиент полиморфный -
часть на AccessMDB,
часть на AccessADP
часть на VB
часть на C# ASP
Каждый по своему хорош

Если есть возможность выбора , то этетически мне ближе C#
AccessADP неплох если нужен быстрый старт с резким набором функционала
(этакий рабочий(и работающий) протатип ), но затем нужен переход на
платформу с нормальной поддержкой ООП иначе в конце будет каша неудобоваримая.
...
Рейтинг: 0 / 0
Масштабируемость связки SQL сервер+ADP
    #32304864
вадя
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ну тогда самый оптимальный вариант ассембер - всё будет в тыоих руках....

главное что нужно получить от проги если ввод - акса + SQL за глаза, а ежели какихто общетов - в SQL можно присабачить расширенные процедуры хоть на чем и вперед.
тоже самое можно сделать и для клиентской части.
а связь аксом-SQL отличный вариат для выборки данных для клиента.
на аксе можно писать великолептных клиентов.
главное правильно распределить ввыплняемые задачи.

Хранимая работает быстро на серваке - а аксес не принимает данные. Если с условиями ту же хранимую, то всё нормально.
на фига гнать на клиента столько данных? что оператор сможет визуально их обработать? нада правильно сформировать данные хранимкой и их отогнать на клиента - в этом мастерство и заключается.
тут был вопрос по поиску данных в отчете в 200 страниц!!!
грамотнее было-бы формировать отчет в одну страницу, но с нужными данными
распечатать(подготовить на печать) 200 страниц - а потом их анализировать? а комп зачем? - пишмашка?
...
Рейтинг: 0 / 0
Масштабируемость связки SQL сервер+ADP
    #32304905
Фотография Pavel
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Масштабируемость это дело SQL сервера. Но коммерческий проект я бы на adp разрабатывать не взялся - см. посты Hummer за минусом постов вадя
...
Рейтинг: 0 / 0
Масштабируемость связки SQL сервер+ADP
    #32305161
вадя
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Из подводных камней - тупость аксесав некоторых моментах

хотелось бы знать кто и что считает тупостью акса.

ваши мниния , господа!

моё - нужно городить выделение строки цветом.(хотя и решается просто)
...
Рейтинг: 0 / 0
Масштабируемость связки SQL сервер+ADP
    #32305164
Фотография Pavel
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Я бы не стал категорично применять слово тупость . Выражаюсь более мягко - негибкость . Вот обьеденить бы 3 продукта: Paradox (Corel, borland, может еще куому-то сплавят), Sybase Power Builder и Access!
У каждого из них есть такие изюминки, которые влюбляют раз и надолго. надо только просечь. Так вот - жесткая привязка проекта adp к конкретному SQL серверу - это похороны сверхперспективного продукта. Если разработчики не одумаются.
...
Рейтинг: 0 / 0
Масштабируемость связки SQL сервер+ADP
    #32305323
Odess
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 Pavel
Масштабируемость это дело SQL сервера. Но коммерческий проект я бы на adp разрабатывать не взялся

Все таки можно поподробнее - почему? Я как раз взялся за разработку почти с нуля достаточно крупного проекта, причем часть его уже крутится у клиента на 1С. Переписывать будем все. Неужели это более тормозной и неправильный путь?
...
Рейтинг: 0 / 0
Масштабируемость связки SQL сервер+ADP
    #32305387
Фотография Темный
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Мля... Псиал-писал, в итоге прервалось соединение. Писать устал - поэтому выборка основных тезисов:
1) Все зависит от сервера и только от сервера.
2) Руки кривые - на Микрософт не пеняй.
3) 200 страниц отчета и поиск нужной - в морг
4) "Разруха прежде всего в головах..." (с) Булгаков
...
Рейтинг: 0 / 0
Масштабируемость связки SQL сервер+ADP
    #32305415
вадя
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2Тёмный

ну ты просто гений....

2Odess
пиши на том что, знаешь и то что нравится.

лично мне нравиться очень система команд PDP11(кто помнит, тот знает)
и ассемблер к ней....
я бы сделал проект на ADP+SQL2000. - API подключать можно (без особых проблем). расширенные процедуры (на клиенте и на сервере(повторяюсь)) хоть на чем. вариант RUNTIME (ADE) почти exe. полный комплект мелкосовтовких примочек(типа офиса) - это по происхождению.
описалово есть приличное.

самое главное чтоб голова была. и если писать командой - так чтоб народ был умеющий работать в команде.(а это большая редкость. из практики)
...
Рейтинг: 0 / 0
Масштабируемость связки SQL сервер+ADP
    #32305499
Фотография vdimas
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Писал довольно давно проект на ADP. Действительно, очень быстро растет функционал на Accesse. Со временем, когда размер ADP файла после сжатия стал более 10M, и я запарился с падениями Access, стал выносить оттуда классы в VB, и делать COM-библиотеки - разгрузил более 60% кода, да и работать все стало в 2 раза быстрее. Часть критичных к быстродействию классов потом была еще переписана на С++, и получил весьма адекватное по быстродействию приложение.

Далее. Действительно, грид на Access не позволяет по-человечески изворачиваться с раскраской, колонками-картинками, выпадающими календариками ипрочими прелестями. Но это не страшно, т.к. такое требуется дай бог в 15% всех гридов в приложении. Поэтому постепенно, уже в процессе отладки некоторые формы со вложенным гридом были переписанны с использованием Infragistics UltraGrid (очень похож внешне на Access-овский, поэтому вписывается весьма органично). Это, плюс повсеместное использование иерархических справочников и собственного ActiveX элемента-дерева, который понимает 3 вида организации иерархии без единой строчки кода, плюс ресайз практически всех форм, дало приложению вполне профессиональный вид и функционал. (а отчеты делать в Access - вообще песня!)

Так что, большие и серьезные проекты на Access делать можно и нужно, особенно в условиях нехватки разработчиков. Для сравнения на аналогичный проект полностью на С# потребуется в 3 раза больше народу, это - по-минимуму.
...
Рейтинг: 0 / 0
Масштабируемость связки SQL сервер+ADP
    #32305550
Фотография Pavel
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Odess
Все таки можно поподробнее - почему?
Да хотя бы потому, что adp требует Public на сервере. А это серьезная угроза безопасности.
...
Рейтинг: 0 / 0
Масштабируемость связки SQL сервер+ADP
    #32305634
Hummer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
вадя писал:на фига гнать на клиента столько данных? что оператор сможет визуально их обработать? нада правильно сформировать данные хранимкой и их отогнать на клиента - в этом мастерство и заключается.

Это отчёт с различными показателями всего за МЕСЯЦ. Просто количество обрабатываемых в ДЕНЬ записей очень велико - порядка 1,5 млн. записей.
Разумеется, все записи не требуются - цифра приведена для того, чтобы было понятно, каков объём данных. Данные группируются по определённым критериям и выводятся не в отчёт, а на форму.
Мастера есть, не сумлевайтесь:)

2 Pavel
Ну с тупостью погорячился, просто некоторые моменты в поведении аксеса крайне поражают:)
...
Рейтинг: 0 / 0
Масштабируемость связки SQL сервер+ADP
    #32305639
Фотография Senin Viktor
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2Hummer
>просто некоторые моменты в поведении аксеса крайне поражают:)

Спорю на банан - нет такой системы в которой что-нибудь да как-нибудь не поразило разработчика (правда, Акес иногда поражает на смерть )
==
Через терни - к зведам :)
...
Рейтинг: 0 / 0
Масштабируемость связки SQL сервер+ADP
    #32305701
x
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
x
Гость
2 Pavel

Да хотя бы потому, что adp требует Public на сервере. А это серьезная угроза безопасности.

Что требует ? Поясни для бестолкового
...
Рейтинг: 0 / 0
Масштабируемость связки SQL сервер+ADP
    #32305848
Фотография Pavel
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Public - это стандартная роль MSSQL. Позволяет много такого, что позволять не надо бы. В небольшом и некоммерческом проекте на это можно забить. А вот для коммерческого проекта это никуда не годится.
...
Рейтинг: 0 / 0
Масштабируемость связки SQL сервер+ADP
    #32305873
incold
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Интересно насколько масштабируемо решение Сиквел+ADP.Видел ли кто нибудь крупный рабочий комплекс (80-150 интенсивно работающих пользователей и размер базы от 50 гигабайт). Вопрос о том,насколько эфективен будет клиент по сравнению с другими (ODBC и пр.) Какие подводные камни при такой реализации.

Есть рабочий проект.
Есть работа с одним сервером БД другого офиса по выделеному каналу.
Пользователей порядка 100. База до 10 Гб (пока ).
Все работает. Не скажу летает, но серьезных сбоев и задержек не наблюдается.
По сравнению с ODBC - однозначно лучше...имхо.
Другие варианты не пробовал, пока и этот устраивает.
Возможно и нужно будет переходить на другие платформы, но при грамотном написании серверной и клиентской части запас масштабируемости довольно большой.

P.S. Совсем недавний пример грамотного написания: была форма сбора статистической информации, переписал по-другому хранимую процедуру, и немного форму, время работы изменилось с 10-20 сек до 1-3 сек.
...
Рейтинг: 0 / 0
Масштабируемость связки SQL сервер+ADP
    #32306202
x
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
x
Гость
2 Pavel

Public - это стандартная роль MSSQL. Позволяет много такого, что позволять не надо бы. В небольшом и некоммерческом проекте на это можно забить. А вот для коммерческого проекта это никуда не годится.

Бедный MSSQL. И ничего-то коммерческого на нем не напишешь, так поиграться только :)

Напиши это в конфу по MSSQL :)

А в аксессе есть стандартная группа Users, куда тоже попадают все пользователи базы :)
...
Рейтинг: 0 / 0
Масштабируемость связки SQL сервер+ADP
    #32314795
Могу сказать про свое негативное впечатление об ADP/ADE. Многое касается только крупных проектов.

1. То что ADE часто валится без всяких на то причин и имеет неприличный размер, к этому думаю все привыкли. Под валится, имею в виду не создается ADE
2. Объекты внутри часто, просто херятся, даже эспортнуть нельзя, без опять-таки видимых причин.
3. Компилятор может не замечать ошибок, ну это ладно, мелочи жизни.
4. Очень хреново работать с ActiveX-контролами. Блин, даже свойства не отображаются нормально. Список свойств и методов недоступен при нажатии на точку. Приходится что-то делать сначала на VB6, а потом переносить код в Access, а потом иногда еще и править из-за некоторой несовместимости.
5. Некоторые ActiveX-контролами в Access глючат, некоторые выдают ошибки, такие, что работать с ними просто невозможно.
6. Из-за привычки ADE самохериться приходится создавать головной ADE, который имеет ссылки на остальные, запускать это можно только 1 раз (типа не dll:-), если меняется что-то в подчиненных ADE приходится пересоздавать головные. Геморрой еще тот.
7. Очень неприятная особенность при большой БД. Access скачивает себе список всех объектов БД при подключении: вьюх, таблиц, хр. процедур, функций. При большом количестве объектов на сервере такие чудные мгновения могут сильно растянуться. Если ADE имеет ссылки на другие ADE, то они при обращении к ним радостно сделают то же самое.
8. С API дружит хреново, почему у контролов нет хендлеров до сих пор непонятно. Функционал втроеных контролов оставляет желать много лучшего.
9. Ну и куча глюков о которых вспоминать нет времени, да и памяти никакой не хватит.

З.Ы. Ну, а плюсы сами знаете :-)
...
Рейтинг: 0 / 0
Масштабируемость связки SQL сервер+ADP
    #32314826
Фотография Лох Позорный
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
И все это (за искл. п.7) - кажись особенности аксеса вообще, а не именно адп/аде.

1. Неприличный размер - это сколько? Особенно в сравнении с такой же функциональностью, реализованной на VB к примеру?
И "не создается ADE" - это как? Может просто беда с проектом вышла?

2. Опять таки беда с проектом? Декомпайл/восстановить/сжать никак не помогает?

3. Опять беда с проектом? Что ж это за размер такой, что он так по черному глючит?

4. Через ссылки не пробовал нужные библиотеки подключать? И явно тип описывать? У меня так еще в 97-м (мдб разумеется) все доступно и через точку все что нужно вываливается.

5. Есть такое. Так ведь контролы глючат, а не аксес. Хотя... кто ж его знает...

6. Если меняется что-то в библиотечных ade - ни фига не надо пересоздавать головной. Разумеется если интерфейсы не изменялись.

7. Ну есть такое, есть...

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

9. См. п.7
...
Рейтинг: 0 / 0
Масштабируемость связки SQL сервер+ADP
    #32315015
вадя
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2Лох Позорный

полностью подписываюсь под тем что ты ответил.
полностью подписываюсь под тем что ты ответил.
полностью подписываюсь под тем что ты ответил.
полностью подписываюсь под тем что ты ответил.

!!!!!
...
Рейтинг: 0 / 0
Масштабируемость связки SQL сервер+ADP
    #32315243
автор писал:И все это (за искл. п.7) - кажись особенности аксеса вообще, а не именно адп/аде
Однако утешает это мало :-)

автор писал:1. Неприличный размер - это сколько? Особенно в сравнении с такой же функциональностью, реализованной на VB к примеру?
И "не создается ADE" - это как? Может просто беда с проектом вышла?
Да по разному бывает. Бывает и создается, а некоторые формы отказываются работать. Размер может быть метров под 20.
Глюки накапливаются каким-то образом, сравнивать с VB, думаю, не коректно, хотябы потому, что VB создает exe-ик каждый раз заново.
А решение проблем - восстановление из BackUp :-)

автор писал:4. Через ссылки не пробовал нужные библиотеки подключать? И явно тип описывать? У меня так еще в 97-м (мдб разумеется) все доступно и через точку все что нужно вываливается.
Когда на форму кидаешь ActiveX, он и так в референсах прописывается. Если его объявить, например, как
Код: plaintext
dim tree as TreeView
, то все видно. Но, если обращаться к имени контрола на форме, то нифига. Их эти гады не могут этого сделать который год!

автор писал:5. Есть такое. Так ведь контролы глючат, а не аксес. Хотя... кто ж его знает...
В VB-то пашут, значит Access глючит.

автор писал:6. Если меняется что-то в библиотечных ade - ни фига не надо пересоздавать головной. Разумеется если интерфейсы не изменялись. Надо, хоть букву одну измени и вперед, пересоздавать головной ADE!

автор писал:8. Хендлеров нет - потому что аксесовский контрол (не в фокусе) ни фига и не окно. Откуда ж там хендлеру взяться? Экселевские ячейки тоже без хендлеров, но это вроде как и не мешает.
Кто значит не окно? В какой не в фокусе? В виднах все, что есть окна. Я даже их хендлеры могу узнать (естественно не от Access'а). Только использовать это не получается.

А в принципе на некрупных проектах и не крупных базах, ADE очень неплох. Про MDB можно спокойно забыть.
...
Рейтинг: 0 / 0
Масштабируемость связки SQL сервер+ADP
    #32315263
Да, чего собственно зашел-то :-) Хотел узнать можно ли программно создать ADE? Если нет, вот вам еще один минус :-) В 97-м была недокументированная функция.
...
Рейтинг: 0 / 0
Масштабируемость связки SQL сервер+ADP
    #32315325
вадя
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Хотел узнать можно ли программно создать ADE


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

а на фига?
...
Рейтинг: 0 / 0
25 сообщений из 34, страница 1 из 2
Форумы / Microsoft Access [игнор отключен] [закрыт для гостей] / Масштабируемость связки SQL сервер+ADP
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]