Клиент-сервер

← →
RVH (2006-09-02 12:10) [0]

Имел ли кто опыт работы c БД MS Access в клиент-серверных приложениях? Необходимо разработать программу тестирования на 10-15 клиентских мест, при этом все вопросы теста, а также Logи работы клиентов должны размещаться (сохраняться) в mdb на сервере (требования заказчика). Потянет ли Access это???

← →
Виталий Панасенко (2006-09-02 12:20) [1]

3-хзвенка - эмулятор клиент-сервера для MS Access(в данном контексте). Это вообще-то файл-серверная СУБД

← →
Виталий Панасенко (2006-09-02 12:22) [2]

И 10-15, кажись, для Access многово-то(по отзывам тут же на форуме)

← →
DrPass © (2006-09-02 13:07) [3]

> Имел ли кто опыт работы c БД MS Access в клиент-серверных
> приложениях?

На основе MS Access клиент-серверное приложение никак не сделаешь. Разве что действительно самому сделать приложение-сервер, и чтобы оно с одним коннектом к БД писало в нее данные

← →
sniknik © (2006-09-02 13:27) [4]

> И 10-15, кажись, для Access многово-то(по отзывам тут же на форуме)
для трезвенки пофигу, да и как файл сервер для программы "тестера" потянет на 15 коннектов, т.к. не будет частых обращений. (хотя не стоит конечно, делать зная что это неправильно)
а вообще для аксесс заявлено 5 подключений.

> Разве что действительно самому сделать приложение-сервер
можно еще воспользоваться готовым мелкосовтским rds сервером в системе (DataFactory), но это имхо посложнее будет чем свой на midas сделать (и написание и утановка/настройка).

← →
Antoxa2005 (2006-09-02 13:33) [5]

5-7 работет отлично, но лучше потратить недельку на изучение FireBird.
В Access проблемы с "автоинкрементом".

← →
RVH (2006-09-02 13:50) [6]

В таком случае какую СУБД лучше использовать (нет времени изучать +/-)?

← →
sniknik © (2006-09-02 13:50) [7]

> В Access проблемы с "автоинкрементом".
да не, скорее у когото проблемы с руками...

← →
sniknik © (2006-09-02 13:53) [8]

> В таком случае какую СУБД лучше использовать (нет времени изучать +/-)?
mssql, учитывая что более менее знаеш access(?, иначе с чего вопрос про него), это будет лучший/близкий переходный вариант.

← →
Antoxa2005 (2006-09-02 14:16) [9]

> да не, скорее у когото проблемы с руками...

Да, а ты попробуй восстановить информацию в пустую таблицу с нужными значениями ключей. А сделать поле автоинкрементным с уже имеющимися записями - ни ХРЕНА.

> mssql, учитывая что более менее знаеш access(?, иначе с
> чего вопрос про него), это будет лучший/близкий переходный
> вариант.

А кто будет платить за mssql, или на пиратском, ну тогда УК ст.146.

← →
Anatoly Podgoretsky © (2006-09-02 14:27) [10]

Antoxa2005 (02.09.06 14:16) [9]
А зачем же воровать, при наличии бесплатных версий?
Я просмотрел свои базы, все они могли бы работать и на бесплатном, при том с приличным запасом.

← →
sniknik © (2006-09-02 14:28) [11]

> Да, а ты попробуй восстановить информацию в пустую таблицу с нужными значениями ключей.
легко. (и это не проблема с "проблемы с "автоинкрементом"", это недостаток знаний по предмету... судя по всему сравниваеш с IB/FB где автоинкремент таковым вовсе не является.)

> А сделать поле автоинкрементным с уже имеющимися записями - ни ХРЕНА.
и в чем тут проблема? не читал справку, и не знаеш что можно, что нельзя, но очень хочется?

> А кто будет платить за mssql, или на пиратском, ну тогда УК ст.146.
пользуйся бесплатным вариантом... ни платить, ни проблем с УК.

← →
Antoxa2005 (2006-09-02 14:40) [12]

> и в чем тут проблема? не читал справку, и не знаеш что можно,
> что нельзя, но очень хочется?

Не ну тогда я не знаяю...

← →
Antoxa2005 (2006-09-02 14:43) [13]

Т.е. хочешь сказать, что заполенное поле можно сделать автоинкрементным?

← →
Anatoly Podgoretsky © (2006-09-02 14:55) [14]

Antoxa2005 (02.09.06 14:43) [13]
Можно, я часто так делаю, при том без программирования, а только штатными средствами сервера.

← →
Antoxa2005 (2006-09-02 15:00) [15]

> Можно, я часто так делаю, при том без программирования,
> а только штатными средствами сервера.

Да нет sniknik, написал, что в Access это можно сделать.

На таблицу с данными наложить автоинкремент. Но как это можно сделать? Насколько я знаю это невозможно и это является существенным недостатком Access. Я сам часто использую Access, как БД к своим приложениям. И очень бы обрадовался, если бы кто-нибудь рассказал, как это сделать.

← →
Anatoly Podgoretsky © (2006-09-02 15:02) [16]

Я говорил про MSSQL, а sniknik говорил, что проблема с руками.

← →
sniknik © (2006-09-02 15:05) [17]

Anatoly Podgoretsky © (02.09.06 14:55) [14]
не, асксесс не даст это не mssql, у него всетаки функционал поограниченнее.
для него только вариант с созданием новой таблици и копированием данных включая будующий автоинкремент.
но это всетаки не проблема, это стандартно и в справке описано (более того ошибка выдается с подробным описанием альтернативы...)

← →
Antoxa2005 (2006-09-02 15:12) [18]

Например, работают несколько служб
1.Вводится НСИ
2.Складской учет
3.Расчет прибыли
и т.д.

Вдруг кладовщик, что-то удалил или еще что-то. Короче необходимо восстановить одну или несколько таблиц(данные). Если залить информацию в таблицу из копии БД, то автоинкремент "встанет" по новым значениям и все связки с этой таблицей окажутся неактуальными. В FB нет таких проблем и в то же время сервер всегда выдаст тебе уникальное значение.

← →
sniknik © (2006-09-02 15:25) [19]

> Короче необходимо восстановить одну или несколько таблиц(данные).
> Если залить информацию в таблицу из копии БД, то автоинкремент "встанет" по новым значениям
нет, здесь все "встанет" правильно. или думаеш мелкосовтцы допустили такой банальный просчет, о котором ты додумался а целая команда разработчиков лоханулась?
да у тебя мания величия.

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

> В FB нет таких проблем и в то же время сервер всегда выдаст тебе уникальное значение.
главное чего в FB нет, это автоинкрементов... поэтому там совсем другие принципы действуют. (тянуть привычки с одного на другое, верный способ "искривить себе руки")

← →
Anatoly Podgoretsky © (2006-09-02 15:35) [20]

Antoxa2005 (02.09.06 15:12) [18]
Не продуманность технологии, надо разрабатывать программу с учетом подобных операций. Реально в сложной, много связной системе это уже будет невозможно, включая и ИБ.

← →
Antoxa2005 (2006-09-02 15:35) [21]

> и потом даже это действие, в этом случае необязательно...
> тут проше восстановить, просто заменив файл копией из бэкапа.

Не остальные, то уже свою информацию "настучали" и им не понравиться, если все это восстановиться на пару дней назад, только потому, что кладовщику так надо.

> или думаешь мелкосовтцы допустили такой банальный просчет,
> о котором ты додумался а целая команда разработчиков лоханулась?

Ну, подскажи, как они это предусмотрели?

← →
Antoxa2005 (2006-09-02 15:38) [22]

> Anatoly Podgoretsky

Что имеется под
> включая и ИБ.

← →
Anatoly Podgoretsky © (2006-09-02 15:48) [23]

А то что, в сложной системе связи уже будет не восстановить, или это дастся такой кровь, что всех проклянешь. Если предполагается восстановление удаленных, то процедура должна быть очень продумана, включая восстановление самых, самых сложных данных и на этом пути будет столько сложностей, что и врагу не пожелаешь.

← →
Anatoly Podgoretsky © (2006-09-02 15:50) [24]

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

← →
Antoxa2005 (2006-09-02 15:56) [25]

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

> sniknik ©

пишет, что это делается и при чем легко, но как не сообщает. Следовательно, либо он лукавит, либо скрывает. Если первое, то все ясно, если второе, то ПРОСИМ…

← →
Antoxa2005 (2006-09-02 16:00) [26]

Другое дело, что достоинства БД Access превосходят недостатки, но эти самые недостатки не дают чувствовать себя комфортно и подталкивают присматриваться к другим БД в т.ч. серверного типа. А разобраться с FB заставила необходимость подключаться к БД удаленно не расшаривая каталоги.

← →
sniknik © (2006-09-02 16:07) [27]

Antoxa2005 (02.09.06 15:35) [21]
> Ну, подскажи, как они это предусмотрели?
где ты видиш код до этого, или чтото конкретное? ветка "трепальная" по моим категориям, а я отвечаю в унисон ветке... обычно, (очень стараюсь), т.е. ты мне свой "наезд" без всякой конкретики, я тебе такоеже опровержение.... мило, абстрактно беседуем... зачем же "кайф ломать" грубой реальностью?

Anatoly Podgoretsky © (02.09.06 15:48) [23]
ну тут у нас вопрос не о системе в общем, а о возможности восстановить автоинкрементные значения из другой таблицы.

> Невозможно снять автоинкремент с поля залить данные в таблицу и установить,
> sniknik ©
> пишет, что это делается и при чем легко, но как не сообщает.
нет я говорил не так, читай оригинал, и передергивай. [11]
>> Да, а ты попробуй восстановить информацию в пустую таблицу с нужными значениями ключей.
> легко. ...
про изменения был другой ответ.

← →
Antoxa2005 (2006-09-02 16:07) [28]

Ладно, отключаюсь, а то sniknik © исчез.

мечты...

← →
Antoxa2005 (2006-09-02 16:09) [30]

Да весело, но надо иногда и спать...

Antoxa2005 (02.09.06 16:07) [28]
Он так просто не отстанет.

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

Это каскады сработали?

Соловьев © (02.09.06 20:55) [32]
Естественно, при удалении работника должна быть удалена вся связанная с ним информация. Это как раз нормально. А вот восстановление с кучей связаных ИД это ужас.

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

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

А зачем снимать - заливай сразу ГЛАВНОЕ чтоб ID не повторялись - проверено РАБОТАЕТ

> А зачем снимать - заливай сразу ГЛАВНОЕ чтоб ID не повторялись
см. выше. не верит, думает что нужны какието тайные знания, а то что сам делает неправильно даже мысли не допускает.

← →
Antoxa2005 (2006-09-04 11:51) [38]

> А зачем снимать - заливай сразу ГЛАВНОЕ чтоб ID не повторялись
> - проверено РАБОТАЕТ

Структура таблицы справочник клиентов IDK, NameK, таблицы продаж IDPr,IDK, Summ.

Если перезалить таблицу клиентов, то Access сам пронумерует а/и поле, но в табол. продаж вторичный индекс уже сохранен, следовательно мне нужны конкретные значения а/и поля залить, а затем пусть Access сам номерует вновь вводимые пользователем записи.

> Если перезалить таблицу клиентов, то Access сам пронумерует а/и поле
с чего бы это? если в заливаемых данных присутствуют все поля вместе с автоинкрементом...

> следовательно мне нужны конкретные значения а/и поля залить
легко. заливай.

> sniknik © (04.09.06 12:06) [39]

MS SQL при такой заливке ругается. Там нужно явно указать, что автоинкремент ты присваиваешь сам.
Уж запостил бы правильный ответ, там наверняка нужно просто пару ключевых слов в инсерт добавить.

Клиент-сервер Найти похожие ветки