Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 75 76 77 78 79 [80] 81 82 83 84 .. 106   вперед  Ctrl
 Re: CACHE и MSSQL  [new]
Ptn
Guest
DocAl
Sergei Obrastsov
DocAl
Так tps или qps?

Сравнивались tps, предлагаются qps, так вроде серьезнее будет.
В смысле, "а в попугаях-то я гоораздо длиннее!"? Или просто в Каше с транзакциями не очень? Тут вот выяснили, что в Каше на разных слоях транзакции разные, и друг с другом несовместимые.


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

Для READ UNCOMMITED нет никакой разницы что использовать SQL-ную &SQL(BEGIN TRANSACTION) или COS-вскую TSTART.
9 янв 07, 09:11    [3614310]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Ptn
Guest
Gluk (Kazan)Тем более, что SQL-нашлепкой НЕ РЕКОМЕНДУЮТ пользоваться даже сами ярые апологеты Cache Этой наколенке даже до RBO оччччень далЁко[/quot]

И конечно же благородный дон осилить предоставить тынц ?

Не надоело еще мифы то придумывать ? Хотя что с форума то взять.
9 янв 07, 09:13    [3614322]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Sergei Obrastsov
Gluk (Kazan)

Либо денормализует БД как в случае хранение max-ов и count-ов в отдельных счетчиках
Со всеми вытекающими тормозами на конкурирующем обновлении этих счетчиков и необходимостями всех этих обновлений ручками

Не все так страшно. При постоянном обновлении счетчиков можно гарантировать наличие блоков с ними в кэше. А насчет ручек не стоит, ну надоело уже.


Мон Шер Ами, как это не странно, не Каша придумала кэш. Без кэширования была-бы невозможна ни одна современная РСУБД, просто потому-что диски - медленные устройства, но УВЕРЯЮ ВАС, наличие горячих грязных блоков еще никому не делало жизнь светлой и радостной.

Особенно в кластере
9 янв 07, 09:20    [3614346]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Ptn
Guest
Gluk (Kazan)

Динамическое изменение ПЛАНА и ЗАПРОСА это две больших разницы мон шер. Если я начну решать проблемы оптимизатора динамическим SQL-ем меня уволють

Зачем менять ЗАПРОС то ? где вы такое вычитали ? План меняется Пла-а-ан. Хороший такой план

Gluk (Kazan)

Тема сисек, тьфу транзакций не раскрыта, так можно их использовать из ридного M или тильки из слабоумной SQL-нашлепки ??? Не блокировка ручками всего и вся, а вменяемый Begin Transaction, Commit Transaction, ну и Rollback для кучи ?


Вы меня извините великодушно - но если такие матерые специалисты не смогли освоить в приведенной ссылке "See Also" или просто перейти в индекс по разделу.
Не говоря уже о встроенном полнотекстовом поиске в правом верхнем углу тынца.

То да тема сисек не раскрыта - снимать бюстгалтером еще учиться и учиться Извините

START Transaction, Commit, Rollback ... TSTART, TCOMMIT , TROLLBACK.
9 янв 07, 09:23    [3614355]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Выбегалло
Member

Откуда: Scottsdale, AZ, USA
Сообщений: 3823
Gluk (Kazan)
Ptn
Выбегалло Почитал. Проникся. Оказывается, для того, чтобы эффективно программировать на MUMPS, надо быть напроловину разработчиком движков баз данных. Все, за что в РСУБД уже заплачено - индексирование, к примеру - в M надо писать самому.
Ну значить так читал - чтение и толкование вслух извини платное.


Да нет, сказано там все это довольно внятно. Да и не тайна это ни для кого.



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

И, не в обиду вам будь сказано, но V52 из вас всех самый вменяемый, и, по-моему, самый практик от сохи - и он честно признается на стр 75 "Практически ничего из перечисленного вами мне делать не приходится. ". Так шта меня терзают смутные сомнения, что лично вы индексы в мумпсе применяете в основном в диспутах на форуме.


Ptn
Ptn
Кроме того, оптимизатор ценен тем, что позволяет менять план динамически - в зависимости от статистики индексов, таблиц, и много чего. А что можете вы ? В лучшем случает - написать его жалкое подобие, "если в таблице А меньше ста трок, использовать индекс 1, иначе - индекс 2". В 99.9% случаев и этого никто из М-программистов не делает, потому что не тот уровень.

Опа - нада же я тот самый 0.01% Оценил-оценил ) Читать раздел Dynamic SQL до просветления.
Вслух извини платное.


Динамическое изменение ПЛАНА и ЗАПРОСА это две больших разницы мон шер. Если я начну решать проблемы оптимизатора динамическим SQL-ем меня уволють


Да вы что ?! Кто бы, (кроме вас) мог в этом усомниться ! Я еще удивился, при чем тут приплетен динамический SQL, но списал на общую вашу невнятицу. А вы, стало быть, решили, что я предлагаю переписывать запросы ? И четенько так меня отбрили, молодец какой !
Ну так я уточню, поскольку, похоже, вы оптимизатора и издали не видели. Оптимизатор - он запросы не переписывает. Он перебирает разные варианты выполнения, и выбирает, как вы наверное уже догадываетесь - оптимальный. И я интересуюсь - а у вас есть хоть что-то, хоть жалкое подобие ? Если есть - хотелось бы взглянуть на текст, как вы понимаете, чай не в джентельменском клубе, на слово верить и рад бы, да не получается.

Ptn

Тема сисек, тьфу транзакций не раскрыта, так можно их использовать из ридного M или тильки из слабоумной SQL-нашлепки ??? Не блокировка ручками всего и вся, а вменяемый Begin Transaction, Commit Transaction, ну и Rollback для кучи ?


Вы меня спрашивате ? Ну откуда ж мне знать. Вы у нас специалист - вот и расскажите, как можно все три типа доступа использовать в одной транзакции, и чтоб они друг друга уважали. И что (какой мешанизм) мешает Васе Пупкину влезть в средину ваших данных, пока вы выполняете транзакцию, и вам всю малину проапдейтить. И эта... про дедлоки просвятите. Кто их обнаруживает, как разрешает. Если вы, конечно, понимаете, о чем я говорю.
Я весь уши, как говорится.
9 янв 07, 09:28    [3614365]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Ptn
vadiminfo >>Роль самодельных скриптов тогда не так высока, раз есть более продвинутые средства от ведущих фирм для тех же целей.
Согласен - как то доводилось работать с Кристал Репортс - но всегда могуть быть нюансы разработки.


Поскольку с М Кристалл работать не умеет, работа явно производилась через SQL-нашлепку.
На нерегламентированных запросах :) ага. Ну и как быстродействие ? В продакт пошло ???
9 янв 07, 09:28    [3614366]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Ptn
c127 >>Поэтому если хотите что-то изобразить по этому пункту, то изображайте на М.

^T.TD=3
^T.TD(1)=$LB(1,3)
^T.TD(2)=$LB(1,2)
^T.TD(3)=$LB(2,3)

^T.TDI("a2Index",1,2,1)=""
^T.TDI("a2Index",1,3,2)=""
^T.TDI("a2Index",2,3,3)=""

Приводить весь сгенерированный М код не вижу смысла. Но вы правы - вопрос не мой.


Гениально, я в следующий раз тоже буду приводить только раздел инициализации переменных, ссылаясь на то что постить весь код лениво. Спасибо за идею
9 янв 07, 09:31    [3614374]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Ptn
Gluk (Kazan)Тем более, что SQL-нашлепкой НЕ РЕКОМЕНДУЮТ пользоваться даже сами ярые апологеты Cache Этой наколенке даже до RBO оччччень далЁко


И конечно же благородный дон осилить предоставить тынц ?
Не надоело еще мифы то придумывать ? Хотя что с форума то взять.[/quot]

А зачем, Вы же их не даете, просто посылаете в свой раздел :(
Вот и я Вас ТУДА-ЖЕ пошлю. Подтверждающих примеров там ПРЕДОСТАТОЧНО
9 янв 07, 09:33    [3614386]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Ptn
Для READ UNCOMMITED нет никакой разницы что использовать SQL-ную &SQL(BEGIN TRANSACTION) или COS-вскую TSTART.


Оооо да это ВЫСОКИЙ уровень изоляции
Настолько высокий, что Oracle его даже не поддерживает
9 янв 07, 09:34    [3614391]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Ptn
Gluk (Kazan)

Динамическое изменение ПЛАНА и ЗАПРОСА это две больших разницы мон шер. Если я начну решать проблемы оптимизатора динамическим SQL-ем меня уволють

Зачем менять ЗАПРОС то ? где вы такое вычитали ? План меняется Пла-а-ан. Хороший такой план


Правда ??? [снимая лапшу с ушей], и как же это Вы меняете ПЛАН друг мой ???
Вы меняете запрос, впрочем для Вас это одно и то-же

Ptn

Gluk (Kazan)

Тема сисек, тьфу транзакций не раскрыта, так можно их использовать из ридного M или тильки из слабоумной SQL-нашлепки ??? Не блокировка ручками всего и вся, а вменяемый Begin Transaction, Commit Transaction, ну и Rollback для кучи ?


Вы меня извините великодушно - но если такие матерые специалисты не смогли освоить в приведенной ссылке "See Also" или просто перейти в индекс по разделу.
Не говоря уже о встроенном полнотекстовом поиске в правом верхнем углу тынца.


Читать до просветления про ACID, грязное чтение это не то о чем я мечтал всю жизнь
9 янв 07, 09:38    [3614407]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Выбегалло
Member

Откуда: Scottsdale, AZ, USA
Сообщений: 3823
Ptn

То да тема сисек не раскрыта - снимать бюстгалтером еще учиться и учиться Извините

START Transaction, Commit, Rollback ... TSTART, TCOMMIT , TROLLBACK.


Еще раз, для слабо понимающих :

http://docs.intersystems.com/csp/docbook/DocBook.UI.Page.cls?KEY=RSQL_starttransaction

Caché ObjectScript transaction processing, using TSTART and TCOMMIT, differs from, and is incompatible with, SQL transaction processing using the SQL statements START TRANSACTION and COMMIT.

Ну-ка, поделитесь с нами, что случится, если вы сделаете START TRANSACTION, измените данные - и в этот момент ваш коллега запустит TSTART и полезет менять те же самые данные, используя ObjectScript ? А другой ваш коллега, человек старой закалки, не мудрствуя лукаво, откроет цикл и потянет свои грязные ручки все к тем же многострадальным данным ? Неужто они оба получат отлуп и будут ждать вашего коммита ? или таки внесут свою скромную лепту в количество трудноуловимых багов вашей системы ?
9 янв 07, 09:39    [3614412]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Ptn
Guest
Выбегалло>>Так шта меня терзают смутные сомнения, что лично вы индексы в мумпсе применяете в основном в диспутах на форуме.

Я там привел для c127 пример класса - там есть индексы - рассматривайте сколь душе угодно.


>>А вы, стало быть, решили, что я предлагаю переписывать запросы ? И четенько так меня отбрили, молодец какой !

Не надо грязи. Это фраза принадлежить Gluk (Kazan) Так что ваш ответ пускай он и комментирует - и собнсо как видите - он в этом упорствует

Gluk (Kazan)
Правда ??? [снимая лапшу с ушей], и как же это Вы меняете ПЛАН друг мой ???
Вы меняете запрос, впрочем для Вас это одно и то-же


Так что таварищи оппоненты - доки вам всё предоставлены - а ваши домыслы вы между собой разбирите.


>>Вы у нас специалист - вот и расскажите, как можно все три типа доступа использовать в одной транзакции, и чтоб они друг друга уважали.

Уй ты господи... фомы неверующие
new sc,Obj,SQLCODE
set sc=$$$OK
TSTART
set Obj=##class(Cinema.Film).%Open(1,3)
set ^MyFilms("JUR",$i(^MyFilms),Obj.%Id())=Obj.Category.CategoryName
do Obj.CategorySetObjectId(^MyFilms("SET",Obj.%Id()))
set sc=Obj.%Save(0)
if $$$ISOK(sc) {
 &SQL(UPDATE Cinema.USER_FovoriteFilms SET FovoriteFilms_Category=Obj.CategoryGetObjectId() WHERE Films=:Obj.%Id())
 set:SQLCODE<0 sc=$$$ERROR(5001,"Не удалось обновить сведения о категории SQLCODE="_SQLCODE)
}
if $$$ISOK(sc) { TCOMMIT  } else { TROLLBACK }

На основе заполненого глобала (пришел извне)- поменять у Фильма категорию, старую скинуть в журнал для выгрузки вовне, после чего обновить категорию фильма в коллекции фильмов у всех пользователей.
9 янв 07, 10:02    [3614551]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Ptn
Guest
Выбегалло
Ptn

То да тема сисек не раскрыта - снимать бюстгалтером еще учиться и учиться Извините

START Transaction, Commit, Rollback ... TSTART, TCOMMIT , TROLLBACK.


Еще раз, для слабо понимающих :

http://docs.intersystems.com/csp/docbook/DocBook.UI.Page.cls?KEY=RSQL_starttransaction

Caché ObjectScript transaction processing, using TSTART and TCOMMIT, differs from, and is incompatible with, SQL transaction processing using the SQL statements START TRANSACTION and COMMIT.

Ну-ка, поделитесь с нами, что случится, если вы сделаете START TRANSACTION, измените данные - и в этот момент ваш коллега запустит TSTART и полезет менять те же самые данные, используя ObjectScript ? А другой ваш коллега, человек старой закалки, не мудрствуя лукаво, откроет цикл и потянет свои грязные ручки все к тем же многострадальным данным ? Неужто они оба получат отлуп и будут ждать вашего коммита ? или таки внесут свою скромную лепту в количество трудноуловимых багов вашей системы ?


Ну если у вас программисты могут использовать функционал с документированными ограничениями да еще втихушку от напарников, проектировщика и архитектора ПО.

То да - у вас может случится что угодно. И закончиться скорее всего увольнением этого "кадавра".

Как ваши домыслы относяться к реальной жизни непонятно - пишите исчо

ЗЫ: Как легче всего отстрелить ногу на М ? - дать почитать доки РСУБД-никам.
9 янв 07, 10:11    [3614626]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Локшин Марк
Member

Откуда: Воронеж
Сообщений: 3155
iscrafm
Локшин Марк
large machines with lots of memory - это надо понимать Sempron и есть, да? Ой, а в AMD то и не знают, надо будет наверное дуракам этим написть, а то на халяву продают.
напишите. они любят читать спам от остряков и подобный поток сознания.

Т.е. Вы хотите сказать, что одна из самых дешевых конфигураций - это "large machines with lots of memory"? Ну-ну.
iscrafm
Наблюдая за всем этим проникаешься уважением к сторонникам MUMPS, видимо все таки более взрослые и состоявшиеся люди

Может тогда Вас не затруднит разяснить за вашего фруктового друга про изменения в распределенной системе? А то он как-то я смотрю выдохся...
Насчет возраста - не спорю, оно как говорят - старость не радость, а вот в чем состоятельность-то мерять будем?
9 янв 07, 10:11    [3614627]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Изопропил
Member

Откуда:
Сообщений: 31627
[quot PtnНу если у вас программисты могут использовать функционал с документированными ограничениями да еще втихушку от напарников, проектировщика и архитектора ПО.
[/quot]

не втихушку, а по ошибке. А предлагаемый зоопарк шансы на ошибку увеличивает
9 янв 07, 10:16    [3614655]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Ptn
Guest
Gluk (Kazan)
Ptn
vadiminfo >>Роль самодельных скриптов тогда не так высока, раз есть более продвинутые средства от ведущих фирм для тех же целей.
Согласен - как то доводилось работать с Кристал Репортс - но всегда могуть быть нюансы разработки.


Поскольку с М Кристалл работать не умеет, работа явно производилась через SQL-нашлепку.
На нерегламентированных запросах :) ага. Ну и как быстродействие ? В продакт пошло ???


Ему и не нужно работать с М. Ему нужно уметь работать с SQL.

А вот что там на сервере внутри таблицы, вьюхи или хранимой процедуры - М и/или объекты и/или SQL - ему совершенно фиолетово. Да и не положено.

Работает - уже леть пять как.
9 янв 07, 10:17    [3614662]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 30237
Ptn
С точки зрения сравнения (а именно это я имел в виду) - вот приведут какую нибудь задачу.
Вы приведете решение на SQL и я приведу решение на SQL и что сравнивать ?

производительность, разумеется, и уровень реализации функционала SQL.

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


это пример с TSTART. А вопрос был более прямой - как взаимодействуют эти три разных режима управления/неуправления транзакциями?
9 янв 07, 10:19    [3614669]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Ptn
Guest
Изопропил
не втихушку, а по ошибке. А предлагаемый зоопарк шансы на ошибку увеличивает


Такое может быть - правда это как с убийством в состоянии аффекта.

Вошел в состояние аффекта - пошел в сарай - открыл сейф с кодовым замком - достал ружо - снарядил патроны - причем разрывные - потом пошёл к соседу и случайно выстрелил ему ему в ухо.

В таком случае - товарисч Выбегалло прочитав документацию делает вывод что М-спецы сплош ошибку на ошибке лепять.

От "ошибки" вас не спасет любая система.
9 янв 07, 10:22    [3614700]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Ptn
Guest
kdv

это пример с TSTART. А вопрос был более прямой - как взаимодействуют эти три разных режима управления/неуправления транзакциями?


Замените в примере

TSTART - &SQL(START TRANCATION)
TCOMMIT - &SQL(COMMIT)
TROLLBACK - &SQL(ROLLBACK)

и будет вам счастье. Еще раз, если доки лень читать, "ружо" нужно еще достать и снарядить.

По умолчанию всё со всем совместимо по самое немогу.
9 янв 07, 10:26    [3614720]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Изопропил
Member

Откуда:
Сообщений: 31627
Ptn
kdv

это пример с TSTART. А вопрос был более прямой - как взаимодействуют эти три разных режима управления/неуправления транзакциями?


Замените в примере

TSTART - &SQL(START TRANCATION)
TCOMMIT - &SQL(COMMIT)
TROLLBACK - &SQL(ROLLBACK)

и будет вам счастье. Еще раз, если доки лень читать, "ружо" нужно еще достать и снарядить.

По умолчанию всё со всем совместимо по самое немогу.


Вопрос про уровни изоляции транзакций не раскрыт
9 янв 07, 10:28    [3614745]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Ptn
Guest
Gluk (Kazan)
Ptn
Для READ UNCOMMITED нет никакой разницы что использовать SQL-ную &SQL(BEGIN TRANSACTION) или COS-вскую TSTART.


Оооо да это ВЫСОКИЙ уровень изоляции
Настолько высокий, что Oracle его даже не поддерживает


С не поддерживает try catch - а половина функций со строками вообще на ёё длину относительно буфера кладут.

УЖОС!
9 янв 07, 10:30    [3614755]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Ptn
Guest
Изопропил
Ptn
kdv

это пример с TSTART. А вопрос был более прямой - как взаимодействуют эти три разных режима управления/неуправления транзакциями?


Замените в примере

TSTART - &SQL(START TRANCATION)
TCOMMIT - &SQL(COMMIT)
TROLLBACK - &SQL(ROLLBACK)

и будет вам счастье. Еще раз, если доки лень читать, "ружо" нужно еще достать и снарядить.

По умолчанию всё со всем совместимо по самое немогу.


Вопрос про уровни изоляции транзакций не раскрыт


То есть тынц вы не читали ? И второй тынц про соответсвие SQL-92 тоже? Как изволите с вами общатся ?

Времени то у меня много ... было бы желание у оппонентов вести беседу.
9 янв 07, 10:35    [3614790]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Выбегалло
Member

Откуда: Scottsdale, AZ, USA
Сообщений: 3823
Ptn
kdv

это пример с TSTART. А вопрос был более прямой - как взаимодействуют эти три разных режима управления/неуправления транзакциями?


Замените в примере

TSTART - &SQL(START TRANCATION)
TCOMMIT - &SQL(COMMIT)
TROLLBACK - &SQL(ROLLBACK)

и будет вам счастье. Еще раз, если доки лень читать, "ружо" нужно еще достать и снарядить.

По умолчанию всё со всем совместимо по самое немогу.


не-не-не, не надо передергивать. Вопрос был - что случится, если TSTART оставить, а в средину вашего кода втулить &SQL(START TRANCATION) , какой-нить &SQL(UPDATE) и , до кучи, s ^MyFilms.
Остановит ли их система, или они таки наступят друг другу на гонококки ? И не надо мне петь военных песен про дисциплину программирования, джентельменские договора и немедленный расстрел идиотов за сараем - в реальной жизни реальные системы состоят из спагетти кода, и ничего кроме спагетти кода.
9 янв 07, 10:44    [3614853]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Изопропил
Member

Откуда:
Сообщений: 31627
Ptn
То есть тынц вы не читали ? И второй тынц про соответсвие SQL-92 тоже? Как изволите с вами общатся ?

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

Ваш тынц показыет, что READ COMMITED - максимум чего можно добиться.

There is a limit on the number of subnodes (child tables) that can be deleted as the result of a node delete operation. The default value for this limitation is 1000 subnode kills. Subnode kills in excess of this limit are not journaled, and thus cannot be rolled back. This default limit can be changed using the Caché Configuration Manager. Go to the Advanced Tab and select the Journal options, which displays the Journal Kill Rollback Limit option. You can set this option to a value between 1000 and 65535, inclusive.
ROLLBACK хоть ошибку выдаст?

By default, uncommitted updates to data are visible for read access by other users. This is the same as ISOLATION LEVEL READ UNCOMMITTED, If you specify ISOLATION LEVEL READ COMMITTED in SET TRANSACTION or START TRANSACTION, uncommitted updates are not visible. Instead, you may get a lock wait or time out if you attempt to read uncommitted data
Предлагается для любого чтения открывать транзакцию? Спасибо, не надо.
9 янв 07, 10:50    [3614889]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 30237
Как это у вас, Ptn, транзакции одинаковые, когда в той же доке, на которую ВАМ ДАЛИ ССЫЛКУ, они не одинаковые?

http://docs.intersystems.com/csp/docbook/DocBook.UI.Page.cls?KEY=RSQL_starttransaction

Caché ObjectScript transaction processing, using TSTART and TCOMMIT, differs from, and is incompatible with, SQL transaction processing using the SQL statements START TRANSACTION and COMMIT.

и потом - An application should not attempt to mix the two types of transaction processing.
А 2 application могут использовать каждая свой тип старта-завершения транзакций? Судя по всему - нет. Т.е., если мы начинаем работать с транзакциями в некоем комплексе приложений, где могут быть обращения к "пересекающимся" данным, то либо только в SQL, либо в COS, но не "одновременно".


А собственно, после прочтения по упомянутой ссылке следующего текста:
Query operations using the SELECT DISTINCT or GROUP BY clauses, or invoking aggregate functions are unaffected by the ISOLATION MODE option. Aggregate functions always return the current state of all changes, including changes not yet committed. Because aggregate functions such as COUNT(*) involve large numbers of records and return values that are constantly changing, the value of an aggregate at any given moment cannot reflect the exact state of changes occurring in the current transaction.

можно уже дальше ничего не читать.
9 янв 07, 10:53    [3614918]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 75 76 77 78 79 [80] 81 82 83 84 .. 106   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить