Наши проекты:
Журнал · Discuz!ML · Wiki · DRKB · Помощь проекту |
||
ПРАВИЛА | FAQ | Помощь | Поиск | Участники | Календарь | Избранное | RSS |
[18.219.28.179] |
|
Данный раздел предназначается для обсуждения вопросов использования баз данных, за исключением составления запросов на SQL. Для этого выделен специальный раздел. Убедительная просьба - соблюдать "Правила форума" и не пренебрегать "Правильным оформлением своих тем". Прежде, чем создавать тему, имеет смысл заглянуть в раздел "Базы данных: FAQ", возможно там уже есть ответ. |
Сообщ.
#1
,
|
|
|
Всем привет! Сходу к делу!
Много читал и запутался в итоге) Постараюсь коротко и самую суть. Есть программа MS Access. Поставляется вместе с пакетом MS Office. В Access удобно создавать настольные приложения. Можно создать БД + интерфейс к ней. Как понимаю, вся информация о данных + метаданных БД хранится в файле *.mdb (microsoft database). Клиент-серверная архитектура (классическая двузвенка): на "тонком" клиенте интерфейс, который программируется, например, на C#, на "толстом" сервере лежат данные в виде базы данных. Также на сервере специализированное ПО вида СУБД/СУРБД. Вообще, если грубо, под сервером я понимаю более производительный комп + спец.ПО. Считается, что MS Access заточен под файл-серверную технологию, а разве нельзя преобразовать ее в клиент-серверную. Например, клиент на C#, на сервере файл *.mdb. Как я понимаю, *mdb файл с данными, но там нет встроенного интерпретатора анализа запросов и пр., т е того, что встроено в MS SQL Server, например. Пример: у меня есть 2 компа (пусть 1 более мощный, типа он будет выступать Сервером). На Сервере нет инсталлированного пакета MS Office. У меня есть БД с расширением *.mdb, который я кладу в какую-нибудь папку на Сервер. На клиенте есть C#. Я ведь могу, используя, например, поставщик OLEDB, ODBC с клиента подключится к файлу баз данных *.mdb, располагающегося на Сервере и получать данные посредством технологии ADO.NET?? Это будет считаться клиент-серверной технологией, когда на клиенте C#, а на Сервере БД акссессовская?? P.S. про всякие Jet движки не стал писать и пр., но думаю итак понятно, что я спрашиваю) |
Сообщ.
#2
,
|
|
|
Цитата FasterHarder @ Считается, что MS Access заточен под файл-серверную технологию, а разве нельзя преобразовать ее в клиент-серверную. Нет Цитата FasterHarder @ Например, клиент на C#, на сервере файл *.mdb. У меня есть БД с расширением *.mdb, который я кладу в какую-нибудь папку на Сервер. На клиенте есть C#. Я ведь могу, используя, например, поставщик OLEDB, ODBC с клиента подключится к файлу баз данных *.mdb, располагающегося на Сервере и получать данные посредством технологии ADO.NET?? Данные получать/изменять можно. Цитата FasterHarder @ Это будет считаться клиент-серверной технологией, когда на клиенте C#, а на Сервере БД акссессовская?? Нет. |
Сообщ.
#3
,
|
|
|
Bas, слушай, можешь поконкретнее, ты ведь ас в Аксесе и про него ВСЕ знаешь)!
Цитата Bas @ Это будет считаться клиент-серверной технологией, когда на клиенте C#, а на Сервере БД акссессовская?? Нет. потому что на Сервере нету СУРБД, а в *mdb она не встроена? а разве поставщики данных ODBC не обеспечивают встроенную поддержку СУРБД )? |
Сообщ.
#4
,
|
|
|
Способы совместного использования базы данных Access
Цитата Совместное использование базы данных с помощью сервера Совместное использование базы данных можно организовать с помощью приложения Access и сервера баз данных (например, сервера SQL Server). Этот способ обеспечивает много преимуществ, но для него требуется дополнительное программное обеспечение — сервер баз данных. Этот способ напоминает разделение баз данных, поскольку таблицы хранятся в сети, а у каждого пользователя есть локальная копия файла базы данных Microsoft Access, содержащая ссылки на таблицы, запросы, формы, отчеты и другие объекты базы данных. Этот вариант используется, если сервер баз данных доступен, а у всех пользователей установлено приложение Access. Преимущества этого метода зависят от используемого программного обеспечения сервера баз данных, но в общем случае они включают наличие учетных записей пользователей и избирательный доступ к данным, отличную доступность данных и удобные встроенные средства управления данными. Более того, большинство серверных приложений для работы с базами данных нормально работают с более ранними версиями Access, поэтому не требуется, чтобы все пользователи работали с одной и той же версией. Совместно используются только таблицы. Добавлено Цитата FasterHarder @ а разве поставщики данных ODBC не обеспечивают встроенную поддержку СУРБД )? Они обеспечивают доступ к таблицам *mdb но к отчетам , формам ... - нет. Поэтому на каждом клиенте надо держать свою версию отчетов. А если он не обновил версмю? |
Сообщ.
#5
,
|
|
|
Цитата Bas @ Они обеспечивают доступ к таблицам *mdb но к отчетам , формам ... - нет. Поэтому на каждом клиенте надо держать свою версию отчетов. А если он не обновил версмю? погоди-погоди, ты говоришь не только про табл.данные, а даже про интерфейс (формы). Интерфейс на клиенте на С#. Вот эти провайдеры ОДБС, ОЛЕДБ они ведь подключаются к файлу *.mdb, как-то химичат с ним, вычленяют данные, связи, ключи + умеют интерпретировать запросы. Или нет? поясни на "пальцах", почему я не могу положить файл *.mdb ТОЛЬКО С ТАБЛИЦАМИ И ДАННЫМИ на сервант и подключатся из клиента на C# посредством АДО.НЕТ к этому файлу, отсылая всякие запросы, аля "Select * from Car where CarID = 3"?? |
Сообщ.
#6
,
|
|
|
Цитата FasterHarder @ я не могу положить файл *.mdb ТОЛЬКО С ТАБЛИЦАМИ И ДАННЫМИ на сервант и подключатся из клиента на C# посредством АДО.НЕТ к этому файлу, отсылая всякие запросы, аля "Select * from Car where CarID = 3"?? Можно (и это делают), но это файл-сервер. Цитата FasterHarder @ Вот эти провайдеры ОДБС, ОЛЕДБ они ведь подключаются к файлу *.mdb, Да Цитата FasterHarder @ как-то химичат с ним, вычленяют данные, связи, ключи + умеют интерпретировать запросы. НЕТ, это не то слово "химичат", они получают результат этой "химии" а провайдеры "ни сном ни духом" что они там "химичат". |
Сообщ.
#7
,
|
|
|
Цитата FasterHarder @ Считается, что MS Access заточен под файл-серверную технологию База данных MS Access есть всего лишь файл-контейнер. Относись к нему как к каталогу, в котором лежат файлы данных, файлы скриптов, файлы форм, прочая шелуха... И всю эту ерунду обрабатывает внешний интерпретатор с исполняемым модулем по фамилии MSACCESS.EXE. Цитата FasterHarder @ а разве нельзя преобразовать ее в клиент-серверную. Например, клиент на C#, на сервере файл *.mdb. Да пжалста... но из показанной выше аналогии - дополнительный гимор с отслеживанием интерференций одновременного доступа, который сваливается на плечи операционок (и сервера, и клиента) и обслуживается отдельным файлом блокировок (к которому тоже совместный доступ, который отслеживается... ну ты понял). Цитата FasterHarder @ потому что на Сервере нету СУРБД, а в *mdb она не встроена? Нет, не поэтому. А потому, что в этом случае .MDB файл в принципе ничем не отличается от, к примеру, .DBF-файла - это просто файл с данными, который для удобства внутри является кластеризованным контейнером с позиционным доступом. А весь гимор с поиском нужного кластера, расчётом его местоположения и смещения в нём, валится на плечи драйвера доступа - и в т.ч. обслуживание взаимоблокировок. Цитата FasterHarder @ почему я не могу положить файл *.mdb ТОЛЬКО С ТАБЛИЦАМИ И ДАННЫМИ на сервант и подключатся из клиента на C# посредством АДО.НЕТ к этому файлу, отсылая всякие запросы, аля "Select * from Car where CarID = 3"?? А кто их там будет принимать и обрабатывать? .MDB - это файл ДАННЫХ. В нём исполняемого кода нет - от слова "вообще". |
Сообщ.
#8
,
|
|
|
Akina, отлично, я еще кое-что понял.
В моем понимании, без СУБД/СУРБД невозможно получить в принципе архитектуру клиент-сервер. Т е вся нагрузка по обработке данных ложится должна на Сервер (он - "толстый" клиент). А такая ситуация: на Сервере есть файл MSACCESS.EXE, который запускаем какой-нить удаленной службой (ну, не суть), также на Сервере лежит файл с данными *.mdb. Т е получается, что в принципе есть СУБД на Серваке, которая может работать с файлами *.mdb. На др.компе-клиенте есть интерфейс на Visual Basic. Коннектимся к файлу *.mdb и отправляем запросы, посредством ADO.NET, например. Разве это не будет клиент-сервером?? |
Сообщ.
#9
,
|
|
|
Цитата FasterHarder @ на Сервере есть файл MSACCESS.EXE, который запускаем какой-нить удаленной службой (ну, не суть), также на Сервере лежит файл с данными *.mdb. Т е получается, что в принципе есть СУБД на Серваке, которая может работать с файлами *.mdb. На др.компе-клиенте есть интерфейс на Visual Basic. Коннектимся к файлу *.mdb и отправляем запросы, посредством ADO.NET, например. Разве это не будет клиент-сервером?? Чтобы получить клиент-сервер, тебе надо коннектиться не MDB (файлу данных), а к некоему выполняемому там, на сервере, исполняемому коду - то есть к запущенному там, на сервере, MSACCESS.EXE. Вот только выполняющийся MSACCESS.EXE - это "вещь в себе", к коей (если нет в текущей его БД некоего "слушающего" кода, формирующего свой сервер). И ему на какие-то там извнешние ADO.NET чхать с высокой колокольни - у него и входов-то таких нету. Им можно снаружи "порулить" только по DDE через Access.Application, что для исполняемого на удалённом сервере процесса задачка весьма нетривиальная. Но если в базе на VBA состряпать какой-нить сокет-сервер - то пжалста, будет тебе клиент-сервер. Не ADO, конечно (не, можно и ADO, но это ж сколько коду нарисовать потребуется!), но тем не менее... вот только использовать нормальный готовый сервер го-о-ораздо проще. К тому же некоторые умеют использовать файлы MDB в качестве файла-хранилища данных вместо своих родных файловых форматов (геморройно, с ограничениями, но тем не менее). |
Сообщ.
#10
,
|
|
|
Akina, так, стало еще понятнее)) но и сложнее становится понимать)
я уже выкупил, что клиент-сервера быстро на файлах *.mdb не получить! Еще вопрос, пусть дилетантский: а вот эти вот поставщики/провайдеры, аля ОЛЕДБ, ОДБС разве не могут связать MSACCESS.EXE с файлом *.mdb, чтобы можно было потом запросы отсылать и все всЁ понимали на Сервере, что нужно делать?) |
Сообщ.
#11
,
|
|
|
Цитата FasterHarder @ а вот эти вот поставщики/провайдеры, аля ОЛЕДБ, ОДБС разве не могут связать MSACCESS.EXE с файлом *.mdb Ну они же не запускают исполняемый код - тем более на удалённом сервере... |
Сообщ.
#12
,
|
|
|
Цитата Akina @ Ну они же не запускают исполняемый код - тем более на удалённом сервере... ну, ясно... в общем, если нужен клиент-сервер, то нужно искать СУРБД, которая интегрирует файлы *.mdb, иначе придется писать с нуля НОВУЮ технологию к БД)) Akina big спс за пояснения! P.S. еще читал, что приложение Аксесовское бьют на 2 части, образовывая файл вроде с расширением *.adp и это некая имитация клиент-сервера, но только в этом случае Клиент будет на Access, а др.язык, например, С-диез нельзя... |
Сообщ.
#13
,
|
|
|
FasterHarder, может есть смысл воспользоваться клиент-серверной СУБД и не париться с аксесом?
|
Сообщ.
#14
,
|
|
|
Цитата FasterHarder @ еще читал, что приложение Аксесовское бьют на 2 части, образовывая файл вроде с расширением *.adp и это некая имитация клиент-сервера ADP - это ПРОЕКТ MS Access. Интерфейс в Аксе, а данные в MS SQL. И да,это уже получается клиент-сервер. А когда бьют на две части, то обе они MDB. В одной только данные, в другой интерфейс. И тоже файловый доступ. |
Сообщ.
#15
,
|
|
|
Цитата Akina @ И тоже файловый досту Добавлено Цитата Akina @ И тоже файловый доступ. Добавлено Видел варианты, но это ... и работает "через пень колоду" |
Сообщ.
#16
,
|
|
|
Цитата FasterHarder @ В Access удобно создавать настольные приложения Именно для этого Акцесс и предназначен. Как и всё остальное из пакета МС Оффис. Цитата kosten @ Ага. В чём проблема-то??? FasterHarder, может есть смысл воспользоваться клиент-серверной СУБД и не париться с аксесом? |