powered by simpleCommunicator - 2.0.59     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / Поругайте Акцесс. Очень надо.
147 сообщений из 147, показаны все 6 страниц
Поругайте Акцесс. Очень надо.
    #32380288
aPT
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
На днях надо "опустить" программу конкурентов. Используют Акцесс. Я же со своей стороны накатал на FireBird.
Про акцесс мои знания ограничиваются "Акцесс-ацтой. FB - рулез". Исходные данные для ругани:
-Работа будет клиент-сервер.
-Данных может быть до 100 000 записей.
Выскажитесь по сабжу, если не трудно :)
...
Рейтинг: 0 / 0
Поругайте Акцесс. Очень надо.
    #32380303
Фотография Лох Позорный
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ну так и покажи свои знания!
Ударь себя пяткой в грудь и громко возопи "АКСЕС АЦТОЙ!!!"
И все сразу поймут, что 100000 с помощью аксеса обработать никак нельзя.
А уж про клиент-сервер и говорить нечего, ибо даже в режиме adp аксес может использовать только MS SQL, а MS SQL - тоже ацтой.
...
Рейтинг: 0 / 0
Поругайте Акцесс. Очень надо.
    #32380309
Фотография Владимир Саныч
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
авторВыскажитесь по сабжу, если не трудно :)
Пожалуйста.

Ё% твою ма%ь, пи%дец, %лядь, на%уй.

%уесос ё%аный, %лядун пи%здорваный.

Еще?
...
Рейтинг: 0 / 0
Поругайте Акцесс. Очень надо.
    #32380313
Витал
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
А FireBird из какого болота выпузырилось?

А Аксекс - это класс!!! Особенно в сочетании с SQL server!!
...
Рейтинг: 0 / 0
Поругайте Акцесс. Очень надо.
    #32380314
Фотография Артист
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
...
Рейтинг: 0 / 0
Поругайте Акцесс. Очень надо.
    #32380319
Витал
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Если еще добавить горчички и перчику, да под водочку холодненькую... Мурррррррррр!
...
Рейтинг: 0 / 0
Поругайте Акцесс. Очень надо.
    #32380322
Фотография Лох Позорный
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Витал, тебя попросили поругать аксес
А ты вместо этого начал аксес хвалить и ругать FB
Внимательнее читай ТЗ.
...
Рейтинг: 0 / 0
Поругайте Акцесс. Очень надо.
    #32380326
Витал
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Владимиру Санычу горячие аплодисменты!!!

Самое странное, что я похожпе понимаю его иврит!
...
Рейтинг: 0 / 0
Поругайте Акцесс. Очень надо.
    #32380336
Фотография Senin Viktor
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
>На днях надо "опустить" программу конкурентов. Используют Акцесс

Как вариант - опустить самих конкурентов, не опуская Акес. Мои предложения: "сам дурак", "у меня член больше"...
...
Рейтинг: 0 / 0
Поругайте Акцесс. Очень надо.
    #32380341
Витал
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 ЛП

Пардон за невнимательность!!

Аксекс - это такая срамная штука, которая не позволяет
а) хранить данные
б) обрабатывать данные
в) отображать данные

А файл БД к тому же не может быть больше (2 или 4 Гб - даже этого не помню).

Те кто его использует просто, не побоюсь этого слова, лохи позорные .
...
Рейтинг: 0 / 0
Поругайте Акцесс. Очень надо.
    #32380342
Фотография Лох Позорный
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Санычу - замечание
Просили высказаться по сабджу, а он - по матери
Некошерная реализация ТЗ.

2 Сенин Виктор
а клиент того и глядишь ответит, что у него пробел длиннее и более кривой
...
Рейтинг: 0 / 0
Поругайте Акцесс. Очень надо.
    #32380357
Витал
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ЛП грита клиент того и глядишь ответит, что у него пробел длиннее и более кривой

Ниче!!! Зато у нас Ентир с загогулиной!
...
Рейтинг: 0 / 0
Поругайте Акцесс. Очень надо.
    #32380365
aPT
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Энтер с пробелом в краткое сравнение моей программы на 10 страницах с существующими аналогами не подошьешь. Как бы не хотелось этого. Генерал который читать это будет не поймет.
...
Рейтинг: 0 / 0
Поругайте Акцесс. Очень надо.
    #32380366
Фотография fedd
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
если серьёзно -

для работы с аксесс на каждой клиентской машине должен быть установлен этот... как его... а! аксесс!

а для работы с firebird не должен. а должна быть установлена специальная клиентская программа.

аксесс
1) стоит денех
2) устанавливается тоьлко на Маздай
3) ну а если это mdb (так ли это?), то и действительно, клиент сервер из него - ну это братья аксессники скажут
...
Рейтинг: 0 / 0
Поругайте Акцесс. Очень надо.
    #32380399
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
авторПро акцесс мои знания ограничиваются "Акцесс-ацтой. FB - рулез". Исходные данные для ругани:
-Работа будет клиент-сервер.
-Данных может быть до 100 000 записей.
Мда, очень "точное" описание достоинств клиент-серверных технологий и "убедительное" доказательство преимуществ FB перед Access :)

P.S. Кстати странно, что автор не сказал, на чем у него клиент написан.
...
Рейтинг: 0 / 0
Поругайте Акцесс. Очень надо.
    #32380403
alex_k
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
вообще, можно даже клиентскую программу не устанавливать.
у нас шара на сервере, на шаре лежат ехешники, gds32.dll и firebird.msg
и все запускатеся с шары. на клиенте вообще ничего не нужно.

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

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

ну и самое главное. твоя программа должна быть лучше конкурентской. иначе все упрется в твою харизму и удачу :-)
...
Рейтинг: 0 / 0
Поругайте Акцесс. Очень надо.
    #32380406
aPT
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ASCRUS написал:P.S. Кстати странно, что автор не сказал, на чем у него клиент написан.
Ну на дельфи...... Конкурент на VB слепил программу.......
...
Рейтинг: 0 / 0
Поругайте Акцесс. Очень надо.
    #32380409
aPT
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
alex_k ну и самое главное. твоя программа должна быть лучше конкурентской. иначе все упрется в твою харизму и удачу :-)
Да лучше она. Уперлось в то, что часть бэта-тестеров куплена конкурентом. Хотя и через это прорвемся.
...
Рейтинг: 0 / 0
Поругайте Акцесс. Очень надо.
    #32380414
Фотография # Darth Vader #
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ну вы даете

Такого еще не встречал. Вот это ход!

Что за птица FireBird ? Незнаю может рулёзная , но я думаю и у нее минусов не меньше?
...
Рейтинг: 0 / 0
Поругайте Акцесс. Очень надо.
    #32380417
aPT
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
FireBird = InterBase. Вторая база сверху на форуме.
...
Рейтинг: 0 / 0
Поругайте Акцесс. Очень надо.
    #32380418
Фотография Лох Позорный
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Клиент на VB? К базе на аксесе???
Самый главный аргумент - конкурент д....еб. Его посадют.
...
Рейтинг: 0 / 0
Поругайте Акцесс. Очень надо.
    #32380423
Фотография fedd
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
толко прежде чем пользоваться советом Лоха убедись что там прозвучало именно VB а не VBA
...
Рейтинг: 0 / 0
Поругайте Акцесс. Очень надо.
    #32380424
Фотография Лох Позорный
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Или же наоборот - конкурент бесконечно крут. Тогда его все равно посадют.
...
Рейтинг: 0 / 0
Поругайте Акцесс. Очень надо.
    #32380433
aPT
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
именно VB
...
Рейтинг: 0 / 0
Поругайте Акцесс. Очень надо.
    #32380444
Фотография Лох Позорный
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
гыыы
еще наверное через ОДБЦ
...
Рейтинг: 0 / 0
Поругайте Акцесс. Очень надо.
    #32380446
Фотография # Darth Vader #
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Пошла "расовая" дискриминация.
А потом придет команда извращенцев , которая делает клиентов на ASM и Ваш FireBird улетит в трубу.
...
Рейтинг: 0 / 0
Поругайте Акцесс. Очень надо.
    #32380448
alex_k
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
а почему посадют?
шутка=false
...
Рейтинг: 0 / 0
Поругайте Акцесс. Очень надо.
    #32380464
Фотография Лох Позорный
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
почему, почему...
для его же блага.
такие к жизни на воле не приспособлены, вымирают быстро.
еду не могут добывать. их опережают более быстрые, либо более сильные, либо более устойчивые особи.
...
Рейтинг: 0 / 0
Поругайте Акцесс. Очень надо.
    #32380690
f_w_p
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Если клиентов более 10 и БД более 100М - ACCESS это даже тормоз. Это якорь. Чугуниевый!
...
Рейтинг: 0 / 0
Поругайте Акцесс. Очень надо.
    #32380803
Фотография Senin Viktor
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
>Если клиентов более 10 и БД более 100М - ACCESS это даже тормоз. Это якорь. Чугуниевый!

так как в исходном ТЗ не было упоминания про кол-во клиентов и объем данных, то надо считать, что клиентов 0, данные потеряли,а свет выключили.
...
Рейтинг: 0 / 0
Поругайте Акцесс. Очень надо.
    #32380815
Фотография Владимир Саныч
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Как раз было сказано:Данных может быть до 100 000 записей
...
Рейтинг: 0 / 0
Поругайте Акцесс. Очень надо.
    #32381067
c127
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
2 aPT
> -Работа будет клиент-сервер.

Так же вот оно: акцес это не клиент-сервер по определению. На сервер он не тянет ни в каком приближении. Вообще по-правильному он называется файл-сервер.

Еще: по-моему VB поддерживается только до конца этого года. Так зачем вам клиент на VB? А акцес или молча прикроют или переведут на акцес.нет и потребуют полное переписывание всех приложений. Правда с дельфи может случиться та же история.

В мире осталась всего одна компания, поддерживающая файл-сервер - мелкософт. И всего 2 ФС продукта: акцес и фокспро. И при этом постоянно курсируют слухи о прекращении поддержки фокспра, т.е. сокращении количества доступных на рынке продуктов вдвое.
...
Рейтинг: 0 / 0
Поругайте Акцесс. Очень надо.
    #32381169
Фотография Лох Позорный
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Радуют меня люди, которые ни ухом ни рылом в аксесе, но рассуждают о чугуниевых тормозах, невозможности обработки 100000 записей, и о том, что аксес не может быть клиент-сервером.
Поругать что-ли FB - благо я о нем ничего не знаю...

2 Саныч
А 100000 - может сколь угодно места занимать, и много, и мало (тем более до 100000)
...
Рейтинг: 0 / 0
Поругайте Акцесс. Очень надо.
    #32381270
Фотография # Darth Vader #
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
>А акцес или молча прикроют или переведут на акцес.нет
Вот это гвоздь программы будет.
...
Рейтинг: 0 / 0
Поругайте Акцесс. Очень надо.
    #32381312
aPT
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Акцессу точка НЕТ!!!!!!!!
Спасибо вам, теперь мы этих злыдней разобьем в пух и прах
...
Рейтинг: 0 / 0
Поругайте Акцесс. Очень надо.
    #32381325
Фотография Senin Viktor
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ЛП прав - 100000 записей - это м.б. объем 1 Мб, а м.б. более 2Гб.
Кол-во юзверей - неизвестно, а это в частности определяет, "какой" Акес использовать - как СУБД (mdb-формат) или как клиента к MS SQL (или MSDE) (формат adp - а это уже клиент-серверное приложение).
Если речь идет о adp - то спорить по поводу "Акес против ХХХ" можно до усрачки - все зависит от конкретного проекта, а судя по высказыванию автора: уже есть программа на Акесе и она вроде и работает, в отличии от FB.
И никто в спорах не сможет привести ни одного существенного аргумента "за"/"против"

Лучше давайте выясним - с какого конца надо разбивать яйцо: с тупого или острого? :)
...
Рейтинг: 0 / 0
Поругайте Акцесс. Очень надо.
    #32381332
alex_k
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Я же со своей стороны накатал на FireBird.
читаем внимателно (с) цк
...
Рейтинг: 0 / 0
Поругайте Акцесс. Очень надо.
    #32381625
Фотография Senin Viktor
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2alex_k
>читаем внимателно
>Я же со своей стороны накатал на FireBird.

Извини, за не внимательность,

но так еще хуже: тогда получатся, что
Acess=FireBird, коль и у тебя и у них все работает?
Т.е. Акес справился с задачей, к тому же (скорей всего) за более короткое время. Предлагаю ругать тезис: На Акесе можно сделать быстро то, что на FireBird дольше. :)
...
Рейтинг: 0 / 0
Поругайте Акцесс. Очень надо.
    #32381644
alex_k
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Т.е. Акес справился с задачей, к тому же (скорей всего) за более короткое время
ну и откуда ты это взял? это я про "более короткое время" :-)
...
Рейтинг: 0 / 0
Поругайте Акцесс. Очень надо.
    #32381844
karly™
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
c127В мире осталась всего одна компания, поддерживающая файл-сервер - мелкософт.
За весь мир ручаться не буду, а на рассейских просторах - 1С.

с127И при этом постоянно курсируют слухи о прекращении поддержки фокспра.
Первый же пункт по ссылке
...
Рейтинг: 0 / 0
Поругайте Акцесс. Очень надо.
    #32382384
F-Pro
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
==В мире осталась всего одна компания, поддерживающая файл-сервер - ==мелкософт. И всего 2 ФС продукта: акцес и фокспро. И при этом постоянно ==курсируют слухи о прекращении поддержки фокспра, т.е. сокращении ==количества доступных на рынке продуктов вдвое.

ну вы прогнали... че жарптица насрала на голову?
кто закроет фокспру? Билли?
да он скорей Дедьфи затюкает донельзя и на Борланд бомбу скинет.....
Фокспро рулить будет и будет еще.. исходя из выхода новых версий продукта...
...
Рейтинг: 0 / 0
Поругайте Акцесс. Очень надо.
    #32382410
c127
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
2 karly™
> c127
> В мире осталась всего одна компания, поддерживающая >файл-сервер - мелкософт.
>
>За весь мир ручаться не буду, а на рассейских просторах - 1С.

1С это вообще не СУБД, это специализированная система бухгалтерского/складсого и какого-то еще учета, построенная на основе файл сервера. Есть версии под MSSQL, но ее же SQL сервером никто не называет.

2 F-Pro

>Фокспро рулить будет и будет еще.. исходя из выхода новых версий продукта...

Перед прекращением поддержки абсолютно любого продукта была выпущена хотя бы одна его версия.

Может ты и прав, я же не спорю, я написал: слухи курсируют.

2 All

Не нужно заводиться, речь не о том, кто круче. Почитайте внимательно постановку задачи: ПОРУГАТЬ систему: акцесс как СУБД для клиент-сервера. Ругаем: акцесс клиент-сервер? Нет, он файл-сервер. Условиям задачи вообще не удовлетворяет.

Читаем дальше: клиент написан на VB. Ругаем: выпуск VB уже год как прекращен, а поддержка прекращается через 11 месяцев. Зачем нужен клиент на официально умершем софте, одни проблемы.

Какие еще вопросы?
...
Рейтинг: 0 / 0
Поругайте Акцесс. Очень надо.
    #32382554
Фотография # Darth Vader #
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Рассмотрим ближайших родственников FoxPro, схожих с ним по типу решаемых задач. Вообще в прессе высказывались опасения о «смерти» FoxPro, ибо его ниша сжимается под давлением тяжеловесных монстров (Oracle и SQL) сверху и пакетов быстрой разработки СУБД типа Access снизу. Да еще поджимают популярные языки Delphi и Visual Basic, имеющие средства для работы с базами данных. Но популярность, простота и мощь любимого многими языка навсегда развеяли подобные страхи.
Старший брат FoxPro, если так можно выразиться, - это продукт фирмы Oracle - вечный конкурент Microsoft в секторе СУБД. По прессе известно, что продукцию Oracle выбрал, например, такой монстр, как «Мосэнерго» для комплексного управления финансовыми, энергетическими, кадровыми, производственными и прочими потоками. С получением моментальной информации по любому срезу этого многомерного клубка. Задача, схожая с задачами, решаемыми FoxPro, но колоссальные масштабы, конечно, делают такие мощные пакеты специфичными и неэффективными для рассмотренных выше «мелочовок». Хотя FoxPro создан не для мелочей, известно, например, что база данных строящегося под Ламаншем тоннеля была написана на FoxPro и проработала удачно все годы строительства.
Некоторые знакомые программисты перешли на Visual Basic, так как этот приятный и мощный язык имеет возможность создавать и обрабатывать реляционные таблицы. И хотя он содержит большое количество объектов, библиотек, процедур и функций, в нем нет имеющихся в FoxPro специальных команд для обработки СУБД, их приходится писать заново средствами Visual Basic'a. Так что выбор языка написания СУБД определяется решаемой задачей или пристрастиями программиста.
Младшим родственником FoxPro являются средства самостоятельной разработки СУБД, самый яркий представитель которых - популярнейший пакет Access, входящий в Microsoft Office. Дружественная оболочка и наличие подсказок и многочисленных мастеров (Wizard) позволяют неспециалисту в течение нескольких минут создать таблицу или БД и разработать механизм для работы с ней - добавление, удаление, просмотр, сортировка, выборка и разные сложные отчеты. Например, сотрудник набрал в Word'e список имеющихся книг, но ему сказали, что нужна картотека учета книг. В течение секунд список был конвертирован в Access и распечатан в виде карточек. Еще пример: из минского журнала «Радиолюбитель. Ваш компьютер» технологи инструментального цеха разработали систему автоматического получения технологии изготовления инструментальных оправок. Access запрашивает размеры и материал и выдает лист технологии с эскизом, с режущим и мерительным инструментом, с числом проходов резца, с режимами резания и нормами времени. Сложные программы самим создавать, возможно, затруднительно (хотя известны мощные пакеты, созданные крупными фирмами именно на Access), но написать учет личных финансов, например, под силу любому юзеру.


/http://ru.infocom.uz/
...
Рейтинг: 0 / 0
Поругайте Акцесс. Очень надо.
    #32382555
Фотография Senin Viktor
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2alex_k
>ну и откуда ты это взял? это я про "более короткое время" :-)

Я знаю Акес как средство очень быстрой разработки прог для бд. Интегрированность СУБД и клиента в одном флаконе + полезные фичи -очень сильно упрощают/ускоряют работу. Не знаю кто и что за клиент у твоей FB, но сколько времени нужно, например, на создание одной главной формы и в ней связанную подчиненую с возможностью поиска и фильтрации по всему открытому набору данных?
А сколько времени нужно на создание отчета на основе этой формы (такое же условие: главный отчет + подчиненый ?
На Акесе минут 3-5 со всеми работами под ключ и без единой строчки кода. Со всем. Т.е. все мышкой :)
...
Рейтинг: 0 / 0
Поругайте Акцесс. Очень надо.
    #32382591
alex_k
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
(даже не знаю как обратится-то)
Коллега!
больше внимательности!
Это не моя программа!
Это не я ее писал!
Это не я ее собираюсь продвигать!

Но!

То что на аксесе сделано быстрее ты вывел только! из своих рассуждений.
Не из материалов данного топика.
Откуда ты знаешь тех людей, их скорость? откуда ты знаешь скорость разработки разработчика на дельфи?
я думаю ты не прав говоря "скорее всего".

про скорость разработки на аксесе не могу с тобой спорить.
вот прямо сейчас юзаю аксес как средство вспомогательной разработки.
это просто ужасно.
то что я на дельфи делаю за минуты, сдесь отнимает часы.
давай уже объективно применять субъективность.
...
Рейтинг: 0 / 0
Поругайте Акцесс. Очень надо.
    #32382889
Фотография # Darth Vader #
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
>то что я на дельфи делаю за минуты, сдесь отнимает часы.

В прямом смысле слова? Это зачем дельфи с Access сравнивать?
Это средства разного калибра! Для своего круга задач!
На запорожце ведь в формуле 1 не ездят.
...
Рейтинг: 0 / 0
Поругайте Акцесс. Очень надо.
    #32382913
aPT
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Коллеги, только давайте на личности не будем переходить. Все равно субьективные рассуждения на тему "А у меня генератор круче" ни к чему не приведут. Да и ветка свою миссию выполнила.
...
Рейтинг: 0 / 0
Поругайте Акцесс. Очень надо.
    #32382933
Фотография fedd
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Кто выиграл тендер-то?
...
Рейтинг: 0 / 0
Поругайте Акцесс. Очень надо.
    #32382935
Фотография fedd
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
мой любимый аксес или мой любимый фаерберд? ;)))
...
Рейтинг: 0 / 0
Поругайте Акцесс. Очень надо.
    #32382950
aPT
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Рано пока об этом. На 75% победа за мной. Открытая борьба только началась.
...
Рейтинг: 0 / 0
Поругайте Акцесс. Очень надо.
    #32382951
alex_k
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
а на аксесе можно клиента к fb сделать?
...
Рейтинг: 0 / 0
Поругайте Акцесс. Очень надо.
    #32382964
aPT
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Можно, но не нужно.
...
Рейтинг: 0 / 0
Поругайте Акцесс. Очень надо.
    #32382982
Фотография fedd
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
можно, если есть одибиси. я когда боялся командной строки, через аксесс с мойсквелем работал.... делов то.

но там есть спецфича по работе с MSSQL - это правда. то есть база на MSSQL, а морда - на Access. Это сочетает плюсы аксеса как средства быстрой и красивой виндовой разраобтки и клиент-серверных технологий, о чем мужики из аксессного форума и пытались сказать, круто загибая пальцЫ ;))
...
Рейтинг: 0 / 0
Поругайте Акцесс. Очень надо.
    #32383087
Фотография Senin Viktor
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2alex_k
Коллега!
Теперь и я прошу быть внимательней :)
Я же сказал "скорей всего" быстрей, а не одназначно "быстро, супер быстро".
Есно, все зависит от уровня знания прогеров и наличии "домашних заготовок".

И, если можно, расскажи, что в Акесе занимает часы, а в Дельфи - минуты. Возможно смогу подсказать, как и на Акесе сделать быстрей. Только, конечно, задавай вопрос в форуме по Акесу, ну, или пиши на е-маил: senin_job#zyx.ru
...
Рейтинг: 0 / 0
Поругайте Акцесс. Очень надо.
    #32383871
c127
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
2 Eternal

Благодарю за цитатку, развеселил. "Старший брат FoxPro, если так можно выразиться, - это продукт фирмы Oracle - вечный конкурент Microsoft в секторе СУБД."

2 aPT

Успехов.
...
Рейтинг: 0 / 0
Поругайте Акцесс. Очень надо.
    #32383877
Фотография Cat2
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Модератор форума
Для меня главным недостатком ACCESS, впрочем как и любой другой файл- серверной БД, является отсутствие транзакций. Любой аппаратный сбой может привести в к появлению в базе неполных и противоречивых данных.

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

Недостаток спорный, но присутствующий. M$ уже отказалось от развития Jet. Наверняка создатели проги на VB работают через него. Если в будущем в Jet обнаружится дыра, то не факт, что M$ будет ее латать. А переход с Jet на ODBC штука не совсем тривиальная, особенно если вся логика делается на клиенте.

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

Разные версии Access не совместимы. Пускай сейчас стоит самая современная. Через некоторое время она станет "предыдущей". И будет очень весело, когда кто-нибудь их крутых юзеров откроет базу Access-2002 из Access-2005 и переконвертит ее в новый формат. Это не смертельно, но на пол дня работа будет парализована. Это конечно слабый аргумент, но все же.
...
Рейтинг: 0 / 0
Поругайте Акцесс. Очень надо.
    #32383898
Фотография Лох Позорный
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Cat2, не ешь коричневые грибы

Для меня главным недостатком ACCESS, впрочем как и любой другой файл- серверной БД, является отсутствие транзакций.
В аксесе всю жизнь были мало того что транзакции, так еще и изначально распределенные, и полноценно вложенные друг в друга
Любой аппаратный сбой может привести в к появлению в базе неполных и противоречивых данных
Аппаратный сбой может привести к появлению в базе чего угодно. И не только в аксесе, но и в любой СУБД. От царапанья головок по винту ничто не спасет. Другое дело, что в аксесе система управления распределена по всем клиентам сразу, и из-за этого страдает общая надежность. Это минус. Но с транзакциями это не связано.
Работая с аксесом получить неполные и противоречивые данные в результате сбоя на клиенте - это еще постараться надо. В 99% сбоев будет просто падение базы в откатом всех незавершенных транзакций. При этом достаточно маломальски грамотного построения сети, чтобы сбои были сами по себе редкостью (максимум раз в несколько месяцев)

Недостаток поменьше. На ACCESS невозможно сделать резервную копию базы без отключения от нее всех обычных пользователей.
Утверждалось, что это есть в 2003-м аксесе. сам не проверял.

Недостаток спорный, но присутствующий. M$ уже отказалось от развития Jet. Наверняка создатели проги на VB работают через него. Если в будущем в Jet обнаружится дыра, то не факт, что M$ будет ее латать.
Для Jet 4.0 и так уже восьмой сервис пак вышел. Куда уж дальше то латать :)
Вон, к NT не выходит сервис-паков (после 6-го) - дык и на фиг не надо.

Разные версии Access не совместимы.
По формату данных - обратная совместимость полная. Из 2002-го аксеса спокойно линкуйся к аксесу 2.0 и работай.
По VBA-коду, библиотекам, формочкам и прочее - начиная с 97-го все более новые версии нормально конвертируются в новый формат. 2002-й и 2003-й спокойно исполняют код 2000-го и выше даже без конвертации.
Это только с переводом аксеса 2.0 на 97-й были серьезные проблемы. Но когда это было?

когда кто-нибудь их крутых юзеров откроет базу Access-2002 из Access-2005 и переконвертит ее в новый формат
mde/ade тебе в помощь. устанет юзер мде конвертить :)

SQL-сервера обладают более развитой системой...
Более развитой системой всего чего угодно. Давай не сравнивать мотоцикл с камазом? В булочную на камазе ездить не станешь.
Аксес в формате мдб - настольная база. У него свой сегмент.
В формате адп - весьма неплохой клиент к MS SQL. Гиперфункциональность и бешеная скорость разработки клиента (хотя и своих тараканов хватает).
Есть еще и формат "мдб+одбц+любой sql server", но это извращение. мутант мертворожденный. годится только как временное решение.
...
Рейтинг: 0 / 0
Поругайте Акцесс. Очень надо.
    #32384017
Фотография # Darth Vader #
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 ЛП
>В булочную на камазе ездить не станешь.
Это точно.

Так ведь надо было Access в этом топике опустить перед FB, а ты его расхваливаешь.
...
Рейтинг: 0 / 0
Поругайте Акцесс. Очень надо.
    #32384528
Фотография Лох Позорный
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 Eternal
Я не расхваливаю. Я указываю на ошибки в ругани других.
На FB мне вообще пофиг, я зверя такого не знаю, поэтому опустить аксес перед FB - да легко! Крекс-фекс-пекс-аксес опустись! Контрольный трахтибидох!
Как можно ругать какое-то средство не зная задачи, для решения которой оно было выбрано? А тут ничего не известно, кроме того, что 10 пользователей и 100000 записей.

2 Cat2
Во! Вспомнил, что ты действительно забыл в указании недостатков! Отсутствие триггеров. В совокупности с обработкой на клиенте - оч нехорошо. Приходится извращаться.
З.Ы. Еще раз приколюсь над фразой "отсутствие транзакций в любой файл- серверной БД".
В MySQL вроде тоже не было транзакций? Теперь вроде они появились, но правда ли, что MySQL когда-то тоже был файл-серверной БД?
...
Рейтинг: 0 / 0
Поругайте Акцесс. Очень надо.
    #32384686
IgorM
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2ЛП: Транзакции Access, к сожалению, не всегда спасут от сбоев в работе, особенно в сетевой базе. Сам с этим сталкивался.
...
Рейтинг: 0 / 0
Поругайте Акцесс. Очень надо.
    #32384731
Фотография Лох Позорный
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Транзакции Access, к сожалению, не всегда спасут от сбоев в работе, особенно в сетевой базе.
Двумя руками за! Действительно не спасут. И я с этим сталкивался.
И от сброса чугуниевой бомбы на хрупкий винчестер - тоже не спасут (хоть я с этим не сталкивался).
Да и не должны транзакции этим заниматься. Транзакция - это логическая единица работы (определение из Дейта), к системе обеспечения отказоустойчивости относится постольку поскольку, в ACID св-вах ни слова о сбоях.

Продолжаю цитировать Дейта:
"Замечание. Тема восстановления носителей представляет собой нечто совершенно самостоятельное и не имеющее отношения к транзакциям и восстановлению системы после сбоев. Она включена в данное обсуждение только для завершенности всей картины."

Устал цитировать Дейта. В общем, есть "мягкие отказы" (не нарушающие физического состояния базы) и "жесткие отказы" (например, отказ носителя).
Если мы говорим о "мягких отказах" - то транзакции в аксесе работают ровно так, как им и положено. Если о "жестких" (база рухнула, причем рухнула экстремально) - то механизм транзакций тут и не при чем.
...
Рейтинг: 0 / 0
Поругайте Акцесс. Очень надо.
    #32384845
Фотография Gluk (Kazan)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 LP

Устал слушать ахинею, только по этой причине пишу. Транзакции подразумевают (четвертым свойством ACID) ДЛИТЕЛЬНОСТЬ. Т.е. при фиксации транзакции, информация сохраняется (надолго). Это подразумевает устойчивость к сбоям (в том числе и аппаратным). От сброса чугуниевой бомбы спасает backup/recovery в нормальных СУБД ОЧЕНЬ сильно завязанная на понятие транзакций.
...
Рейтинг: 0 / 0
Поругайте Акцесс. Очень надо.
    #32384871
Фотография Лох Позорный
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Т.е. при фиксации транзакции, информация сохраняется (надолго)
Что и происходит в аксесе. Если фиксация, конечно, прошла. Вопросы?

От сброса чугуниевой бомбы спасает backup/recovery в нормальных СУБД ОЧЕНЬ сильно завязанная на понятие транзакций.
Она может быть хоть узлом завязана, мне то что?
В MySQL бекапов нет совсем, да? Потому как там транзакций нет? Сори, не было раньше. Да?
Не смешите мои тапки. В следующий раз будете проходить мимо - проходите дальше. Не слушайте ахинею.
...
Рейтинг: 0 / 0
Поругайте Акцесс. Очень надо.
    #32384931
Фотография Gluk (Kazan)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Я сказал в нормальных СУБД
...
Рейтинг: 0 / 0
Поругайте Акцесс. Очень надо.
    #32384949
f_w_p
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
В MySQL бекапов нет совсем, да? Потому как там транзакций нет? Сори, не было раньше. Да?
А и вправду, как без транзакций сделать BACKUP?
...
Рейтинг: 0 / 0
Поругайте Акцесс. Очень надо.
    #32384975
Фотография Лох Позорный
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 Глюк
Я сказал в нормальных СУБД
А Дейт, видать, писал исключительно про плюшевые СУБД, ибо (еще раз):
" Тема восстановления носителей представляет собой нечто совершенно самостоятельное и не имеющее отношения к транзакциям и восстановлению системы после сбоев."

То, что система транзакций может быть использована системой backup/recovery - да пожалуйста. Лишний плюс ораклу и всем кто так делает. Только не надо ставить знак равенства между этими двумя системами.
И вообще, мы здесь аксес ругаем, а не оракл хвалим :)

2 f_w_p
А и вправду, как без транзакций сделать BACKUP?
А хрен его знает товарисч майор.
Взять палку, выгнать всех из базы нафиг, и тупо сделать бекап путем копирования файлов с данными :)
В аксесе так и делается (попрошу заметить - не потому что транзакций нет :))
Cat2 об этом уже упомянул. Интересно послушать обладателей 2003-го аксеса - сделали там то, о чем так долго говорили большевики (бекап базы без выгоняния всех юзеров)?
...
Рейтинг: 0 / 0
Поругайте Акцесс. Очень надо.
    #32385016
IgorM
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ЛПИнтересно послушать обладателей 2003-го аксеса - сделали там то, о чем так долго говорили большевики (бекап базы без выгоняния всех юзеров)?

Нет. На сколько я понимаю, при бэкапе база должна быть открыта монопольно.

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

ЛПИ вообще, мы здесь аксес ругаем

Вот именно, так что не влезай в оффтопик. ;)
...
Рейтинг: 0 / 0
Поругайте Акцесс. Очень надо.
    #32385036
Фотография Лох Позорный
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
допустим, MSSQL откатит все незавершенные транзакции после сбоя, то от Access'а, по понятным причинам, этого ждать не приходится
А что он по твоему сделает? Commit?
У меня дежавю? Не далее как вчера вечером я задавал этот вопрос в ответ на подобное же утверждение в форуме по аксесу.

На сколько я понимаю, при бэкапе база должна быть открыта монопольно.
Не вижу предпосылок для такого утверждения.
Понятно, почему в предыдущих версиях (до 2002-го включительно) нельзя сделать бекап не выгнав предварительно всех. Просто потому, что в аксесе отсутствует как явление встроенная в аксес же система резервного копирования. Приходится бекапить внешними средствами , что нереально при работающих в базе пользователях - во всех базах без исключения, а не только в аксесе.
Почему нельзя сделать встроенное в аксес средсво для бекапа, или почему для бекапа надо открывать базу монопольно - мне пока непонятно.

И вообще, мы здесь аксес ругаем
Вот именно, так что не влезай в оффтопик. ;)
Ну ладно, давай поругаем
Аксес - АЦТОЙ!
Патамушта не умеет делать бекап, в нем не могут работать больше пяти юзеров, при размере базы больше одного мегабайта - тормоза чугуниевые, в нем нет транзакций, и вообще он для хранения данных использует экселевские файлы!
У меня хорошо получилось?
...
Рейтинг: 0 / 0
Поругайте Акцесс. Очень надо.
    #32385037
MSSQL откатит все незавершенные транзакции после сбоя, то от Access'а, по понятным причинам, этого ждать не приходится. ГЫ!!! - а что же он с ими сделал?......

Хихихи......Такое впечатление, что откат тразакции - это такая операция, уууу какая большая и сложная :).
...
Рейтинг: 0 / 0
Поругайте Акцесс. Очень надо.
    #32385049
Фотография Gluk (Kazan)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 ЛП

Вы совершенно правы, Access АЦТОЙ и ссылки на (кстати уважаемого мной) Дейта его не спасают. Патамушта, в случае падения он сделает не commit и не rollback, а элементарно нарушит логическую (а возможно и физическую) целостность базы данных. По моему это ОЧЕНЬ плохо. Я пошел домой, по этой причине свое участие в сей дивной дискуссии заканчиваю.

Ничего личного
...
Рейтинг: 0 / 0
Поругайте Акцесс. Очень надо.
    #32385056
А у меня на акцессе 20 чел база - 100 Мб, склады, заказы, динамические прайс-листы, заказчики, накладные и т.п. - в общем целая контора(кроме бух. учета) с обротом в десятки млн.евро работает. И транзакции там есть, а на тормоза нткто не жалуется. Я понимаю, что клиент-сервер лучше, и сейчас хочу на него переходить, но не потому, что Акцесс плох. В течении 5 лет он полностью всех удовлетворял. Просто выросли мы из него.... Но раньше это был оптимальный вариант.
...
Рейтинг: 0 / 0
Поругайте Акцесс. Очень надо.
    #32385075
Фотография Лох Позорный
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 Глюк
в случае падения он сделает не commit и не rollback, а элементарно нарушит логическую (а возможно и физическую) целостность базы данных.
Вот именно это я и имел в виду, когда говорил про "ни ухом ни рылом в аксесе".
Ничего личного

2 мимо пробегал
Ну а у меня 100-150 человек база 300метров в центральном офисе. И тоже никто чугуниевых тормозов не наблюдает
За 2 года ни одного случая "нарушения логической целостности данных"
...
Рейтинг: 0 / 0
Поругайте Акцесс. Очень надо.
    #32385153
IgorM
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
авторА что он по твоему сделает? Commit?
Вполне возможно нарушение данных, о чем тебе писали. То что у тебя это не встречалось - очень хорошо, у меня было, очень редко, но было.

Что касается устойчивости к сбоям - последняя буква в ACID, говорит именно об этом. Открываем MSDN и читаем (Using Transactions):

Durable denotes that after a transaction is committed, its updates survive — even if there is a subsequent system crash.

И далее:

Important File-server databases, such as the Jet database engine, can't guarantee durable transactions. There are currently no file-server—based database engines that can fully support this criterion of true transactions. For example, a database connected to a file server can't be expected to fully support the durability rule if the file server crashes before a transaction has had time to commit its changes. If you require true transaction support with respect to durability, you should investigate the use of a client/server database engine such as SQL Server or the Microsoft Data Engine (MSDE).
...
Рейтинг: 0 / 0
Поругайте Акцесс. Очень надо.
    #32385160
IgorM
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ЛПНе вижу предпосылок для такого утверждения.

Я попробовал.

ЛППочему нельзя сделать встроенное в аксес средсво для бекапа, или почему для бекапа надо открывать базу монопольно - мне пока непонятно.

Потому что данные (если речь о сетевой версии) обрабатываются не централизованно.
...
Рейтинг: 0 / 0
Поругайте Акцесс. Очень надо.
    #32385355
Фотография Лох Позорный
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 IgorM
По поводу бекапа - возражений нет. Понял, закопался на два метра :)

Это был кусок, по которому нет возражений. Теперь возражения:

По поводу транзакций.
Копирую цитату из MSDN
For example, a database connected to a file server can't be expected to fully support the durability rule if the file server crashes before a transaction has had time to commit its changes.
Какое накуй Durability если сервер crashes before??? Вы млять о чем? С Лукоморья приехали? Где дуб рухнул?
Выкинь нафих такой MSDN, я тебе новый подарю. Читай больше классиков (того же Дейта)

Вполне возможно нарушение данных, о чем тебе писали
То, что возможно нарушение данных - мне не надо писать. Я это сам могу написать маслом. Это как то связано с транзакциями ? А?
Я с трех кликов любую аксесовскую базу уроню напрочь (не поднимется никак). И там не будет ни одной транзакции. Веришь, нет?

у меня было, очень редко, но было.
Что именно? Транзакция не сработала? Т.е. 1) начал транзакцию 2) добавил запись 3) закоммитил транзакцию 4) посмотрел - а записи зуй? И при этом база жива и здорова? Не верю . Не читай сказки на ночь.
(если еще раз подтвердишь, что так оно и было - может и поверю, чудеса таки бывают)
...
Рейтинг: 0 / 0
Поругайте Акцесс. Очень надо.
    #32385517
c127
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
2 Лох Позорный

>В MySQL вроде тоже не было транзакций? Теперь вроде они появились, но правда ли, что MySQL когда-то тоже был файл-серверной БД?

>Я с трех кликов любую аксесовскую базу уроню напрочь (не поднимется никак). И там не будет ни одной транзакции. Веришь, нет?

Ты постоянно зачем-то перепутываешь необходимые и достаточные условия. Если нет транзакций, то это не значит, что система - файл сервер. Это значит, что система не SQL сервер и ничего больше.

Если нет транзакций то это не значит, что нельзя уронить систему до неподъемного состояния. Как раз можно. А вот с транзакциями нельзя: если только диски целы система должна откатиться до состояния последнего завершенного комита. Это конечно в теории. На практике наверное не так красиво, хотя я не знаю ни одного случая гибели SQL БД или даже каких-то проблем с самовосстановлением SQL сервера.
...
Рейтинг: 0 / 0
Поругайте Акцесс. Очень надо.
    #32385538
f_w_p
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
А хрен его знает товарисч майор. Взять палку, выгнать всех из базы нафиг, и тупо сделать бекап путем копирования файлов с данными :)
Так вот тож!

Ну а у меня 100-150 человек база 300метров в центральном офисе. И тоже никто чугуниевых тормозов не наблюдает
Не верю. (С) Станиславский.
Не про 300М. Про 150 человек. Никакая сетка не потянет такую БД на ACCESS. М.б. у тебя клиент к MSSQL? Или сетка сплошь Гигабит?
...
Рейтинг: 0 / 0
Поругайте Акцесс. Очень надо.
    #32385869
IgorM
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ЛПКакое накуй Durability если сервер crashes before??? Вы млять о чем? С Лукоморья приехали? Где дуб рухнул?

Упал, прежде чем транзакция успела реально обновить данные. Ты как-то выборочно читаешь... Что скажешь про определение Durable в совокупности с "Jet database engine, can't guarantee durable transactions..."?

ЛПВыкинь нафих такой MSDN, я тебе новый подарю. Читай больше классиков (того же Дейта)

Разговор о конкретной реализации...

ЛПЧто именно? Транзакция не сработала? Т.е. 1) начал транзакцию 2) добавил запись 3) закоммитил транзакцию 4) посмотрел - а записи зуй? И при этом база жива и здорова? Не верю. Не читай сказки на ночь.
(если еще раз подтвердишь, что так оно и было - может и поверю, чудеса таки бывают)

Не верь, я тебя не заставляю. База жива и здорова, но изменения прошли лишь частично (в сетевом варианте на "тяжелой" базе). Признаюсь, что dbFlushOSCacheWrites не использовал, но читал что при наличии этого флага сбои возможны.

И вообще, речь не о том, что Access не поддерживает транзакции (я их использую и полезности не отрицаю), а что их реализация менее надежна, чем в серверных системах. Мне кажется это очевидно.
...
Рейтинг: 0 / 0
Поругайте Акцесс. Очень надо.
    #32385954
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Access, БД 1,5 гб. Более менее крутиться, подключено 30 юзеров. Сетка не такая уж толстая. А все потому, что на сервере стоит Terminal Service. Проблем не мало у народа, который все это сделал - например Access любит падать после переползания БД за 2 гига, индексы частенько куда то улетают, админы по ночам ночуют. Terminal Service любит гадости еще подкидывать, особенно касательно печати. Но в принципе как ни странно, все работает. Причем я бы не сказал, что дюже медленно. Вот так вот :)
...
Рейтинг: 0 / 0
Поругайте Акцесс. Очень надо.
    #32386003
IgorM
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ну, для терминала сетка некритична, а вот что база может быть больше 2ГБ, так это странно, если конечно верить спецификациям MS Access.
...
Рейтинг: 0 / 0
Поругайте Акцесс. Очень надо.
    #32386471
Фотография Лох Позорный
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 c127
Ты постоянно зачем-то перепутываешь необходимые и достаточные условия.
Могу даже сказать - зачем. По приколу. В следующий раз пятнадцать смайликов поставлю и слово "лопата" в конце произнесу.
Если нет транзакций, то это не значит, что система - файл сервер. Это значит, что система не SQL сервер и ничего больше
MySQL - не SQL сервер? Ну спасибо что просветил, а то бы я так и помер дураком. Еще бы ты сказал, чем же MySQL является - цены б тебе не было. Неужто иерархической БД?
И еще. Раз в аксесе есть транзакции - значит аксес является SQL сервером?
лопата

2 f_w_p
Не верю. (С) Станиславский.
Не про 300М. Про 150 человек. Никакая сетка не потянет такую БД на ACCESS.
150 рабочих мест, количество активных пользователей колеблется около 100. Бывает и больше.
М.б. у тебя клиент к MSSQL?
Нет. Обычная файл-серверная архитектура. Никаких терминал-серверов, если не считать терминальных подключений из других городов (но их мало).
Или сетка сплошь Гигабит?
Не сплошь. Сплошь - 100 мбит, нормальные свичи, только отдельные куски гигабитные (к сервакам в основном).

2 IgorM
Упал, прежде чем транзакция успела реально обновить данные
Не успела транзакция обновить данные, и что? Просто напросто незавершенная транзакция. Эти данные никуда не попадут, можно считать что их вообще не было никогда. Если транзакция закончилась - то она DURABLE (с точностью до повреждения хранилища данных), а если сервер рухнул до того, как транзакция закончилась - то Commit'а транзакции просто не случилось, бессмысленно спорить - DURABLE то, чего нет, или нет?
Я исхожу из предположения, что флаг фиксации транзакции проставляется после внесения изменений, а не до и не параллельно с ними.

База жива и здорова, но изменения прошли лишь частично
Уверен, что до этого база была в кошерном состоянии? Просто это... не хочется в такие чудеса верить :)
мне почему-то всегда удавалось чисто программистские ошибки находить в подобных случаях. уверен, что у тебя код без ошибок?

Признаюсь, что dbFlushOSCacheWrites не использовал
Я использовал. Этот флаг не работает. По крайней мере на сетевой кеш он никак не влияет. Еще он не влияет на кеширование на стороне файл-сервера, в том числе и на кеш винчестера (вот тебе и еще 8мб потенциально потерянных данных).

И вообще, речь не о том, что Access не поддерживает транзакции
Вообще-то я веду речь именно об этом. Начиная с высказывания Cat2 ("отсутствие транзакций в любой файл-серверной БД")
а что их реализация менее надежна, чем в серверных системах. Мне кажется это очевидно.
Разумеется очевидно. Аксес как хранилище - сам по себе менее надежен, нежели серверные системы. Есть транзакции, нет транзакций - по фигу, надежности аксесу это не прибавит.
Никто и не утверждал, что аксес есть надежнее серверных систем. На слова "аксес - ненадежен" остается лишь жидко обкакаться, поджать хвост и пойти прочь, бормоча под нос "... базе у них рухнула... ну бывает... сами виноваты... сетку не могли нормальную проложить... руки кривые..."
Но против отсутствия транзакций в файл-серверных БД буду сражаться до последнего. Когда погибну смертью храбрых - на смену мне придет мотострелковый взвод оловянных солдатиков.
...
Рейтинг: 0 / 0
Поругайте Акцесс. Очень надо.
    #32386573
IgorM
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ЛПНе успела транзакция обновить данные, и что? Просто напросто незавершенная транзакция. Эти данные никуда не попадут, можно считать что их вообще не было никогда. Если транзакция закончилась - то она DURABLE (с точностью до повреждения хранилища данных), а если сервер рухнул до того, как транзакция закончилась - то Commit'а транзакции просто не случилось, бессмысленно спорить - DURABLE то, чего нет, или нет?


Вот в этом-то и вся разница, транзакция подтверждена (выполнен CommitTrans), данные в буфере, сервер упал. SQL-сервер с полной поддержкой транзакций ее "допроведет" после восстановления, Jet - нет.
=== Access 97 help ===
В рабочей области Microsoft Jet пользователь имеет возможность задать в методе CommitTrans константу dbFlushOSCacheWrites, Это приводит к принудительной записи на диск всех обновлений вместо их помещения во временный буфер. Без этого параметра пользователь может перехватить управление сразу после вызова метода CommitTrans программой приложения, выключить компьютер, и отказаться от записи данных на диск. Хотя включение данного параметра может сказаться на быстродействии приложения, это оказывается полезным в ситуациях, когда возможно отключение компьютера до сохранения на диске кэшированных изменений.
=== Access 97 help ===

ЛПУверен, что до этого база была в кошерном состоянии? Просто это... не хочется в такие чудеса верить :)
мне почему-то всегда удавалось чисто программистские ошибки находить в подобных случаях. уверен, что у тебя код без ошибок?

Не на 100%, но уверен. :) BeginTrans код CommitTrans, прямых выходов из блока нет. При серьезной многопользовательской работе, в сети, глюки, как уже говорил, редко, но ловил. В локальном варианте - нет.

ЛПНачиная с высказывания Cat2 ("отсутствие транзакций в любой файл-серверной БД")

За слова Cat2 не отвечаю, м.б. он имел ввиду именно полную поддержку ACID.

ЛПНо против отсутствия транзакций в файл-серверных БД буду сражаться до последнего. Когда погибну смертью храбрых - на смену мне придет мотострелковый взвод оловянных солдатиков.

Ну, флаг после тебя будет кому поднять.
...
Рейтинг: 0 / 0
Поругайте Акцесс. Очень надо.
    #32386762
Фотография Cat2
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Модератор форума
Господа! Была конкретная задача. "Опустить" Связку .mdb+VB против FB+(не помню что, но для клиент-сервера это не важно).
Если надо, то я могу могу опустить связку MS SQL 2010+Delphi против Clipper 5.2. Элементарно. Серверу на клиппере вполне достаточно 386, а клиенты могут быть на 286. Не надо покупать винду и прочие приблуды. Получается огромная экономия денег.
=======
Лох Позорный.
Я не специалист по Access. Открыл его хелп, запустил поиск по слову "транзакция". Ничего вразумительного не нашел.

Задача. Нужно изменить две таблицы.
На SQL-серверах это решается просто
begin transaction
Изменение таблы1
Изменение таблы2
commit transaction

Если во время "Изменение таблы2" произойдет сбой, то "Изменение таблы1" тоже откатится.
Может ли это Access? Сомневаюсь.
...
Рейтинг: 0 / 0
Поругайте Акцесс. Очень надо.
    #32386775
Фотография Лох Позорный
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 Cat2
Может ли это Access? Сомневаюсь
Cat2, прости великодушно, но ты тоже "ни ухом ни рылом" :)
В DAO-шном синтаксисе
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
On Error Goto Rollback_Label
    DBEngine( 0 ).BeginTrans
        CurrentDB.Execute  "изменение таблы1" , dbFailOnError
        CurrentDB.Execute  "изменение таблы2" , dbFailOnError
    DBEngine( 0 ).CommitTrans
    Exit Sub
Rollback_Label:
    DBEngine( 0 ).Rollback

Cat2 писалЕсли во время "Изменение таблы2" произойдет сбой, то "Изменение таблы1" тоже откатится.
Истинная правда. Даже не сомневайся :)

2 IgorM
Вот в этом-то и вся разница, транзакция подтверждена (выполнен CommitTrans), данные в буфере, сервер упал. SQL-сервер с полной поддержкой транзакций ее "допроведет" после восстановления, Jet - нет
Кажется я начинаю понимать про что ты меня пытаешь лечить
я не тормоз... я не тормоз... я не тормоз...
Видимо ты имеешь в виду ситуацию, когда
Данные изменены, сделан Commit

Измененные данные (вместе со флагом фиксации транзакции) помещены в буфер, в самом хранилеще их еще нет.

Данные из буфера доступны на чтение для всех остальных. И, если не повезет, то они и будут прочитаны (это в общем-то единственно интересный случай, ибо если до сбоя измененные данные никем и ничем не использовались - то и хрен бы с этим сбоем и с этими данными, не было никакого мальчика)

Произошел сбой, данные из буфера схерились (вместе с флагом фиксации транзакции)

Имеем, что, с одной стороны - данные были закомитчены (и даже кем то читались), с другой стороны - этих закомитченых данных почему-то нет. Тогда Durable действительно нарушено.
Я правильно понял? Или я все-таки тормоз?

Предположим, что правильно. Меняем аксес на серверную СУБД. Ты утверждаешь, что " SQL-сервер с полной поддержкой транзакций ее "допроведет" после восстановления ". Вопрос - на каком основании он будет делать Rollforward? На основании имеющегося флага фиксации транзакции? Так он же пропал из буфера вместе с данными :)
Не надо мне говорить, что транзакшнлог надо держать на другом носителе, я и сам об этом могу догадаться. Суть дела это не меняет - после фиксации транзакции у тебя были данные, а после сбоя они пропадут вместе с куском транзакшнлога. Просто напросто пропадут из кеша жесткого диска. С какой-то вероятностью.

По поводу dbFlushOSCacheWrites
Не стоит слепо верить хелпу. В хелпе может быть написано, что эта опция приведет к установлению комунизма в отдельно взятой базе.
DAO не имеет возможности управлять системным кешом, кешом сетевого редиректора и кешом жесткого диска. Что бы тебе там хелп не говорил. Проверялась работа (вернее неработа) этой опции неоднократно и не только мной.
...
Рейтинг: 0 / 0
Поругайте Акцесс. Очень надо.
    #32386785
Фотография Cat2
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Модератор форума
Лох Позорный - спасибо.
...
Рейтинг: 0 / 0
Поругайте Акцесс. Очень надо.
    #32386788
c127
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
2 Лох Позорный

>Могу даже сказать - зачем. По приколу. В следующий раз пятнадцать смайликов поставлю и слово "лопата" в конце произнесу.
MySQL - не SQL сервер? Ну спасибо что просветил, а то бы я так и помер дураком. Еще бы ты сказал, чем же MySQL является - цены б тебе не было. Неужто иерархической БД?
И еще. Раз в аксесе есть транзакции - значит аксес является SQL сервером?
лопата

Поскольку пятнадцать смайликов, необходимых для обозначения шутки, не обнаружено, объясняю специально для прикольных знатоков акцеса: MySQL не является SQL сервером, более точно он не является РСУБД в смысле Кодда.

>Cat2, прости великодушно, но ты тоже "ни ухом ни рылом" :)
В DAO-шном синтаксисе

Похоже что причина взаимного непонимания прояснилась. Лох Позорный зачем-то, очевидно опять по-приколу (не подумайте что по незнанию), относит DAO к СУБД. Остальные наивняки после утверждения "транзакции в акцесе есть" кинулись по-привычке искать транзакции в самом акцессе и судя по всему не нашли.

Так вот это в системе DAO - акцесс может быть некое подобие транзакций и реализовано, но вот беда: DAO не является акцессом и даже не является его частью. На всякий случай поясняю для лохов: DAO - data access object есть средство обмена данными между приложением и базой данных, вроде ODBC, и к самой СУБД отношения не имеет. Конечно же Лох Позорный и об этом знал, просто решил поприкалываться, а мы повелись.
...
Рейтинг: 0 / 0
Поругайте Акцесс. Очень надо.
    #32386796
Фотография Лох Позорный
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Здравствуй, буквацифра!
Я тоже рад тебя видеть!
Огромное спасибо тебе за то, что ты еще раз напомнил нам о том, что MySQL не является РСУБД. Надеюсь, что ты произнесешь это и в третий, и, если звезды будут к нам благосклонны, даже в четвертый раз.
Однако ты так и не ответил - чем же является MySQL? Просвети нас, неграмотных, а то ведь так и будем знать только то, чем он не является.

Давным давно мне говорили, что Ульянов-Ленин - это один человек, а не два, Карл Маркс и Фридрих Энгельнс - два человека, а не четыре, а Слава КПСС - вообще не человек.
Теперь, благодаря тебе, я знаю, что DAO - это совсем не СУБД. Господи, щастье то какое
Но просвети меня, о великая буквацифра, если DAO - не СУБД, то, наверное, приведенный вторым котом кусочек SQL-скрипта - тоже не СУБД? И ведь тогда выходит, что некий MS SQL, использующий этот самый SQL - тоже не СУБД? И пусть в SQL есть слова "begin transaction" и "commit transaction" - но самих то транзакций в MS SQL, получается, нет?

Че делать, мужики?
...
Рейтинг: 0 / 0
Поругайте Акцесс. Очень надо.
    #32387044
IgorM
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ЛПКажется я начинаю понимать про что ты меня пытаешь лечить... Видимо ты имеешь в виду ситуацию, когда...
Это не я, а тех. документация от MS. Аналогично с ситуацией, когда во время сетевой работы по обновлению данных отваливается клиент. Результат такого события для SQL-сервера и файл-серверной БД может быть различен.

ЛППредположим, что правильно. Меняем аксес на серверную СУБД. Ты утверждаешь, что "SQL-сервер с полной поддержкой транзакций ее "допроведет" после восстановления". Вопрос - на каком основании он будет делать Rollforward? На основании имеющегося флага фиксации транзакции?

На основании transaction log.

ЛПТак он же пропал из буфера вместе с данными :)

Никуда он (файл регистрации транзакций) не пропал. Access его тоже не в памяти держит, другое дело, что SQL-сервер после сбоя его видит и использует именно для roll forward, а Access нет. Цитаты из хелпа приводить?

ЛППо поводу dbFlushOSCacheWrites
Не стоит слепо верить хелпу. В хелпе может быть написано, что эта опция приведет к установлению комунизма в отдельно взятой базе. DAO не имеет возможности управлять системным кешом, кешом сетевого редиректора и кешом жесткого диска. Что бы тебе там хелп не говорил. Проверялась работа (вернее неработа) этой опции неоднократно и не только мной.

Не спорю, jet чужими кэшами не рулит, но хелп четко определят, что этот параметр используется для управления своим буфером (транзакций). Ссылки есть, что этот параметр никакой роли не играет?
...
Рейтинг: 0 / 0
Поругайте Акцесс. Очень надо.
    #32387050
IgorM
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
c127Остальные наивняки после утверждения "транзакции в акцесе есть" кинулись по-привычке искать транзакции в самом акцессе и судя по всему не нашли.

Проблема F1, действительно острейшая из проблем.

с127Так вот это в системе DAO - акцесс может быть некое подобие транзакций и реализовано, но вот беда: DAO не является акцессом и даже не является его частью. На всякий случай поясняю для лохов: DAO - data access object есть средство обмена данными между приложением и базой данных, вроде ODBC, и к самой СУБД отношения не имеет.

Можно вопрос: а чем является Jet, транзакции реализованы там (ЛП в пылу дискуссии про DAO не к месту вспомнил)?

ЛПЧе делать, мужики?

Вычеркивай из резюме слова "программист БД".
...
Рейтинг: 0 / 0
Поругайте Акцесс. Очень надо.
    #32387086
Фотография Лох Позорный
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 IgorM
Але, гараж?
Мы говорим о сбоях?
Никуда он (файл регистрации транзакций) не пропал.
Почему не пропал? Очень даже пропал! Вместе со всем жестким диском (содержащим транзакшнлог), если так будет угодно достопочтимому джину. Если маразм - то до логического конца.

ЛП в пылу дискуссии про DAO не к месту вспомнил
Вообще-то я отвечал Cat2 (а даже совсем не буквоцифре). Просто привел пример. Пример работы с транзакциями. Можешь перевести это на ADO, суть не изменится. Можно было бы написать это на чистом SQL, но нельзя в виду ограниченной поддержки SQL.
Если второкотовые "begin trans" и "commint trans" к месту - то и мои BeginTrans и CommitTrans тоже к месту (применительно к теме об аксесе)

если буквацифра в следующий раз будет проходить мимо - пусть буквацифра проходит дальше.
...
Рейтинг: 0 / 0
Поругайте Акцесс. Очень надо.
    #32387087
Фотография Лох Позорный
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
О, забыл!
Вычеркивай из резюме слова "программист БД".
Никому говнокопатель по совместительству не нужен?
...
Рейтинг: 0 / 0
Поругайте Акцесс. Очень надо.
    #32387358
IgorM
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ЛПМы говорим о сбоях?

Мы говорим (по крайней мере я со своей стороны) о степени поддержки транзакций в Access (Jet).

ЛППочему не пропал? Очень даже пропал! Вместе со всем жестким диском (содержащим транзакшнлог), если так будет угодно достопочтимому джину. Если маразм - то до логического конца.

Где я писал, что диск пропал, сервер взорвался, серверная сгорела, здание рухнуло, а потом все закатали в асфальт?
Я говорил только о двух случаях:
1. После commit данные уже в логе транзакций, но не в базе - сбой;
2. Обновление данных в mdb Access'ом по сети - сбой.

ЛПЕсли второкотовые "begin trans" и "commint trans" к месту - то и мои BeginTrans и CommitTrans тоже к месту (применительно к теме об аксесе)

Здесь я погорячился, прошу прощения.
...
Рейтинг: 0 / 0
Поругайте Акцесс. Очень надо.
    #32387452
Фотография Лох Позорный
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Где я писал, что диск пропал, сервер взорвался, серверная сгорела, здание рухнуло, а потом все закатали в асфальт?
Однако почему у тебя могут пропасть любые данные, но только не лог?

1. После commit данные уже в логе транзакций, но не в базе - сбой;
Стоп. Не знаю как аксесе реализован лог транзакций (хотя бы потому что его там в явном виде нет :)), но, по-моему, сначала должны записываться измененные данные, а уже потом в логе должна фиксироваться информация о завершенной транзакции. По крайней мере это было бы логично.
Получается, что:
- данные записались (может быть в какой-то абстрактный буфер/кеш)
- журнал транзакций обновился (тоже может быть в каком-нибудь кеше)
- данные потерялись из-за сбоя
- ты утверждаешь, что SQL-сервер допроведет транзакцию на основании журнала, но
- почему не могут потеряться изменения в журнале транзакций??? если потеряна даже та информация, которая должна была быть сохранена раньше , чем журнал? У тебя просто какой-то неубиваемый транзакшнлог получается.

Разумеется, если уж такая ситуация возникнет (данные куда-то делись, а лог остался) - то у SQL-сервера имеется преимущество, он сделает Rollforward. Аксес - не сделает, у него журнал транзакций (вернее некое его подобие) вместе с файлом данных хранится, потеря данных автоматом означает и потерю журнала. Что, конечно же, есть уродство.


Возращаясь к dbFlashOSCacheWrites
Access97 HelpВ рабочей области Microsoft Jet пользователь имеет возможность задать в методе CommitTrans константу dbFlushOSCacheWrites, Это приводит к принудительной записи на диск всех обновлений вместо их помещения во временный буфер. Без этого параметра пользователь может перехватить управление сразу после вызова метода CommitTrans программой приложения, выключить компьютер, и отказаться от записи данных на диск. Хотя включение данного параметра может сказаться на быстродействии приложения, это оказывается полезным в ситуациях, когда возможно отключение компьютера до сохранения на диске кэшированных изменений
IgorMНе спорю, jet чужими кэшами не рулит, но хелп четко определят, что этот параметр используется для управления своим буфером (транзакций).
Такое ощущение, что мы смотрим в одну и ту же книгу, но видим совершенно разные фиги. В цитате из хелпа я не вижу ни одного упоминания о каком-то своем , аксесовском буфере (транзакций). "Временный буфер" - может относится как к чему-то встроенному-аксесовскому, так и к чему-то внешнему-системному. Как ты думаешь, о чем может говорить само название параметра: dbFlash OSCache Writes? Неужто об аксесовском буфере?
IgorMСсылки есть, что этот параметр никакой роли не играет?
Ссылок нет. Есть только экспериментальные проверки.
У меня складывается впечатление, что этот параметр вообще нигде и никем не используется :)
Характерно, что он в хелпе даже называется неправильно, не так, как в библиотеке. По крайней мере в DAO 2.5/3.5 Compatibility, DAO 3.51 и DAO 3.6 перечисление CommitTransOptionsEnum содержит только dbForceOSFlush (заметь, опять dbForce OS Flush)
Ссылки есть, что этот параметр используется и работает?
...
Рейтинг: 0 / 0
Поругайте Акцесс. Очень надо.
    #32387476
Yo!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Yo!
Гость
в оракле:
1. на коммит сервер минуя кэш файловой системы записывает в лог транзакций (undo).
2. логов транзакций как минимум 2 и всегда на разных дисках.
...
Рейтинг: 0 / 0
Поругайте Акцесс. Очень надо.
    #32387620
IgorM
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ЛПНе знаю как аксесе реализован лог транзакций (хотя бы потому что его там в явном виде нет :))

F1 - BeginTrans, CommitTrans, Rollback Methods- "In a Microsoft Jet workspace, transactions are logged in a file kept in the directory specified by the TEMP environment variable on the workstation."

ЛПСтоп. Не знаю как аксесе реализован лог транзакций (хотя бы потому что его там в явном виде нет :)), но, по-моему, сначала должны записываться измененные данные, а уже потом в логе должна фиксироваться информация о завершенной транзакции. По крайней мере это было бы логично.


Не менее логично предположить две фазы: фиксация в логе, перенос из лога в БД и фиксация изменений.

авторРазумеется, если уж такая ситуация возникнет (данные куда-то делись, а лог остался) - то у SQL-сервера имеется преимущество, он сделает Rollforward. Аксес - не сделает, у него журнал транзакций (вернее некое его подобие) вместе с файлом данных хранится, потеря данных автоматом означает и потерю журнала. Что, конечно же, есть уродство.

Об этом я речь все время и веду, т.к. по докам это и есть отсутствие гарантии Durable в транзакциях Access.

ЛП"Временный буфер" - может относится как к чему-то встроенному-аксесовскому, так и к чему-то внешнему-системному. Как ты думаешь, о чем может говорить само название параметра: dbFlashOSCacheWrites? Неужто об аксесовском буфере?

Здесь похоже ты прав - KB165829 (кстати, это статья о том, что этот параметр в Acc97 перименован): "The dbForceOSFlush constant only works if your database resides on a Microsoft Windows 95 or Windows NT computer. If the database file resides on another type of server, such as Novell Netware or Banyan Vines, dbForceOSFlush does not correctly command the operating system to flush all updates to disk."

ЛПСсылки есть, что этот параметр используется и работает?

MSDN пойдет? Как минимум:
http://support.microsoft.com/default.aspx?scid=kb;EN-US;180223
http://support.microsoft.com/default.aspx?scid=kb;EN-US;191253

Ну, и еще в буржуйских форумах натыкался на упоминания, что помогло, но справедливости ради видел и слова о том, что в сетевой версии кому-то наоброт не помогло.

Я думаю, пора заканчивать, т.к. я уже как-то не улавливаю, что ты мне хочешь доказать. Что касается меня, то я согласен с MS по этому вопросу: "File-server databases, such as the Jet database engine, can't guarantee durable transactions " и "If you require true transaction support with respect to durability, you should investigate the use of a client/server database engine such as SQL Server or the Microsoft Data Engine (MSDE)."
...
Рейтинг: 0 / 0
Поругайте Акцесс. Очень надо.
    #32387916
SSY
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
IMHO, самый убойный аргумент против Аксесса - безопасность. Любой может просто взять (скопировать себе куда захочет) файл БД, крякнуть его (средства имеются) и получить абсолютно все данные системы. Получить полный доступ к рабочей базе также, разумеется, не является проблемой.
Практически любую защиту интерфейсной части, написанной на аксессе, также можно относительно легко сломать.

Я понимаю, что FireBird + exe на дельфи тоже не без греха, но это всё равно уже другой уровень.

С уважением, Сергей Смирнов.
...
Рейтинг: 0 / 0
Поругайте Акцесс. Очень надо.
    #32388031
Фотография fedd
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
> Я понимаю, что FireBird + exe на дельфи тоже не без греха, но это всё равно уже другой уровень.

с тем же грехом, только копировать надо не mdb а gdb :)
...
Рейтинг: 0 / 0
Поругайте Акцесс. Очень надо.
    #32388077
alex_k
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
нет, без гнего(греха) :-)
в fb у клиента нет физического доступа к файлу на сервере, а если есть, то админ - му дак.

а в аксесе, насколько я понимаю, у клиента есть физический доступ к файлу, посредством сетевой файловой системы винды.
поправьте, если не прав.
...
Рейтинг: 0 / 0
Поругайте Акцесс. Очень надо.
    #32388089
Фотография Лох Позорный
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 IgorM
F1 - BeginTrans, CommitTrans, Rollback Methods- "In a Microsoft Jet workspace, transactions are logged in a file kept in the directory specified by the TEMP environment variable on the workstation."
Блин, позор на мою седую голову, не смог хелп до конца страницы пролистать :)
Всегда был в непонятках - на кой ляд аксесу нужна директория TEMP. Ну вот теперь знаю, сенькс за посыл в хелп.
Очень мне понравились следующие два предложения:
Access HelpIf the transaction log file exhausts the available storage on your TEMP drive, the database engine triggers a run-time error. At this point, if you use CommitTrans, an indeterminate number of operations are committed, but the remaining uncompleted operations are lost , and the operation has to be restarted.
Вот тут уж я даже не знаю что и сказать... Это вам не мифический rollforward на основе бессмертного лога... Жопа какая-то...

2 alex_k
а в аксесе, насколько я понимаю, у клиента есть физический доступ к файлу, посредством сетевой файловой системы винды.
Истинная правда. Есть доступ. Нормальную защиту на аксесе не построишь.
Есть, конечно, встроенные в аксес механизмы защиты данных, но они способны защитить только от тех, кто не догадается в каком-нить гугле набрать "взлом защиты аксеса"
...
Рейтинг: 0 / 0
Поругайте Акцесс. Очень надо.
    #32388092
Фотография Gluk (Kazan)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 ЛП

Вы таки будете смеятся, но в Oracle на диск сперва пишутся именно логи (как правило в железное или софтварное зеркало). И не undo как эдесь ошибочно было сказано, а самые что ни на есть redo (в Oracle это очень различные понятия). Все эти (и многие другие ухищрения) с целью добиться ACID при максимально возможной производительности.
...
Рейтинг: 0 / 0
Поругайте Акцесс. Очень надо.
    #32388137
Фотография Лох Позорный
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 Gluk (Kazan)
Вы таки будете смеятся, но в Oracle на диск сперва пишутся именно логи (как правило в железное или софтварное зеркало). И не undo как эдесь ошибочно было сказано, а самые что ни на есть redo (в Oracle это очень различные понятия).
Не, не буду смеятся. В умных книжках по ораклу оно так и написано
Только помнится мне, что там сохраняются как undo-, так и redo-запросы ?
Про до и после - я имел ввиду фиксацию транзакции, а не undo/redo логи. Или в оракле сначала флаги фиксации ставятся, а уже потом данные меняются? Странно если так.
Если не прав - поправьте.

З.Ы. Какой урод додумался транзакшнлог в директории TEMP хранить... Самое надежное место блин... Сижу и офигеваю... indeterminate number of operations are committed блин...
...
Рейтинг: 0 / 0
Поругайте Акцесс. Очень надо.
    #32388233
IgorM
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ЛПКакой урод додумался транзакшнлог в директории TEMP хранить... Самое надежное место блин... Сижу и офигеваю... indeterminate number of operations are committed блин...

А какая разница, где его хранить на локальной машине?
...
Рейтинг: 0 / 0
Поругайте Акцесс. Очень надо.
    #32388246
Фотография fedd
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
> в fb у клиента нет физического доступа к файлу на сервере, а если есть, то админ - дурачок.

ну админ может еще быть не мудаком, а просто сволочью. захочет стырить мою секретную базу, на которой я Матрицу написал...
...
Рейтинг: 0 / 0
Поругайте Акцесс. Очень надо.
    #32388282
*
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
*
Гость
>Это только с переводом аксеса 2.0 на 97-й были серьезные проблемы. Но когда это было?

Не только. 97->2000 тоже не без проблем, хотя они и не столь велики, как в первом случае. А вот переход 2.0->97 должен войти в историю как переход от разумного к нераумному
...
Рейтинг: 0 / 0
Поругайте Акцесс. Очень надо.
    #32388304
Фотография Лох Позорный
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 IgorM
А какая разница, где его хранить на локальной машине?
Да никакой в общем-то. Разве что со свободным местом могут быть проблемы. Не всем очевидно, почему это база пишет "недостаточно свободного места", в то время как на диске (в том разделе где база) куча гигов свободных.

2 *
А вот переход 2.0->97 должен войти в историю как переход от разумного к нераумному
У тебя такое хорошее мнение о 2.0 или такое плохое о 97-м?
...
Рейтинг: 0 / 0
Поругайте Акцесс. Очень надо.
    #32388384
*
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
*
Гость
>У тебя такое хорошее мнение о 2.0 или такое плохое о 97-м?
Глюки были и там и там, но хуже всего то, что в 97-м (или 95-м) изменили правила проверки ссылок
...
Рейтинг: 0 / 0
Поругайте Акцесс. Очень надо.
    #32388389
Фотография Лох Позорный
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
хуже всего то, что в 97-м (или 95-м) изменили правила проверки ссылок
Что имеется в виду? Ссылок на что?
...
Рейтинг: 0 / 0
Поругайте Акцесс. Очень надо.
    #32388398
*
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
*
Гость
Выходит, я непонятно выразился.
Ссылка - это foreign key
...
Рейтинг: 0 / 0
Поругайте Акцесс. Очень надо.
    #32388426
Фотография Лох Позорный
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Тогда я все равно не понял. Что-то изменилось в foreign key'ях в 97-м по сравнению с 2-ым? Хм... вроде как было "связь с обеспечением целостности данных", так и осталось...
Что ты под "правилами проверки" подразумеваешь? И как их изменили?
...
Рейтинг: 0 / 0
Поругайте Акцесс. Очень надо.
    #32388469
c127
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
2 Лох Позорный

>Но просвети меня, о великая буквацифра, если DAO - не СУБД, то, наверное, приведенный вторым котом кусочек SQL-скрипта - тоже не СУБД? И ведь тогда выходит, что некий MS SQL, использующий этот самый SQL - тоже не СУБД? И пусть в SQL есть слова "begin transaction" и "commit transaction" - но самих то транзакций в MS SQL, получается, нет?

>Че делать, мужики?

Логику учить. Опять все поперепутывал.


IgorM

>Можно вопрос: а чем является Jet, транзакции реализованы там

Не знаю я чем является Jet, я это понятие впервые увидел в этой ветке. Подозреваю что Jet есть подобие сервера БД в исполнении акцеса, то что раньше называлось engine.

>(ЛП в пылу дискуссии про DAO не к месту вспомнил)?

Возможно, но я ориентируюсь только на текущее обсуждение ибо акцеса не знаю и не стремлюсь. Cat2 сказал:"Открыл его хелп, запустил поиск по слову "транзакция". Ничего вразумительного не нашел.". Лох Позорный: "Cat2, прости великодушно, но ты тоже "ни ухом ни рылом" :) В DAO-шном синтаксисе....". Так что либо Cat2 невнимателен, либо Лох Позорный, но по-моему, из общих соображений, Cat2 ближе к истине.
...
Рейтинг: 0 / 0
Поругайте Акцесс. Очень надо.
    #32388531
Фотография Gluk (Kazan)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 ЛП

Суть достаточно прозрачна. REDO (в Oracle) используются исключительно для наката транзакций при различных форс-мажорах и не для чего больше, поэтому запись в них осуществляется строго последовательно, никакой конкуренции и максимальная производительность. Транзакция считается состоявшейся, когда в REDO (по commit) записывается информация о том, что она завершена (потом неспеша пишутся грязные блоки базы данных из кэша в дисковую память произвольного доступа). Если чего-то упадет, эти блоки можно восстановить по текущим REDO-логам. При переключении журналов, остатки грязных блоков сбрасываются на диск принудительно и отработанный журнал начинает архивироваться (единственным и очень слабым оправданием отключения archivelog является нехватка места на диске). По архивным логам можно восстановить состояние базы на любой момент времени (начав с последней полной (горячей или холодной) копии). Также можно восстанавливать по отдельности файлы данных и табличные пространства.
Не совсем понял, что есть флаг фиксации, но НА ДИСК данные о фиксации транзакции в общем случае пишутся раньше чем сами данные (разумеется еще раньше данные изменяются в кэше). В общем не суть важно, что хранится в REDO, важно, что они применяются только для наката. Впрочем есть LOGMINER, позволяющий просматривать их содержимое в форме SQL запросов.
UNDO храняться в сегментах отката и используются для rollback и обеспечения версионности. Они храняться в самых обычных табличных пространствах, защищенных REDO-логами. Это очень важно, поскольку при сбое сначала вся база (вместе с UNDO) накатывается по текущим REDO-логам, а затем выполняется обычный откат всех незавершенных транзакций.
Надеюсь, что я ответил на Ваш вопрос и ничего не перепутал.
...
Рейтинг: 0 / 0
Поругайте Акцесс. Очень надо.
    #32388545
Фотография Senin Viktor
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Классно! Акес сравнивают уже с Ораклом и MS SQL :)
ЛП пора переходить на работу в отдел маркетинга микрософт
...
Рейтинг: 0 / 0
Поругайте Акцесс. Очень надо.
    #32388573
Фотография Лох Позорный
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 Глюк
Большое спасибо. Очень доступно и понятно.

2 Сенин Виктор
Да это вообще отличный топик получился! Сначала меня ИгорьМ носом в хелп ткнул так, что я соплями до сих пор утираюсь, потом про оракл рассказали, в промежутках буквацифра шедевры выдает (engine, блин, это звучит гордо... engine от паровоза). Еще бы Звездочка с неба упала и рассказала, что же такого со связями в 97-м аксесе сделали - я бы вообще умер счастливым.
...
Рейтинг: 0 / 0
Поругайте Акцесс. Очень надо.
    #32389257
*
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
*
Гость
>Тогда я все равно не понял. Что-то изменилось в foreign key'ях в 97-м по сравнению с 2-ым? Хм... вроде как было "связь с обеспечением целостности данных", так и осталось...
Что ты под "правилами проверки" подразумеваешь? И как их изменили?

Было (2.0): FK проверяется если заполнены все его поля
Стало (97): FK проверяется если заполнено хотя бы одно его поле
И в ORACLE и в MSSQL(!) реализован первый вариант.

Проблема возникает когда есть два частично пересекающихся (включающих одни и те же поля) не обязательно заполняемых FK.
...
Рейтинг: 0 / 0
Поругайте Акцесс. Очень надо.
    #32389362
Фотография Лох Позорный
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Теперь понял. Я с этим тоже сталкивался, но не знал, что во 2-м аксесе оно было реализовано по другому.
...
Рейтинг: 0 / 0
Поругайте Акцесс. Очень надо.
    #32389917
c127
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
2 Лох Позорный
>(engine, блин, это звучит гордо... engine от паровоза)

А Jet от самолета. Большая разница. Только термин engine (двигатель, любой, совсем не обязательно от паравоза) гораздо лучше отражает ситуацию, чем jet (реактивный двигатель, реактивный самолет, реактивный).

Если вдруг кто-то не знает: engine - стандартное название, использовалось еще в восьмидесятых например в парадоксе (Borland Paradox), наверняка в других продуктах было еще раньше, и всех это устраивало. Мелкософт как обычно взял старое, назвал другим словом и выдает за новое.
...
Рейтинг: 0 / 0
Поругайте Акцесс. Очень надо.
    #32390084
Фотография Лох Позорный
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Буквацифра, ты не перестаешь радовать людей.
Мы уже узнали, что MySQL это не SQL-сервер и даже не РСУБД, мы узнали, что DAO - это тоже не СУБД, а теперь ты открыл нам страшную тайну:
Оказывается, что майкрософт (который, видимо, правильнее называть мелкософт), нагло сп..дил чужую разработку! Двигатель от паровоза, изначально придуманный сэром Борландом Парадоксом, теперь продается под видом двигателя от самолета!
З.Ы. Тебя же просили - проходите, товарисч, дальше, не мешайте людям аксес ругать.

цирк уродов :)
где таких берут... на грядке выращивают что-ли...
...
Рейтинг: 0 / 0
Поругайте Акцесс. Очень надо.
    #32390494
f_w_p
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Access, БД 1,5 гб. Более менее крутиться, подключено 30 юзеров. Сетка не такая уж толстая. А все потому, что на сервере стоит Terminal Service. Проблем не мало у народа, который все это сделал - например Access любит падать после переползания БД за 2 гига, индексы частенько куда то улетают, админы по ночам ночуют. Terminal Service любит гадости еще подкидывать, особенно касательно печати. :)
Я как раз вот такой осчастливленный ACCESS~ом админ. И тоже проблемы с печатью в терминал-сессиях. Не мог бы рассказать какие проблемы у вас и как вы их решаете.
...
Рейтинг: 0 / 0
Поругайте Акцесс. Очень надо.
    #32391495
*
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
*
Гость
Забыл одну вещь:
create table T1(A Text(10), B Text(10));
create table T2(A Text(10), B Text(10));
Если в T1 определить UK(A,B), а в T2 FK (A,B), ссылающийся на T1 (A,B) и в
T1 ввести ДВЕ строки ("1",NULL), то на эти ("1",NULL) можно будет сослаться из T2. Вот как. Вопрос в том, на какую из них ссылаемя?
...
Рейтинг: 0 / 0
Поругайте Акцесс. Очень надо.
    #32391683
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
авторИ тоже проблемы с печатью в терминал-сессиях. Не мог бы рассказать какие проблемы у вас и как вы их решаете.
Ничего к сожалению подсказать не могу, я в данном случае на все это просто смотрю со стороны. Попробую напрячь админов, чтобы они поактивнее принимали участие на форумах sql.ru, в разделах Access и Windows. Опыт у них по прокручивании Access в терминалке не маленький.
...
Рейтинг: 0 / 0
Поругайте Акцесс. Очень надо.
    #32391727
c127
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
2 Лох Позорный

>Буквацифра, ты не перестаешь радовать людей.
Мы уже узнали, что MySQL это не SQL-сервер и даже не РСУБД, мы узнали, что DAO - это тоже не СУБД, а теперь ты открыл нам страшную тайну:
Оказывается, что майкрософт (который, видимо, правильнее называть мелкософт), нагло сп..дил чужую разработку! Двигатель от паровоза, изначально придуманный сэром Борландом Парадоксом, теперь продается под видом двигателя от самолета!
З.Ы. Тебя же просили - проходите, товарисч, дальше, не мешайте людям аксес ругать.

>цирк уродов :)
>где таких берут... на грядке выращивают что-ли...

А что это ты так разнервничался? Cпокойнее, Маня, Вы же не на работе. Ты несешь такую очевидную чушь, что я готов бы поверить, что ты действительно придуриваешься в угоду публике, но эту картину явно нарушает бурная реакция на критику. Так что по-видимому ты веришь в то, что говоришь.

Поэтому объясняю по-порядку, может еще не все потеряно.

* мелкософт конечно же не крал борландовскую разработку, он просто назвал свой старый engine новым словом Jet.

* DAO ты вообще приплел ни к селу ни к городу, о чем тебе сказал IgorM: "ЛП в пылу дискуссии про DAO не к месту вспомнил". DAO не является частью СУБД поскольку к акцесу можно коннектится из дельфей через ОДБЦ не используя DAO, а можно используя DAO коннектится к ораклу из VB через тот же ОДБЦ. Учи матчасть.

* MySQL не СУБД вообще и не РСУБД в частности в смысле Кодда по той простой причине, что не подерживает транзакции. По Кодду есть восемь требований к СУБД, тразакции идут под номером 3 (Codd E.F., "Relational Database: A Practical Foundation for Productivity", Communications of the ACM 25, no.2). Так что если тебе что-нибудь не нравится - все претензии туда.

Успехов.
...
Рейтинг: 0 / 0
Поругайте Акцесс. Очень надо.
    #32391750
Фотография Senin Viktor
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 Звезде
>T1 ввести ДВЕ строки ("1",NULL), то на эти ("1",NULL) можно будет сослаться из T2. Вот как. Вопрос в том, на какую из них ссылаемя?

Твоя проблема легко решалась бы вводом искуственного уникального ключа и построении связи по нему, а не по хрен знает чему. И вообще такая таблица в связке SQL+Access будет не редактируема - ибо отсуствует уникальный ключ.
И вообще Null<>Null - меня так еще в школе учили :)
...
Рейтинг: 0 / 0
Поругайте Акцесс. Очень надо.
    #32392231
IgorM
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
c127* DAO ты вообще приплел ни к селу ни к городу, о чем тебе сказал IgorM: "ЛП в пылу дискуссии про DAO не к месту вспомнил".

Там все к месту было, перечитай внимательнее. Я был не прав.

А почему правил Кодда всего 8? Я читал 12:

http://www.frick-cpa.com/ss7/Theory_RelationalDB.asp

И серьезных противоречий с ними Access имхо не имеет.
...
Рейтинг: 0 / 0
Поругайте Акцесс. Очень надо.
    #32392391
*
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
*
Гость
>Твоя проблема легко решалась бы вводом искуственного уникального ключа и построении связи по нему, а не по хрен знает чему. И вообще такая таблица в связке SQL+Access будет не редактируема - ибо отсуствует уникальный ключ.
И вообще Null<>Null - меня так еще в школе учили :)

Пример, который я привел - искусственный, но он демонстрирует неразумность принятого в Access 97 правила проверки FK

А говорю я это потому, что имел проблемы с переносом приложения, в котором ряд проверок данных был построен на частично пересекающихся внешних ключах. После переноса таблицы действително стали нередактируемыми, но вовсе не из-за отсутствия PK
...
Рейтинг: 0 / 0
Поругайте Акцесс. Очень надо.
    #32392397
*
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
*
Гость
И еще маленькое дополнение. Не во всех системах PK необходим для редактирования. Таблица ORACLE, например, редактируется и при отсутствии PK (например, в ней нет PK, но есть пара UK)
...
Рейтинг: 0 / 0
Поругайте Акцесс. Очень надо.
    #32392409
aPT
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
*И еще маленькое дополнение. Не во всех системах PK необходим для редактирования. Таблица ORACLE, например, редактируется и при отсутствии PK (например, в ней нет PK, но есть пара UK)
Он как-бы даже и не нужен. Главное чтобы не было 2-х полностью одинаковых записей. У меня например в базе нет ни PK ни FK в чистом виде. Есть некие условные составные ключи, не обьявленные в базе как ключи.
...
Рейтинг: 0 / 0
Поругайте Акцесс. Очень надо.
    #32392488
funikovyuri
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
У меня например в базе нет ни PK ни FK в чистом виде.

Извините конечно, но ПРОСТО ЗАШИБИСЬ!
...
Рейтинг: 0 / 0
Поругайте Акцесс. Очень надо.
    #32392554
Читатель
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
У меня например в базе нет ни PK ни FK в чистом виде. Есть некие условные составные ключи, не обьявленные в базе как ключи.

К сожалению довольно распространеная ситуация.
Иногда даже понятно как она сложилась исторически.
Но всеравно руки разработчику оторвать хочется !
...
Рейтинг: 0 / 0
Поругайте Акцесс. Очень надо.
    #32392564
Фотография Senin Viktor
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 *
Не во всех системах PK необходим для редактирования. Таблица ORACLE, например, редактируется и при отсутствии PK (например, в ней нет PK, но есть пара UK)

Акес тоже позволяет редактировать данные без PK и вообще без каких-либо индексов.
Получаеться Акес круче Оракла ?

Пример, который я привел - искусственный, но он демонстрирует неразумность принятого в Access 97 правила проверки FK

"Неразумность" Акеса слихвой компенсируеться разумностью разработчика.
...
Рейтинг: 0 / 0
Поругайте Акцесс. Очень надо.
    #32392596
aPT
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Хе-хе. Меряться генераторами будем?
Для чего нужны ключи на практике?
PK:
1 - обеспечение уникальности каждой записи. Псевдоключи в моей базе имеют все признаки уникальности: 2 поля отвечают за уникальность базы на планете Земля (есть сложная система репликации и они указывают на источник записи) и 1 поле формируется генератором. Неуникальной данная связка быть не может.
2 - для обновления таблицы. Таблицы как объект типа *Table не использую вообще. Использую запросы к хранимым процедурам и для рефреша (какой нахиг рефреш, когда навигаторов всего 3 на 60 форм) нужные *UpdateSQL. Кстати редактирование в сетке почти не использую. Не нужно.

FK:
1 - Связи между таблицами. Ну понимаешь через SQL и хранимые процедуры можно такое навернуть, что никакому любителю Paradox не снилось.
2 - Запрет на удаление подчиненной записи. Ну перед удалением идет строгая проверка на правильность такого решения как клиентом, так и серверной логикой и в случае принятия узером такого решения она не удаляется, а помечается удаленной. Удалять можно лет через 5 после отметки как удаленной только после помещения записи и подчиненных ей в долгосрочный архив. Да и триггеры ставят надежный заслон в крайнем случае. Все-таки 350 кило серверной логики уже накатал.
3 - каскадные действия по отношению к подчиненной таблице. А триггеры для чего? В носу ковырять?

Ну убедите меня что я не прав. Вот только аргументы не забудьте. Не люблю пустые споры.
...
Рейтинг: 0 / 0
Поругайте Акцесс. Очень надо.
    #32392608
funikovyuri
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
aPT

Псевдоключи в моей базе имеют все признаки уникальности

Так чего там у вас нет - ключей или constraint'ов?
...
Рейтинг: 0 / 0
Поругайте Акцесс. Очень надо.
    #32392611
aPT
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
У меня нет PK,FK и constraint'ов.
...
Рейтинг: 0 / 0
Поругайте Акцесс. Очень надо.
    #32392612
funikovyuri
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Это означает что вы отказались от DRI а не от ключей - ключи это группа(1..*) полей отвечающих за уникальность записи
...
Рейтинг: 0 / 0
Поругайте Акцесс. Очень надо.
    #32392684
*
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
*
Гость
>"Неразумность" Акеса слихвой компенсируеться разумностью разработчика.

К сожалению нет. Ибо способностью предвидеть будущее обладают немногие...
...
Рейтинг: 0 / 0
Поругайте Акцесс. Очень надо.
    #32393005
c127
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
2 IgorM

>Там все к месту было, перечитай внимательнее. Я был не прав.

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

> А почему правил Кодда всего 8? Я читал 12:

Посмотрел по ссылке. Мы говорим о немного разных вещах: в цитируемой статье приводятся не правила, а возможности или сервисы, которыми с необходимостью должна обладать СУБД (не обязательно реляционная). В статье их 8:
1) data storage, retrirval and update
2) a user-accessable catalog
3) transatction support
4) concurrency control services
5) recovery services
6) autorization services
7) support for data communaications
8) integrity services

>И серьезных противоречий с ними Access имхо не имеет.

Просто не удовлетворяет некоторым и все, это не всегда противоречие. Например в полной мере не поддерживает транзакции: Transactions are not supported for linked tables. Сразу говорю, я не знаю, что это значит, это цитата из хелпа по TRANSACTION Statement.

Но вообще-то мы говорили о MySQL, там транзакций нет вообще никаких.
...
Рейтинг: 0 / 0
Поругайте Акцесс. Очень надо.
    #32393463
IgorM
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
с127DAO не входит в систему акцесовской обработки данных, поэтому приводить DAO-шный синтаксис в качестве доказательства было некорректно, поскольку транзакции в принципе могут быть реализованы не в самом акцесе а в системе DAO-акцес. А если коннектится через ODBC, транзакции пропадут или нет?

Что значит в "самом Access"? Access - это клиент, data access systems в терминах MS, просто максимально интегрированный с Microsoft Jet database engine. По умолчанию, MSA'97 использует DAO для доступа к базам mdb, в которых MS Jet поддерживает транзакции, поэтому пример в "синтаксисе" DAO вполне оправдан. А если коннектится через ODBC поддержка транзакций будет зависеть от подключаемой БД и драйвера ODBC.

с127в цитируемой статье приводятся не правила, а возможности или сервисы, которыми с необходимостью должна обладать СУБД (не обязательно реляционная).

Later Dr. Codd clarified his model by defining twelve rules (Codd’s Rules) that a database management system (DBMS) must meet in order to be considered a relational database .

In practice, many database products are considered 'relational' even if they do not strictly adhere to all 12 rules

Идеал обычно редко достижим.

c127Transactions are not supported for linked tables

linked tables могут быть, например, текстовыми файлами, для них действительно транзакции не поддерживаются, если же внешняя таблица будет из другого mdb, то транзакции могут использоваться.

А что касается MySQL, то цитату из предыдущей ссылки я уже приводил: "In practice..." и т.д.
...
Рейтинг: 0 / 0
Поругайте Акцесс. Очень надо.
    #32394595
c127
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
2 IgorM

>По умолчанию, MSA'97 использует DAO для доступа к базам mdb, в которых MS Jet поддерживает транзакции, ... .

А если я из акцесса буду коннектится к mdb файлам через ODBC (если вдруг такое возможно), то будут ли поддерживаться транзакции? Будет ли задействован MS Jet в этом случае?

>А если коннектится через ODBC поддержка транзакций будет зависеть от подключаемой БД и драйвера ODBC.

Дельфи умеет разговаривать через одбц с кем угодно. Будет ли дельфи поддерживать транзакции в mdb файлах? Будет ли задействован MS Jet в этом случае?

>Later Dr. Codd clarified his model by defining twelve rules (Codd’s Rules) that a database management system (DBMS) must meet in order to be considered a relational database.

In practice, many database products are considered 'relational' even if they do not strictly adhere to all 12 rules

1) Есть определение Кодда, есть его толкования. Предлагаю толкования пока не обсуждать.

2) В моей ссылке речь идет о СУБД, в твоей - о РСУБД, которые есть подмножеством первых. Это одна из причин непонимания.

>linked tables могут быть, например, текстовыми файлами, для них действительно транзакции не поддерживаются, ...

Раз транзакции не поддерживаются, то это не СУБД в смысле Кодда. У него для внешних файлов исключений не предусмотрено: транзакции либо есть либо их нет. Если вдруг оракл или ДБ2 не поддерживает транзакции с внешними файлами, то это тоже не СУБД в смысле Кодда. Или же поддержкой внешних файлов никогда не нужно пользоваться.
...
Рейтинг: 0 / 0
Поругайте Акцесс. Очень надо.
    #32394653
IgorM
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
c127А если я из акцесса буду коннектится к mdb файлам через ODBC (если вдруг такое возможно), то будут ли поддерживаться транзакции? Будет ли задействован MS Jet в этом случае?

Возможно, почему нет...
1. Да.
2. Может быть задействован, а может не быть (я имею ввиду до ODBC драйвера).

с127Дельфи умеет разговаривать через одбц с кем угодно. Будет ли дельфи поддерживать транзакции в mdb файлах? Будет ли задействован MS Jet в этом случае?

1. У меня дельфи нет, BC++Builder против StartTransaction, Commit или Rollback, при ODBC-подключения к mdb, не возражает и они отрабатывают как надо.
2. Честно говоря, точно не знаю, как ODBC-драйвер взаимодействует с mdb, но очень вероятно, что посредством MS Jet Engine (во всяком случае, ссылки на него в odbcjt32.dll присутствуют).

По теории (Р)СУБД спорить не буду, меня не очень беспокоит вопрос полного соответствия каких-либо конкретных БД правилам Кодда.
...
Рейтинг: 0 / 0
Поругайте Акцесс. Очень надо.
    #32395279
*
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
*
Гость
Есть подозрение, что при соединении с mdb-базой через ODBC индексы игнорируются
...
Рейтинг: 0 / 0
Поругайте Акцесс. Очень надо.
    #32395304
Фотография Лох Позорный
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Есть подозрение, что при соединении с mdb-базой через ODBC индексы игнорируются
Смотря откуда
В связке "Jet + ODBC + какой-нить сервер" с индексами точно беда, по крайней мере рашмор для них не будет использоваться. Но это из-за уродской связки "Jet+ODBC". При использовании ODBCDirect все работает как и должно.

З.Ы. А как вы себе представляете коннект из mdb в mdb через ODBC? Сам аксес ведь не даст так прилинковаться. Не из аксеса - можно, и помоему индексы не протераются.
...
Рейтинг: 0 / 0
Поругайте Акцесс. Очень надо.
    #32395493
IgorM
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ЛПА как вы себе представляете коннект из mdb в mdb через ODBC? Сам аксес ведь не даст так прилинковаться.

Без линковки, программно через CreateWorkspace, OpenConnection и соответствующий DSN.
...
Рейтинг: 0 / 0
Поругайте Акцесс. Очень надо.
    #32395508
*
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
*
Гость
>З.Ы. А как вы себе представляете коннект из mdb в mdb через ODBC? Сам аксес ведь не даст так прилинковаться. Не из аксеса - можно, и помоему индексы не протераются.

И Access и VB - нет, клиент был написан на C скорость заметно падала уже на сотнях записей.
...
Рейтинг: 0 / 0
Поругайте Акцесс. Очень надо.
    #32396021
c127
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
2 IgorM

>2. Честно говоря, точно не знаю, как ODBC-драйвер взаимодействует с mdb, но очень вероятно, что посредством MS Jet Engine (во всяком случае, ссылки на него в odbcjt32.dll присутствуют).

Получается что MS Jet Engine выполняет роль сервера. А DAO в этом участвует?

Если DAO живет в odbcjt32.dll, то я согласен, его наверное нужно считать частью MS Jet Engine.

>По теории (Р)СУБД спорить не буду, меня не очень беспокоит вопрос полного соответствия каких-либо конкретных БД правилам Кодда.

Дело в том что MySQL вообще никак не соответсвует, разве что в последней версии ввели транзакции. Но вроде бы еще нет.
...
Рейтинг: 0 / 0
Поругайте Акцесс. Очень надо.
    #32396176
Фотография Лох Позорный
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
IgorMЧестно говоря, точно не знаю, как ODBC-драйвер взаимодействует с mdb, но очень вероятно, что посредством MS Jet Engine
Даже очень вероятно. Без установленного Jet'а с mdb вроде как не получится работать - ни через ODBC, ни через OLEDB, ни с использованием ADO, ни с использованием DAO

2 с127
Получается что MS Jet Engine выполняет роль сервера. А DAO в этом участвует?
Не участвует.
Если DAO живет в odbcjt32.dll, то я согласен, его наверное нужно считать частью MS Jet Engine.
Не живет.

Ты все еще не можешь отойти от примера, который я для Cat2 привел? Сочувствую.

Дело в том что MySQL вообще никак не соответсвует, разве что в последней версии ввели транзакции. Но вроде бы еще нет.
В самом MySQL вроде как ввели. А уж тем более в его клонах.
...
Рейтинг: 0 / 0
Поругайте Акцесс. Очень надо.
    #32396207
IgorM
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
c127Получается что MS Jet Engine выполняет роль сервера. А DAO в этом участвует?

Access через DAO к jet'у и обращается. Точно так же можно обращаться через ADO.
...
Рейтинг: 0 / 0
Поругайте Акцесс. Очень надо.
    #32397361
c127
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
2 Лох Позорный

>В самом MySQL вроде как ввели.

Да, только что появились в версии 4 (это последняя релиз версия, пятого релиза еще нет). До последнего времени MySQL был знаменит тем, что транзакции не поддерживал.

>А уж тем более в его клонах.

А что такое клоны MySQL, ты его с интербейзом случайно не перепутал?

2 IgorM

>Access через DAO к jet'у и обращается. Точно так же можно обращаться через ADO.

Речь не об акцессе, с ним все понятно, а о взаимодействии ODBC и акцесовской БД (IgorM>Честно говоря, точно не знаю, как ODBC-драйвер взаимодействует с mdb, но очень вероятно, что посредством MS Jet Engine (во всяком случае, ссылки на него в odbcjt32.dll присутствуют). Но Лох Позорный уже ответил.

Благодарю за разьяснения, кое-какие вопросы прояснились.
...
Рейтинг: 0 / 0
Период между сообщениями больше года.
Поругайте Акцесс. Очень надо.
    #33725057
Nikolai_Aus
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Про transactions' option "dbFlushOSCache"
здесь есть ответ: http://support.microsoft.com/kb/q165829
В кратце: Нужно использовать 1 или dbForceOSFlush.
...
Рейтинг: 0 / 0
147 сообщений из 147, показаны все 6 страниц
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / Поругайте Акцесс. Очень надо.
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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