Объясните на "пальцах": может ли Access DB быть серверной?

Всем привет! Сходу к делу!
Много читал и запутался в итоге)

Постараюсь коротко и самую суть. Есть программа 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 движки не стал писать и пр., но думаю итак понятно, что я спрашиваю)

0

Сообщение от FasterHarder разве нельзя преобразовать ее в клиент-серверную

Главное отличие "нормальной" СУБД от персональной СУБД - это производительная работа в многопользовательском режиме, причем желательно, чтобы число возможных пользователей измерялось не единицами, а десятками - тысячами. Access вроде поддерживает многопользовательский режим (сам не пробовал, только читал на форумах), но делает это довольно слабо, поскольку изначально позиционировался именно как персональная СУБД.

0

Сообщение от Grossmeister Главное отличие "нормальной" СУБД от персональной СУБД - это производительная работа в многопользовательском режиме, причем желательно, чтобы число возможных пользователей измерялось не единицами, а десятками - тысячами. Access вроде поддерживает многопользовательский режим (сам не пробовал, только читал на форумах), но делает это довольно слабо, поскольку изначально позиционировался именно как персональная СУБД.

да, Access поддерживает multyconnect!
спс за комментарий, но мне не стало яснее)

0

Сообщение от FasterHarder но мне не стало яснее

Все зависит от того, что ты хочешь узнать и от задач, которые хочешь реализовать. Может Access работать как многопользовательская СУБД? Может. Если у тебя несколько пользователей, которые периодически заходят в БД и вводят достаточно небольшой объем инфы, а также формируют простенькие отчеты, то возможно что Access и подойдет. Если у тебя реальная учетная система с хотя бы полусотней пользователей, тысячами транзакций в сутки и таблицами с миллионами строк, то любой здравомыслящий человек Access использовать не будет, для этого есть другие СУБД, пусть и за бОльшие деньги.

0

Grossmeister, я понял) я не про это вообще спрашиваю...

0

Сообщение от FasterHarder но там нет встроенного интерпретатора анализа запросов и пр.

Именно. В СУБД есть масса процессов, которые на сервере занимаются много чем. Скажем, в Oracle больше десятка фоновых серверных процессов плюс стартует процесс на каждую сессию (который и выполняет обслуживание запросов клиентов). В Access ты с клиентской программы просто работаешь с файлом данных, неважно, лежит он локально или на сервере. То есть клиентская программа формирует запросы и сама же формирует ответы, что не есть клиент-сервер.

0

Сообщение от Grossmeister Именно. В СУБД есть масса процессов, которые на сервере занимаются много чем. Скажем, в Oracle больше десятка фоновых серверных процессов плюс стартует процесс на каждую сессию (который и выполняет обслуживание запросов клиентов). В Access ты с клиентской программы просто работаешь с файлом данных, неважно, лежит он локально или на сервере. То есть клиентская программа формирует запросы и сама же формирует ответы, что не есть клиент-сервер.

так, на 5% приблизились к моим вопросам, но пока еще очень и очень холодно)...
я ведь очень четко задал вопросы + даже пример привел + про ОДБС/ОЛЕБД немного чирканул...

0

Сообщение от FasterHarder Считается, что MS Access заточен под файл-серверную технологию, а разве нельзя преобразовать ее в клиент-серверную.

Можно, но нужно быть в ссоре с головой.

Сообщение от FasterHarder Например, клиент на C#, на сервере файл *.mdb.

Вы же осознаёте (вопрос риторический), что файл *.mdb - просто файл с данными, база. Для работы с ней нужна СУБД, которая будет выполнять ваши SQL-запросы, будет знать как работать с этим файлом и всё такое прочее?

Сообщение от FasterHarder Я ведь могу, используя, например, поставщик OLEDB, ODBC с клиента подключится к файлу баз данных *.mdb, располагающегося на Сервере и получать данные посредством технологии ADO.NET?? Это будет считаться клиент-серверной технологией, когда на клиенте C#, а на Сервере БД акссессовская??

Нет, не будет никаким боком. Ваш сервер СУБД будет располагаться на клиенте (OLEDB, Jet), а с сервера просто будет вытягиваться файл для работы локально. Т.е. такой сервер не сервер, а просто отдаватель файла. Он может быть хоть на базе сорокоядерного Xeon, хоть в виде мобильного телефона, разницы не будет, он только отдаёт файл, работы "серверной" никакой не совершает.

0

Сообщение от Usaga Нет, не будет никаким боком. Ваш сервер СУБД будет располагаться на клиенте (OLEDB, Jet), а с сервера просто будет вытягиваться файл для работы локально. Т.е. такой сервер не сервер, а просто отдаватель файла. Он может быть хоть на базе сорокоядерного Xeon, хоть в виде мобильного телефона, разницы не будет, он только отдаёт файл, работы "серверной" никакой не совершает.

а вот тут поподробнее.
Т е, если использую поставщик, ну, пусть универсальный ОДБС, то он ЗАКАЧИВАЕТ полностью файл *.mdb с Сервера на Клиента, потом извлекает информацию, запоминает где-то в памяти, а файл пересылает ОБРАТНО на сервер и отображает данные из памяти. Примерная такая схема, да? Если да, то тогда констатируем, что Access, это ВСЕГДА файл-серверная вещь для создания настольных приложений. А как же adp или как там он правильно называется...

0

FasterHarder, SMB позволяет работать с отдельными частями файла, не выкачивая его целиком. Но смысл не меняется. "Сервер" просто отдаёт части файла и всё, никакой работы с базой он не совершает, ибо на нём даже ПО такого не присутствует.

Сама СУБД вшита в драйвер OLEDB\Jet, ибо относительно простая (персональная же). Т.е. настоящим сервером выступает сам клиент. Никакой клиент-серверной архитектуры нет и в помине.

Если вам нужно именно клиент-серверную архитектуру организовать, то это делается из ТРЁХ частей: клиента, сервера (на C# или любом другом языке) и самой СУБД. Сервер СУБД может торчать на той же машине, что и сервер приложения. Если это MS Access, то иного и быть не может - MS Access или Jet должен быть на той же машине, что и сервер приложения.

Но это дичь лютейшая. MS Access вообще не для таких применений. Возьмите нормальную серверную СУБД, благо, что их как грязи, и даже у платных есть бесплатные редакции.

1

Usaga, давай проясним еще следующие моменты.
1. Чтобы работать с базой файла *.mdb нужна инсталляция на этой машине MS Access (в него ведь встроена локальная СУРБД, ну там всякие анализаторы, интерпретаторы, роли, права и пр. пр.)?
2. Возможна ведь связка следующая: "толстенный" сервер MS SQL Server + "тончайший" клиент MS Access? Это уже будет классическая архитектура сервер + клиент (или наоборот, не суть )
3. Если создана БД на Access и нет ее возможности преобразовать в др. БД, то клиент ОБЯЗАНЫ создавать также на Access + забыть про клиент-сервер, так, да?

0

FasterHarder,
1. На машине, которая будет работать с файлом, должен стоять или MS Access или OLEDB\Jet (которые ставятся, обычно, ставятся с MS Access).

Сообщение от FasterHarder "толстенный" сервер MS SQL Server + "тончайший" клиент MS Access?

Шта?...

3. Мигрировать данные из Access можно в любую другую СУБД. Может для этого даже и готовые инструменты есть, я не знаю. Но если и нету, то можно через OLEDB\Jet вытащить данные из всех таблиц и отправить в другую СУБД.

0

Сообщение от Usaga Шта?...

ну ты чего, ну стандарт ведь) клиент (Аксес) + сервер (БД под управлением MS SQL Server)...

Сообщение от Usaga 3. Мигрировать данные из Access можно в любую другую СУБД.

я знаю, что можно, но, если "нельзя", то клиента ваять нужно на Аксес, т к это крайне удобно...

РЕЗЮМЕ: Access заточен под файл-сервер (хотя там еще АДП есть разбивка), поэтому, если нужен классический клиент+сервер, то смотреть нужно в сторону SQL Server/Oracle, а клиента ваять на том языке, который хорошо знаешь, в том числе и Access...ну так ведь, да? ну должно быть так!

0

FasterHarder, делать клиент на Access? Для SQL Server это скорее всего возможно. Но это дичь какая-то, если честно.

0

Сообщение от Usaga Но это дичь какая-то, если честно.

это бывает НОРМАЛЬНАЯ, вкусная дичь)
меня интересует сам факт, что это возможно)

И крайний вопрос: допустим сделали БД + интерфейсы под Access. Этой прогой должны пользоваться 15 юзеров. Что делаем? Инсталлим у них у всех MS Access, затем выделяем Сервер, туда кладем *.mdb или придется раздать всем копии на эти 15 компов этой БД? Я не знаю, репликации поддерживает Аксес, вроде частично, хотя хз...

0

FasterHarder, если у каждого будет своя копия базы... То как другие пользователи будут видеть работу друг друга?

Сообщение от FasterHarder это бывает НОРМАЛЬНАЯ, вкусная дичь)

Дичь нормальной не бывает никогда.

Я так понимаю, что речь идёт о том, чтобы не оплачивать разработку нормальной ИС, а украсть на торрент-треккере офисный пакет на сумму разработки этой самой ИС и воткнуть всем пользователям? Хоть бекапы, тогда, делайте почаще...

0

Сообщение от Usaga Я так понимаю

неправильно понимаешь!

Сообщение от Usaga FasterHarder, если у каждого будет своя копия базы... То как другие пользователи будут видеть работу друг друга?

никак. Значит нужно взять 1 файл *.mdb положить на Сервант и обеспечить удаленный доступ с 15 компов. Только я не знаю, там всякие блокировки, изоляции как будут. В MS SQL Server прекрасно все это работает.

В общем ладно, Usaga, спс. за помощь! Мне не все понятно и я далеко не все осознал глубоко, но кое-что я понял))

0

Сообщение от FasterHarder Только я не знаю, там всякие блокировки, изоляции как будут.

С этим будет максимально сложно) Несколько процессов будут пытаться одновременно работать с одним файлом.

Сообщение от FasterHarder неправильно понимаешь!

Тогда почему не сделать нормально?

0

Сообщение от Usaga Тогда почему не сделать нормально?

я вообще прогаю на связке C# + SQL Server 2000/2008, но мне стало чисто любопытно, а можно ли взять C# + Access, оказалось, что НЕТ)

0

FasterHarder, я вроде бы сказал, что можно. Только OLEDB\Jet должен стоять на сервере приложения. Или я этого не говорил?)

Добавлено через 1 минуту

Сообщение от FasterHarder я вообще прогаю на связке C# + SQL Server 2000/2008

А с SQL 2012 и выше вы работать уже не можете?))

1