Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 [4] 5 6   вперед  Ctrl      все
 Re: Поругайте Акцесс. Очень надо.  [new]
c127
Guest
2 Лох Позорный

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

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

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

Если нет транзакций то это не значит, что нельзя уронить систему до неподъемного состояния. Как раз можно. А вот с транзакциями нельзя: если только диски целы система должна откатиться до состояния последнего завершенного комита. Это конечно в теории. На практике наверное не так красиво, хотя я не знаю ни одного случая гибели SQL БД или даже каких-то проблем с самовосстановлением SQL сервера.
23 янв 04, 07:35    [503813]     Ответить | Цитировать Сообщить модератору
 Re: Поругайте Акцесс. Очень надо.  [new]
f_w_p
Guest
А хрен его знает товарисч майор. Взять палку, выгнать всех из базы нафиг, и тупо сделать бекап путем копирования файлов с данными :)
Так вот тож!

Ну а у меня 100-150 человек база 300метров в центральном офисе. И тоже никто чугуниевых тормозов не наблюдает
Не верю. (С) Станиславский.
Не про 300М. Про 150 человек. Никакая сетка не потянет такую БД на ACCESS. М.б. у тебя клиент к MSSQL? Или сетка сплошь Гигабит?
23 янв 04, 08:09    [503835]     Ответить | Цитировать Сообщить модератору
 Re: Поругайте Акцесс. Очень надо.  [new]
IgorM
Member

Откуда: Тула - Москва, транзит
Сообщений: 633
ЛП
Какое накуй Durability если сервер crashes before??? Вы млять о чем? С Лукоморья приехали? Где дуб рухнул?


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

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


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

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


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

И вообще, речь не о том, что Access не поддерживает транзакции (я их использую и полезности не отрицаю), а что их реализация менее надежна, чем в серверных системах. Мне кажется это очевидно.
23 янв 04, 11:26    [504257]     Ответить | Цитировать Сообщить модератору
 Re: Поругайте Акцесс. Очень надо.  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
Access, БД 1,5 гб. Более менее крутиться, подключено 30 юзеров. Сетка не такая уж толстая. А все потому, что на сервере стоит Terminal Service. Проблем не мало у народа, который все это сделал - например Access любит падать после переползания БД за 2 гига, индексы частенько куда то улетают, админы по ночам ночуют. Terminal Service любит гадости еще подкидывать, особенно касательно печати. Но в принципе как ни странно, все работает. Причем я бы не сказал, что дюже медленно. Вот так вот :)
23 янв 04, 12:04    [504360]     Ответить | Цитировать Сообщить модератору
 Re: Поругайте Акцесс. Очень надо.  [new]
IgorM
Member

Откуда: Тула - Москва, транзит
Сообщений: 633
Ну, для терминала сетка некритична, а вот что база может быть больше 2ГБ, так это странно, если конечно верить спецификациям MS Access.
23 янв 04, 12:36    [504425]     Ответить | Цитировать Сообщить модератору
 Re: Поругайте Акцесс. Очень надо.  [new]
Лох Позорный
Member

Откуда:
Сообщений: 9898
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 ("отсутствие транзакций в любой файл-серверной БД")
а что их реализация менее надежна, чем в серверных системах. Мне кажется это очевидно.
Разумеется очевидно. Аксес как хранилище - сам по себе менее надежен, нежели серверные системы. Есть транзакции, нет транзакций - по фигу, надежности аксесу это не прибавит.
Никто и не утверждал, что аксес есть надежнее серверных систем. На слова "аксес - ненадежен" остается лишь жидко обкакаться, поджать хвост и пойти прочь, бормоча под нос "... базе у них рухнула... ну бывает... сами виноваты... сетку не могли нормальную проложить... руки кривые..."
Но против отсутствия транзакций в файл-серверных БД буду сражаться до последнего. Когда погибну смертью храбрых - на смену мне придет мотострелковый взвод оловянных солдатиков.
23 янв 04, 16:20    [505033]     Ответить | Цитировать Сообщить модератору
 Re: Поругайте Акцесс. Очень надо.  [new]
IgorM
Member

Откуда: Тула - Москва, транзит
Сообщений: 633
ЛП
Не успела транзакция обновить данные, и что? Просто напросто незавершенная транзакция. Эти данные никуда не попадут, можно считать что их вообще не было никогда. Если транзакция закончилась - то она DURABLE (с точностью до повреждения хранилища данных), а если сервер рухнул до того, как транзакция закончилась - то Commit'а транзакции просто не случилось, бессмысленно спорить - DURABLE то, чего нет, или нет?


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

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


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

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


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

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


Ну, флаг после тебя будет кому поднять. Картинка с другого сайта.
23 янв 04, 17:37    [505197]     Ответить | Цитировать Сообщить модератору
 Re: Поругайте Акцесс. Очень надо.  [new]
Cat2
Member

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

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

Если во время "Изменение таблы2" произойдет сбой, то "Изменение таблы1" тоже откатится.
Может ли это Access? Сомневаюсь.
23 янв 04, 22:09    [505439]     Ответить | Цитировать Сообщить модератору
 Re: Поругайте Акцесс. Очень надо.  [new]
Лох Позорный
Member

Откуда:
Сообщений: 9898
2 Cat2
Может ли это Access? Сомневаюсь
Cat2, прости великодушно, но ты тоже "ни ухом ни рылом" :)
В DAO-шном синтаксисе
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 не имеет возможности управлять системным кешом, кешом сетевого редиректора и кешом жесткого диска. Что бы тебе там хелп не говорил. Проверялась работа (вернее неработа) этой опции неоднократно и не только мной.
  • 23 янв 04, 22:55    [505464]     Ответить | Цитировать Сообщить модератору
     Re: Поругайте Акцесс. Очень надо.  [new]
    Cat2
    Member

    Откуда: Petroskoi, Karjala
    Сообщений: 145754
    Лох Позорный - спасибо.
    24 янв 04, 00:01    [505493]     Ответить | Цитировать Сообщить модератору
     Re: Поругайте Акцесс. Очень надо.  [new]
    c127
    Guest
    2 Лох Позорный

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

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

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

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

    Так вот это в системе DAO - акцесс может быть некое подобие транзакций и реализовано, но вот беда: DAO не является акцессом и даже не является его частью. На всякий случай поясняю для лохов: DAO - data access object есть средство обмена данными между приложением и базой данных, вроде ODBC, и к самой СУБД отношения не имеет. Конечно же Лох Позорный и об этом знал, просто решил поприкалываться, а мы повелись.
    24 янв 04, 00:13    [505499]     Ответить | Цитировать Сообщить модератору
     Re: Поругайте Акцесс. Очень надо.  [new]
    Лох Позорный
    Member

    Откуда:
    Сообщений: 9898
    Здравствуй, буквацифра!
    Я тоже рад тебя видеть!
    Огромное спасибо тебе за то, что ты еще раз напомнил нам о том, что MySQL не является РСУБД. Надеюсь, что ты произнесешь это и в третий, и, если звезды будут к нам благосклонны, даже в четвертый раз.
    Однако ты так и не ответил - чем же является MySQL? Просвети нас, неграмотных, а то ведь так и будем знать только то, чем он не является.

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

    Че делать, мужики?
    24 янв 04, 01:05    [505523]     Ответить | Цитировать Сообщить модератору
     Re: Поругайте Акцесс. Очень надо.  [new]
    IgorM
    Member

    Откуда: Тула - Москва, транзит
    Сообщений: 633
    ЛП
    Кажется я начинаю понимать про что ты меня пытаешь лечить... Видимо ты имеешь в виду ситуацию, когда...

    Это не я, а тех. документация от MS. Аналогично с ситуацией, когда во время сетевой работы по обновлению данных отваливается клиент. Результат такого события для SQL-сервера и файл-серверной БД может быть различен.

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


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

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


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

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


    Не спорю, jet чужими кэшами не рулит, но хелп четко определят, что этот параметр используется для управления своим буфером (транзакций). Ссылки есть, что этот параметр никакой роли не играет?
    24 янв 04, 22:09    [505858]     Ответить | Цитировать Сообщить модератору
     Re: Поругайте Акцесс. Очень надо.  [new]
    IgorM
    Member

    Откуда: Тула - Москва, транзит
    Сообщений: 633
    c127
    Остальные наивняки после утверждения "транзакции в акцесе есть" кинулись по-привычке искать транзакции в самом акцессе и судя по всему не нашли.


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

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


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

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


    Вычеркивай из резюме слова "программист БД".
    24 янв 04, 22:47    [505871]     Ответить | Цитировать Сообщить модератору
     Re: Поругайте Акцесс. Очень надо.  [new]
    Лох Позорный
    Member

    Откуда:
    Сообщений: 9898
    2 IgorM
    Але, гараж?
    Мы говорим о сбоях?
    Никуда он (файл регистрации транзакций) не пропал.
    Почему не пропал? Очень даже пропал! Вместе со всем жестким диском (содержащим транзакшнлог), если так будет угодно достопочтимому джину. Если маразм - то до логического конца.

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

    если буквацифра в следующий раз будет проходить мимо - пусть буквацифра проходит дальше.
    25 янв 04, 04:57    [505920]     Ответить | Цитировать Сообщить модератору
     Re: Поругайте Акцесс. Очень надо.  [new]
    Лох Позорный
    Member

    Откуда:
    Сообщений: 9898
    О, забыл!
    Вычеркивай из резюме слова "программист БД".
    Никому говнокопатель по совместительству не нужен?
    25 янв 04, 04:59    [505921]     Ответить | Цитировать Сообщить модератору
     Re: Поругайте Акцесс. Очень надо.  [new]
    IgorM
    Member

    Откуда: Тула - Москва, транзит
    Сообщений: 633
    ЛП
    Мы говорим о сбоях?


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

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


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

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


    Здесь я погорячился, прошу прощения.
    26 янв 04, 09:39    [506301]     Ответить | Цитировать Сообщить модератору
     Re: Поругайте Акцесс. Очень надо.  [new]
    Лох Позорный
    Member

    Откуда:
    Сообщений: 9898
    Где я писал, что диск пропал, сервер взорвался, серверная сгорела, здание рухнуло, а потом все закатали в асфальт?
    Однако почему у тебя могут пропасть любые данные, но только не лог?

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

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


    Возращаясь к dbFlashOSCacheWrites
    Access97 Help
    В рабочей области Microsoft Jet пользователь имеет возможность задать в методе CommitTrans константу dbFlushOSCacheWrites, Это приводит к принудительной записи на диск всех обновлений вместо их помещения во временный буфер. Без этого параметра пользователь может перехватить управление сразу после вызова метода CommitTrans программой приложения, выключить компьютер, и отказаться от записи данных на диск. Хотя включение данного параметра может сказаться на быстродействии приложения, это оказывается полезным в ситуациях, когда возможно отключение компьютера до сохранения на диске кэшированных изменений

    IgorM
    Не спорю, jet чужими кэшами не рулит, но хелп четко определят, что этот параметр используется для управления своим буфером (транзакций).

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

    Ссылок нет. Есть только экспериментальные проверки.
    У меня складывается впечатление, что этот параметр вообще нигде и никем не используется :)
    Характерно, что он в хелпе даже называется неправильно, не так, как в библиотеке. По крайней мере в DAO 2.5/3.5 Compatibility, DAO 3.51 и DAO 3.6 перечисление CommitTransOptionsEnum содержит только dbForceOSFlush (заметь, опять dbForceOSFlush)
    Ссылки есть, что этот параметр используется и работает?
    26 янв 04, 11:08    [506431]     Ответить | Цитировать Сообщить модератору
     Re: Поругайте Акцесс. Очень надо.  [new]
    Yo!
    Guest
    в оракле:
    1. на коммит сервер минуя кэш файловой системы записывает в лог транзакций (undo).
    2. логов транзакций как минимум 2 и всегда на разных дисках.
    26 янв 04, 11:27    [506464]     Ответить | Цитировать Сообщить модератору
     Re: Поругайте Акцесс. Очень надо.  [new]
    IgorM
    Member

    Откуда: Тула - Москва, транзит
    Сообщений: 633
    ЛП
    Не знаю как аксесе реализован лог транзакций (хотя бы потому что его там в явном виде нет :))


    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)."
    26 янв 04, 12:45    [506661]     Ответить | Цитировать Сообщить модератору
     Re: Поругайте Акцесс. Очень надо.  [new]
    SSY
    Member

    Откуда: Москва
    Сообщений: 198
    IMHO, самый убойный аргумент против Аксесса - безопасность. Любой может просто взять (скопировать себе куда захочет) файл БД, крякнуть его (средства имеются) и получить абсолютно все данные системы. Получить полный доступ к рабочей базе также, разумеется, не является проблемой.
    Практически любую защиту интерфейсной части, написанной на аксессе, также можно относительно легко сломать.

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

    С уважением, Сергей Смирнов.
    26 янв 04, 15:02    [507014]     Ответить | Цитировать Сообщить модератору
     Re: Поругайте Акцесс. Очень надо.  [new]
    fedd
    Member

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

    с тем же грехом, только копировать надо не mdb а gdb :)
    26 янв 04, 16:03    [507163]     Ответить | Цитировать Сообщить модератору
     Re: Поругайте Акцесс. Очень надо.  [new]
    alex_k
    Member

    Откуда: krasnoyarsk
    Сообщений: 6694
    нет, без гнего(греха) :-)
    в fb у клиента нет физического доступа к файлу на сервере, а если есть, то админ - мудак.

    а в аксесе, насколько я понимаю, у клиента есть физический доступ к файлу, посредством сетевой файловой системы винды.
    поправьте, если не прав.
    26 янв 04, 16:32    [507218]     Ответить | Цитировать Сообщить модератору
     Re: Поругайте Акцесс. Очень надо.  [new]
    Лох Позорный
    Member

    Откуда:
    Сообщений: 9898
    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 Help
    If 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
    а в аксесе, насколько я понимаю, у клиента есть физический доступ к файлу, посредством сетевой файловой системы винды.
    Истинная правда. Есть доступ. Нормальную защиту на аксесе не построишь.
    Есть, конечно, встроенные в аксес механизмы защиты данных, но они способны защитить только от тех, кто не догадается в каком-нить гугле набрать "взлом защиты аксеса"
    26 янв 04, 16:38    [507235]     Ответить | Цитировать Сообщить модератору
     Re: Поругайте Акцесс. Очень надо.  [new]
    Gluk (Kazan)
    Member

    Откуда:
    Сообщений: 9365
    2 ЛП

    Вы таки будете смеятся, но в Oracle на диск сперва пишутся именно логи (как правило в железное или софтварное зеркало). И не undo как эдесь ошибочно было сказано, а самые что ни на есть redo (в Oracle это очень различные понятия). Все эти (и многие другие ухищрения) с целью добиться ACID при максимально возможной производительности.
    26 янв 04, 16:40    [507241]     Ответить | Цитировать Сообщить модератору
    Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 [4] 5 6   вперед  Ctrl      все
    Все форумы / Сравнение СУБД Ответить