Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 [3] 4   вперед  Ctrl      все
 Re: Сравнительный анализ СУБД (MS SQL Server, MS Access и др.)  [new]
ЛП
Guest
2 Victor Metelitsa
Представим себе такой случай: в базе данных какого-то SQL-сервера хранится какой-то код... ну, например, Java-код, Visual Basic scripts или даже исходники на C, которые потом компилируются; клиенты вытягивают его себе и выполняют у себя - либо по запросу пользователя (аналог хранимых процедур), либо по какому-то событию (аналог триггеров).

У Вас еще остались вопросы относительно потенциальной возможности (или принципиальной невозможности) реализации хранимых процедур и триггеров в ФС-системах?
Слово "аналог", так и быть, пропущу мимо ушей. По крайней мере дам Вам еще один шанс в буквари заглянуть. Ни в одном букваре не сказано, что хранимая процедура обязана исполняться строго одним и строго серверным процессом. Это исключительно Ваши фантазии.

Но это совсем не то, что предлагают нормальные SQL-сервера

SQL-запрос остается SQL-запросом независимо от того, кто его исполняет - сервер (КС) или клиент (ФС)
Хранимая процедура остается хранимой процедурой независимо от того, кто её исполняет - сервер (КС) или клиент (ФС)
Триггер остается триггером независимо от того, кто его исполняет - сервер (КС) или клиент (ФС)
А уж что там предлагают "нормальные SQL-сервера" - целиком и полностью на их совести.

Как же фокс будет разбираться с такими вещами, если у него вообще какой-то транзакционный лог есть?

Совершенно не в курсе. Я фокс ни разу в жизни не видел.

Что касается сетевого файлового доступа, то тут всё ясно. Когда фокс упрётся в бутылочное горлышко сети, никакая модернизация сервера не повысит производительность, неважно, сколько процессоров на нём будет, сколько ОЗУ и какие диски.

Это что, очередное проявление дибилизма? Узкое место - сеть, а модернизировать - сервер? Зачем? Чтобы показать, что АйКю до семидяситипяти не дотягивает?
Точно так же можно сказать, что "когда MS SQL Server упрется в бутылочное горлышко производительности сервака, никакая модернизация сети не повысит производительность". Фраза - брат близнец Вашей, настолько же правильная, и настолько же не в тему.

Спасибо, что напомнили про security.

Да я про неё и не забывал. И про надежность не забывал. Честным образом посоветовал по этим критериям поставить что аксесу, что фоксу по минус единичке.
Однако при чем здесь это? Изначально спор шел про:
а) декларируемую принципиальную невозможность существования хранимых процедур в ФС-системах.
б) голословные (и в общем случае неправильные) утверждения о выигрыше в производительности в "многопользовательском окружении"
Ни секьюрити, ни надежность тут не в кассу.
22 июн 06, 14:42    [2802392]     Ответить | Цитировать Сообщить модератору
 Re: Сравнительный анализ СУБД (MS SQL Server, MS Access и др.)  [new]
ЛП
Guest
2 pkarklin
прикольный топег...

Гыыы.. прикольный пкарклин... читать не умеет :)


Вот тут Вы в самую точку попали, а действительно, КТО?! В К\С СУБД этим занимается ЕДИНСТВЕННЫЙ реляционный движок и именно через этот единственный движек ходят все к данным. А что с фокспро (да и с любой другой Ф\С СУБД) - сколько клиентов, столько и движков.

У машины 4 колеса (иногда больше), а у велосипеда 2 (иногда меньше). Что дальше? Вы пытаетесь мне рассказать про разницу между ФС и КС? Не стоит, Вы её сами не понимаете.

Надеюсь, что дальше не надо объяснять про контроль DRI, транзакции и т.п?!

Расскажите, будет очень интересно послушать
очередной пластелиновый дятел, блин.

Достаточно взять букварь по архитектуре какого-нибудь сервера СУБД и посмотреть, как там все это реализовано. Особенно в плане транзакций. Была уже тут перепалка по этому поводу. Честная поддержка транзакций невозможна без централизованного движка и ведения write-ahead лога.

Очередные больные фантазии туповатого узколобого фаната.
В сад. Учебники читать.

автор
Нука-нука???!!! И кто будет ее поддерживать, если не одно клиентское приложение (ни один движк) не работает??? Буквари читать надо кому-то другому!!!


Кто будет поддерживать ссылочную целостность базы, с которой никто не работает?
Браво!
упалпацтул


Ааа... Уссаться... Боремся не с причиной, а со следствием!

Нет, мой неумеющий читать туповатый друг. Ни с чем не боремся, а всего лишь указываем на некорректность перескока с обсуждения "производительности в многопользовательском окружении" на "узкое место при сетевой работе". Сеть в ФС может остаться узким местом и при однопользовательском доступе, впрочем, и в многопользовательском режиме может узким местом не являться (приведенный пример с терминалом).
22 июн 06, 14:53    [2802446]     Ответить | Цитировать Сообщить модератору
 Re: Сравнительный анализ СУБД (MS SQL Server, MS Access и др.)  [new]
zhouck
Member

Откуда:
Сообщений: 359

ЛП wrote:

> SQL-запрос остается SQL-запросом независимо от того, кто его исполняет -
> сервер (КС) или клиент (ФС)
Эт понятно.
> Хранимая процедура остается хранимой процедурой независимо от того, кто
> её исполняет - сервер (КС) или клиент (ФС)
Ну тоже
> Триггер остается триггером независимо от того, кто его исполняет -
> сервер (КС) или клиент (ФС)
А кто заставит клиента выполнить триггер? Если, к примеру клиентский
движок отключит их выполнение? И что тогда? Это типа в делфовых прогах
OnBeforeInsert и OnAfterInsert вы тоже назовете триггерами.
Таким образом серверный триггер сработает назависимо от того, какой
движок будет использоваться на клиенте. Клиентский "триггер" - только
если клиентский движок поддерживает выполнение. Разница ясна?

Posted via ActualForum NNTP Server 1.3

22 июн 06, 15:06    [2802549]     Ответить | Цитировать Сообщить модератору
 Re: Сравнительный анализ СУБД (MS SQL Server, MS Access и др.)  [new]
ЛП
Guest
2 zhouck
А кто заставит клиента выполнить триггер? Если, к примеру клиентский движок отключит их выполнение?

Хосспадя ты боже мой...
А кто заставляет клиента запускать каскадное удаление связанных записей?
А кто заставляет клиента нулябельность полей проверять перед апдейтами?
А кто заставляет клиента дефолтовые значения вставлять при инсертах?

В случае аксеса - Jet заставляет.
А все клиентские проги работают через джет. Работать не через jet они не могут. Т.е. "не заставиться" у них не получится.
Ну разве что найдуться клоуны, которые "а если йа напешу праграму каторая в апхот всиво запишыт штота напрямуйу в файло з данными"
22 июн 06, 15:21    [2802652]     Ответить | Цитировать Сообщить модератору
 Re: Сравнительный анализ СУБД (MS SQL Server, MS Access и др.)  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
ЛП
У машины 4 колеса (иногда больше), а у велосипеда 2 (иногда меньше). Что дальше? Вы пытаетесь мне рассказать про разницу между ФС и КС? Не стоит, Вы её сами не понимаете.


Ага. Хуz с горы большая скорость, вот только колеса, вы тут ой как ни к месту приплели.

автор
Очередные больные фантазии туповатого узколобого фаната.
В сад. Учебники читать.


Вот жешь, сцуко...

ЛП
Кто будет поддерживать ссылочную целостность базы, с которой никто не работает?
Браво!
упалпацтул


Вы представлете себе, сервера СУБД поддерживают ссылочную целостность, даже когда с базой никто не работает. Да, да, не написать, ту программку, которая бы обошла то самое единственное ядро и что-нить исковеркала или файле аксеса, или в файлах фокса. Если Вы от этого сползли со стула, то разницу между К\С и Ф\С Вам действительно бесполезно объяснять. И туповайты узколобый фанат здесь кто-то другой. ;) Ибо меня заставили перейти на К\С СУБД не новомодные течения, а та самая с позволения сказать "поддержка целосности и транзакций" в Ф\С СУБД. А с такими я вдоволь любовью на занимался в свое время.

ЛП
Нет, мой неумеющий читать туповатый друг. Ни с чем не боремся, а всего лишь указываем на некорректность перескока с обсуждения "производительности в многопользовательском окружении" на "узкое место при сетевой работе". Сеть в ФС может остаться узким местом и при однопользовательском доступе, впрочем, и в многопользовательском режиме может узким местом не являться (приведенный пример с терминалом).


Нет уж, позвольте. Если у меня при около 500 работающих юзерах средняя нагрузка на сеть не превышает 10% (100 мбит), то у меня и в мыслях не будет переводить их на работу через терминал. ТАк что никакой это не перекос. И, если Вы не хотите этого понимать, то это Ваши проблемы.
22 июн 06, 15:22    [2802659]     Ответить | Цитировать Сообщить модератору
 Re: Сравнительный анализ СУБД (MS SQL Server, MS Access и др.)  [new]
1024
Member

Откуда: Нижний Новгород
Сообщений: 14267
автор
Таким образом серверный триггер сработает назависимо от того, какой
движок будет использоваться на клиенте. Клиентский "триггер" - только
если клиентский движок поддерживает выполнение. Разница ясна?


мда...

тебе русским языком говорят что это и есть разница в архитектуре между файлсервером и клиентсервером. Несколько движков или один. Это сказывается на надёжности, на остальных параметры может не влиять.
22 июн 06, 15:24    [2802673]     Ответить | Цитировать Сообщить модератору
 Re: Сравнительный анализ СУБД (MS SQL Server, MS Access и др.)  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
ЛП
Ну разве что найдуться клоуны, которые "а если йа напешу праграму каторая в апхот всиво запишыт штота напрямуйу в файло з данными"


Чуть Выше Вы хотели написать такую програмку. Я, кстати, с нетерпением жду, чтоб "порушить" свой MS SQL. А вот access и fox я порушу любым редактором!

ЛП
А все клиентские проги работают через джет. Работать не через jet они не могут. Т.е. "не заставиться" у них не получится.


Бл$, Вы действительно тупой, или прикидываетесь? Если бы jet был один на всех пользователей, то да. А так их много, джетов то. И каджый наровит целостность сохранить и транзакции поддержать, работая с одним и тем же файлом. И вот отвалился один клиент посреди транзакции от сети, а буферочки то у него на клиенте, лога централизованного нет. Как остальные джеты узнают, чего она там наделал до середины транзакции, а чего нет?
22 июн 06, 15:28    [2802703]     Ответить | Цитировать Сообщить модератору
 Re: Сравнительный анализ СУБД (MS SQL Server, MS Access и др.)  [new]
zhouck
Member

Откуда:
Сообщений: 359

ЛП wrote:

> Автор: ЛП
> 2 zhouck
> А кто заставит клиента выполнить триггер? Если, к примеру клиентский
> движок отключит их выполнение?
>
>
> Хосспадя ты боже мой...
> А кто заставляет клиента запускать каскадное удаление связанных записей?
> А кто заставляет клиента нулябельность полей проверять перед апдейтами?
> А кто заставляет клиента дефолтовые значения вставлять при инсертах?
>
> В случае аксеса - Jet заставляет.
> А все клиентские проги работают через джет. Работать не через jet они не
> могут. Т.е. "не заставиться" у них не получится.
> Ну разве что найдуться клоуны, которые /"а если йа напешу праграму
> каторая в апхот всиво запишыт штота напрямуйу в файло з данными"/

Та ты шо? Т.е. линкусоиды не смогут написать свой движок для доступа к
аксезу? Так шо ли? Оно ж только через джет работает? Т.е. написать свой
движок доступа к данным ты вообще считаешь нереальной задачей? Да, Лох?

Posted via ActualForum NNTP Server 1.3

22 июн 06, 15:29    [2802716]     Ответить | Цитировать Сообщить модератору
 Re: Сравнительный анализ СУБД (MS SQL Server, MS Access и др.)  [new]
ЛП
Guest
2 pkarklin
Вы представлете себе, сервера СУБД поддерживают ссылочную целостность, даже когда с базой никто не работает.

Ага. Скажите еще, что они поддерживают ссылочную целостность даже когда сервер выключен.
Непонятно только зачем.

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

Да, да, не написать ту программку, которая обошла бы тот самый единственный инстанс MS SQL Server'а и что-нить исковеркала в файлах mdf+ldf.

Ну так что, пкарклин, разовьешь свой бред "Честная поддержка транзакций невозможна без централизованного движка и ведения write-ahead лога.". Или скажешь что это "по определению", как всегда любят говорить те, кто не читает книжек?

И вот отвалился один клиент посреди транзакции от сети, а буферочки то у него на клиенте, лога централизованного нет. Как остальные джеты узнают, чего она там наделал до середины транзакции, а чего нет?

Ты дурак, или как? Нафига кому-то знать - что было сделано посреди транзакции, которая отвалилась?
22 июн 06, 15:32    [2802728]     Ответить | Цитировать Сообщить модератору
 Re: Сравнительный анализ СУБД (MS SQL Server, MS Access и др.)  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
ЛП
Ну так что, пкарклин, разовьешь свой бред "Честная поддержка транзакций невозможна без централизованного движка и ведения write-ahead лога.". Или скажешь что это "по определению", как всегда любят говорить те, кто не читает книжек?


Это не бред. И не "по определению", а по архитектре. H5N1 приводил ссылку. Повторюсь еще раз. Пусть в акссес начали транзакцию, поменяли 1000 записей, которые забуфферизировались в локальном буффере и скомандывали COMMIT. Jet на клиентской машине начал писать все это в файл на сервере и улутел в голубой экран на 501 записи. В каком виде окажеться файл бд? Кто будет заниматься откатом (приведением его в состояние до начала транзакции) при следующем запуске клиента, если другие jetы понятия не имеют, чего он там наменял в файле? В К\С СУБД за это как раз отвечает лог. Как он работает, можно почитать в доке к любой СУБД.

ЛП
Ты дурак, или как? Нафига кому-то знать - что было сделано посреди транзакции, которая отвалилась?


Ну, если я дурак, то просветите меня дурака, как это будет все "вычешено" в Ф\С СУБД.
22 июн 06, 15:52    [2802864]     Ответить | Цитировать Сообщить модератору
 Re: Сравнительный анализ СУБД (MS SQL Server, MS Access и др.)  [new]
H5N1
Guest
ЛП
SQL-запрос остается SQL-запросом независимо от того, кто его исполняет - сервер (КС) или клиент (ФС)

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

2ALL
кто нибудь не с размягшими от ФС мозгами нашел как реализованы транзакции и уровни изолированости в access ?
22 июн 06, 15:57    [2802897]     Ответить | Цитировать Сообщить модератору
 Re: Сравнительный анализ СУБД (MS SQL Server, MS Access и др.)  [new]
H5N1
Guest
2pkarklin

там интересней, в access похоже подругому транзакции работают, но сказать наверника пока нельзя в документации наверника та же лажа что и foxpro.
22 июн 06, 16:00    [2802922]     Ответить | Цитировать Сообщить модератору
 Re: Сравнительный анализ СУБД (MS SQL Server, MS Access и др.)  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
2 H5N1

Мне известно несколько технологий, реализующих поддержку atomicity и durability (2х из 4х от ACID). write ahead logging (WAL) наиболее популярен и его юзают современные сервера СУБД. Раньше на менфреймах юзали shadow paging. Осталось выяснить у ЛП, какой технологией A и D поддерживается в фоксе.
22 июн 06, 16:09    [2802996]     Ответить | Цитировать Сообщить модератору
 Re: Сравнительный анализ СУБД (MS SQL Server, MS Access и др.)  [new]
ЛП
Guest
2 pkarklin
Это не бред. И не "по определению", а по архитектре.

Это по клиент-серверной архитектуре.
Как правильно было замечено - наиболее популярный способ.
Как еще более правильно было замечено - даже в КС это не единственный способ.

Осталось только Вам свои собственные слова прочитать еще раз, и попытаться их скрестить опять таки с Вашими же собственными словами "Честная поддержка транзакций невозможна без централизованного движка и ведения write-ahead лога". Если не страдаете шизофренией, то уж определитесь - или "невозможна", или "наиболее популярный способ".

В ФС этот "наиболее популярный способ" неприменим. Что не мешает пользоваться другими (хоть и "менее популярными") способами.

Ну, если я дурак, то просветите меня дурака, как это будет все "вычешено" в Ф\С СУБД

Ищите поиском по форуму. Обсуждалось неоднократно. Применительно к аксесу.
Неохота в стописятый раз одну и ту же лекцию читать.

автор
Осталось выяснить у ЛП, какой технологией A и D поддерживается в фоксе.

Если Вы не умеете читать, то попросите кого-нибудь рядом сидящего прочитать Вам вслух следующую фразу:
Я НЕ ЗНАЮ, КАК И ЧТО РЕАЛИЗОВАНО В ФОКСЕ. ПАТАМУШТА Я ЕГО НИ РАЗУ НЕ ВИДЕЛ.
22 июн 06, 16:26    [2803123]     Ответить | Цитировать Сообщить модератору
 Re: Сравнительный анализ СУБД (MS SQL Server, MS Access и др.)  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
Поиск, говорите... Да и без поиска я знаю этот топик. Однако тут же натыкаемся на Ваше высказывание (или это не Ваше?). тынц

Теперь Вы с пеной у рта доказываете мне обратное, или это не Вы? :)

А вот Вы расказываете про "физику процесса" на пальцах: Есть ли будущее у файл-сервера?

И где в Вашем же описании можно найти то самое место, когда атомарность не будет соблюдена. Что я и наблюдал, работая и с аксесом и с фокспро. Так что, можете сколько угодно отсылать меня чиать книжки, но ни аксее ни фокс не умеют поддерживать A и D!
22 июн 06, 16:47    [2803270]     Ответить | Цитировать Сообщить модератору
 Re: Сравнительный анализ СУБД (MS SQL Server, MS Access и др.)  [new]
ЛП
Guest
pkarklin
Поиск, говорите... Да и без поиска я знаю этот топик. Однако тут же натыкаемся на Ваше высказывание (или это не Ваше?). тынц

Теперь Вы с пеной у рта доказываете мне обратное, или это не Вы? :)

Але, гараж? Где в этом тынце что-то про реализацию транзакций?
И что такого "обратного" я доказываю? Про надежность и устойчивость к сбоям я вроде тут неоднократно высказался, и высказывания от предыдущих мало чем отличаются.
Может хватит бредить, а, пкарклин?

А вот Вы расказываете про "физику процесса" на пальцах: Есть ли будущее у файл-сервера?

И где в Вашем же описании можно найти то самое место, когда атомарность не будет соблюдена.

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

Что я и наблюдал, работая и с аксесом и с фокспро. Так что, можете сколько угодно отсылать меня чиать книжки, но ни аксее ни фокс не умеют поддерживать A и D!

Бредите? Ну продолжайте бредить.

З.Ы. Если Вы вдруг так и не научились читать, то еще раз подчеркну, что все сказанное мною относительно всяких там транзакций - отностится только и исключительно к аксесу.
З.З.Ы. Нет, даже не спрашивайте меня, как транзакции реализованы в фоксе.
З.З.З.Ы. Нет, я действительно ничего не знаю про реализацию транзакций в фоксе.

-----

А вообще все начиналось с хранимых процедур
22 июн 06, 17:06    [2803416]     Ответить | Цитировать Сообщить модератору
 Re: Сравнительный анализ СУБД (MS SQL Server, MS Access и др.)  [new]
ы
Guest
ЛП
А вообще все начиналось с хранимых процедур

ужос :)
22 июн 06, 17:40    [2803634]     Ответить | Цитировать Сообщить модератору
 Re: Сравнительный анализ СУБД (MS SQL Server, MS Access и др.)  [new]
H5N1
Guest
pkarklin
2 H5N1

Мне известно несколько технологий, реализующих поддержку atomicity и durability (2х из 4х от ACID). write ahead logging (WAL) наиболее популярен и его юзают современные сервера СУБД. Раньше на менфреймах юзали shadow paging. Осталось выяснить у ЛП, какой технологией A и D поддерживается в фоксе.

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

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).

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/odeopg/html/deovrusingtransactions.asp

но че они этим хотели сказать я пока не понял :) может это они имели ввиду во время комита, а не до ...
22 июн 06, 17:52    [2803692]     Ответить | Цитировать Сообщить модератору
 Re: Сравнительный анализ СУБД (MS SQL Server, MS Access и др.)  [new]
ЛП
Guest
2 H5N1
Ты уже эту цитатку приводил, и по поводу неё уже долго смеялись.
При условии, что "server crashes before a transaction has had time to commit its changes" - ни о каком дюрабилити не может быть и речи не то что бы в ФС-системах, а и вообще нигде.
22 июн 06, 17:56    [2803728]     Ответить | Цитировать Сообщить модератору
 Re: Сравнительный анализ СУБД (MS SQL Server, MS Access и др.)  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
ЛП
В моем описании нет места, когда атомарность не будет соблюдена. Потому что такого места действительно нет. База может рухнуть - это да.


Бл$... Я в шоке. Атомарность у него соблюдена, но база рухнула.
22 июн 06, 18:02    [2803767]     Ответить | Цитировать Сообщить модератору
 Re: Сравнительный анализ СУБД (MS SQL Server, MS Access и др.)  [new]
ЛП
Guest
pkarklin
Бл$... Я в шоке. Атомарность у него соблюдена, но база рухнула.

Хммм... Ну бывает так, что базы падают... Везде такое бывает... И без транзакций такое бывает... От чего ж в шоке то быть? Сиквел, наверное, не падает никогда?
Или, мой туповатый друг, ты в шоке от того, что атомарность соблюдена? Ну тады ничем помочь не могу.
22 июн 06, 18:06    [2803784]     Ответить | Цитировать Сообщить модератору
 Re: Сравнительный анализ СУБД (MS SQL Server, MS Access и др.)  [new]
H5N1
Guest
ЛП

Ты уже эту цитатку приводил, и по поводу неё уже долго смеялись.
При условии, что "server crashes before a transaction has had time to commit its changes" - ни о каком дюрабилити не может быть и речи не то что бы в ФС-системах, а и вообще нигде.

правильно, а в документации по фокспро написано, что там есть транзакции. т.е. верить майкрософту нельзя, значит нада делать тесты самому, пытаясь угадать каже там на самом деле, что мне, например, совершенно не интересно...
22 июн 06, 18:07    [2803794]     Ответить | Цитировать Сообщить модератору
 Re: Сравнительный анализ СУБД (MS SQL Server, MS Access и др.)  [new]
ЛП
Guest
2 H5N1
т.е. верить майкрософту нельзя

Верить низзя ваапсче никому :)
22 июн 06, 18:11    [2803813]     Ответить | Цитировать Сообщить модератору
 Re: Сравнительный анализ СУБД (MS SQL Server, MS Access и др.)  [new]
Зайцев Фёдор
Member

Откуда: Лужки
Сообщений: 5308
ЛП
пол-коммита не будет

ЛП
атомарность соблюдена

Прикольно
22 июн 06, 18:17    [2803829]     Ответить | Цитировать Сообщить модератору
 Re: Сравнительный анализ СУБД (MS SQL Server, MS Access и др.)  [new]
ЛП
Guest
3JIA9I с**а
ЛП
пол-коммита не будет

ЛП
атомарность соблюдена

Прикольно

Под "пол-коммита не будет" имелось в виду, что будет либо нормальный коммит (все изменения), либо никакого (никаких изменений). Это в аксесе.
В фоксе, если верить форумам, народ умудрялся получить именно "пол-коммита", т.е. половину изменений закоммитили, половину протеряли куда-то. Может и правда.
22 июн 06, 18:22    [2803845]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 [3] 4   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить