Здравствуйте, IB, Вы писали:
IB>Здравствуйте, SmlMouse, Вы писали:
SM>>Как я понял, аргументов не будет? IB>Аргументов на что? Что ты хотел показать своим примером?
Твои утверждения:
SM>(2) меняет данные на основании фетча из (1).
IB:То есть (2) видит незафиксированные данные (1), и кто после этого читает по диагонали?
SM>Которые и называются "параллельными".
IB:Нет, они последовательные. Транзакция не может начаться, пока не зафиксируется предыдущая, если так понятнее.
SM> Так как в одном соединении в одно и то же время могут быть несколько активнывх транзакций.
IB:Нет в этом смысла. Нельзя так делать и не несет это никакой практической ценности, я уже усталписать почему.
В поддержку моих — код.
Теперь объясни мне, почему так как в коде — делать не правильно.
SM>>Только вот почему-то в БД мессаги под моим аккаунтом не отправлялись, тогда как Test работал без проблем IB>Понятия не имею чтотам у тебя случилось, когда банят выдается совершенно конкретное сообщение.
Ну не знаю. Меня ещё ни разу не банили. А RSDN@Home выдает конкретное сообщение?
--
WBR и ничего личного
... << RSDN@Home 1.2.0 alpha rev. 743>>
Здравствуйте, Alex.Che, Вы писали:
AC>А может ты сперва ознакомишься с тем, что там и как в IB/FB, прежде тем строить эфемерные теории?..
Можно ссылочку на документацию FB, где сказано, что он выполняет мини откаты при RC, и как он это делает?
Здравствуйте, IB, Вы писали:
КД>> MARS, из-за которого все и покатилось, получается вообще ни при чем — примеров, которые можно просто взять и потестить, так и не привели. IB>Ну открой ты MSDN, если бы это было что-то не тривиальное я бы код написал, но если тебе лень в MSDN залезть, то извините...
Иван, я не поленился залезть в спецификацию OLEDB и привести атрибуты, управляющие несколькими сессиями в "одном" подключении MSSQL. Кроме того, мы потестили 2000 и 2005 сервер и опубликовали увиденное. Нет, мне не лень. Но куда лезть-то? У ADO.NET я не припоминаю наличие методов для старта отдельной транзакции.
КД>>Но не в теме, которая вообще говоря касается специфики компонент доступа. IB>Она уже давно касается не этого.
Как модератор, ты должен был предотвратить, а не способствовать этому отклонению
КД>>Да, Иван, здесь в IB/FB тоже пошли немного дальше. IB>В смысле, немного не туда?
Тут вот народ предлагает взять навооружение твои приемы и отвечать в таком же духе. Типа "Ну и что?", "И?", "Данунах" и т.д.
КД>> И ты не поверишь, в OLEDB это тоже прописано. IB>Конечно прописано, потому как это общий драйвер, рассчитаный под самые странные сценарии. А вот в .Net драйверах очень многие вещи намеренно выкинуты.
Да нет, просто курили хорошую траву. Спецификация получилась нормальная. Проще чем для ActiveX-компонент с их километровыми интерфейсами. Но, скажем честно, не для средних мозгов. Ребята граммотно перечислили ну очень много режимов и определили направление развитие. В том числе и MSSQL.
КД>> А MSSQL — минусы. IB>Правильно, так и должно быть. из сиквельных драйверов сознательно и планомерно выкидывают все лишнее. Примечательна еще история с серверными курсорами.
Серверный курсоров у FB никогда не было. Но тем неменее — юзается до сих пор. MSSQL-ем для линкед-серверов. Даже в MSSQL 2005.
Для FB это дело приходится моделировать.
КД>>Её никто не обвиняет. IB>Собственно все началось с твоего наезда на сиквел.
Гы. Да я и щас повторю свой наезд на MS. Только он не на сиквел — я про него явно написал "мне он неинтересен". А на OLEDB.NET.
Разница, полагаю, есть. Если хочешь — могу обосрать ATL.OLEDB. Как ты догадываешься моей квалификации хватит за глаза.
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Здравствуйте, SmlMouse, Вы писали:
SM>В поддержку моих — код.
Каких именно?
SM>Теперь объясни мне, почему так как в коде — делать не правильно.
Я уже раз восемь объяснил.
SM>Ну не знаю. Меня ещё ни разу не банили. А RSDN@Home выдает конкретное сообщение?
Забанят — узнаешь..
SM>>Теперь объясни мне, почему так как в коде — делать не правильно. IB>Я уже раз восемь объяснил.
Ссылку на объяснения в студию.
SM>>Ну не знаю. Меня ещё ни разу не банили. А RSDN@Home выдает конкретное сообщение? IB>Забанят — узнаешь..
Хм. А я думал, у тебя уже есть опыт
--
WBR и ничего личного
... << RSDN@Home 1.2.0 alpha rev. 743>>
Здравствуйте, IB, Вы писали:
AC>>А может ты сперва ознакомишься с тем, что там и как в IB/FB, прежде тем строить эфемерные теории?.. IB>Можно ссылочку на документацию FB, где сказано, что он выполняет мини откаты при RC, и как он это делает?
Иван, IB/FB никогда ничего "втихаря" не делает.
А речь свою веду о том, что ты не знаешь,
какие "подуровни" RC существуют у IB/FB, но при этом
заявляешь, что Oracle поступает правильнеееее
PS: Документация у Кузьменко на сайте (ibase.ru)
PPS: Умиляет твоя безапелляционность.
Здравствуйте, Коваленко Дмитрий, Вы писали:
КД>Иван, я не поленился залезть в спецификацию OLEDB и привести атрибуты, управляющие несколькими сессиями в "одном" подключении MSSQL.
Я ж тебе уже говорил, что OLEDB никакого отношения к MARS не имеет, там вообще другой провайдер.
КД>Но куда лезть-то?
в MARS.
КД>Как модератор, ты должен был предотвратить, а не способствовать этому отклонению
Ой, вот только не надо мне рассказывать про мои обязанности модератора.
КД> Если хочешь — могу обосрать ATL.OLEDB. Как ты догадываешься моей квалификации хватит за глаза.
Только с точки зрения внутренней реализации. Но вот с точки зрения архитектуры клиентских приложений — лучше не надо..
Твои ответы уводят в сторону.
Так как в них нет ни одного аргумента в пользу того, что моё утверждение не верно.
(hint)
— ACID для клиента ни к месту. Не будем же мы в самом деле забирать хлеб у сервера.
— "Транзакции" существуют на сервере. Соотвественно они не видят uncommited изменений друг друга.
— Непротиворечивость данных поддерживает сервер. Он просто не даст что-то сделать криво в рамках реляционной структуры базы данных.
P.S. Не дайте помереть в неведении.
Объясни те же для тупых, чем плоха модель one-connection:many-transactions!!!!!
--
WBR и ничего личного
... << RSDN@Home 1.2.0 alpha rev. 743>>
Здравствуйте, Alex.Che, Вы писали:
AC>Иван, IB/FB никогда ничего "втихаря" не делает.
Кто-то говорил, что FB что-то делает в тихаря?
AC>А речь свою веду о том, что ты не знаешь, какие "подуровни" RC существуют у IB/FB, AC>но при этом заявляешь, что Oracle поступает правильнеееее
Ты опять меня не читаешь? Или искажаешь намеренно?
Я нигде не говорил, что Оракл поступает правильнее, я утверждаю, что у оракла RC строже. Чувствуешь разницу?
AC>PS: Документация у Кузьменко на сайте (ibase.ru)
Так конкретной ссылки не будет? Я вообщем-то так и думал.
AC>PPS: Умиляет твоя безапелляционность.
Меня умиляет ваша безграмотность и наивный троллизм.
Здравствуйте, IB, Вы писали:
КД>> Если хочешь — могу обосрать ATL.OLEDB. Как ты догадываешься моей квалификации хватит за глаза. IB>Только с точки зрения внутренней реализации. Но вот с точки зрения архитектуры клиентских приложений — лучше не надо..
Да я и с конечной, клиентской точки зрения — запросто. Потому что это убожество, рожденное по принципу "шоб було", юзают только последние мазохисты
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Здравствуйте, SmlMouse, Вы писали:
SM>Твои ответы уводят в сторону.
Я не виноват, что ты их не читаешь...
SM>Так как в них нет ни одного аргумента в пользу того, что моё утверждение не верно.
Вних аргументов более чем достаточно.
SM> — ACID для клиента ни к месту. Не будем же мы в самом деле забирать хлеб у сервера.
Тот же вопрос. Ты правда считаешь, что если ACID нарушится на клиенте, то перевод базы из одного состояния в другое станет более согласованным?
SM> — Непротиворечивость данных поддерживает сервер. Он просто не даст что-то сделать криво в рамках реляционной структуры базы данных.
Сервер не даст, а вот на клиенте обойти это можно запросто — чем вы и занимаетесь...
SM> Объясни те же для тупых, чем плоха модель one-connection:many-transactions!!!!!
Для тупых похоже не получается.
Здравствуйте, IB, Вы писали:
AC>>Иван, IB/FB никогда ничего "втихаря" не делает. IB>Кто-то говорил, что FB что-то делает в тихаря?
И снова передёргиваем. Браво.
AC>>А речь свою веду о том, что ты не знаешь, какие "подуровни" RC существуют у IB/FB, AC>>но при этом заявляешь, что Oracle поступает правильнеееее IB>Ты опять меня не читаешь? Или искажаешь намеренно? IB>Я нигде не говорил, что Оракл поступает правильнее, IB>я утверждаю, что у оракла RC строже. Чувствуешь разницу?
Не-а, не чувствую. Насморк у меня (пардону просим).
У Oracle строже по сравнению с чем?
С твоими теориями относительно IB/FB?
AC>>PS: Документация у Кузьменко на сайте (ibase.ru) IB>Так конкретной ссылки не будет? Я вообщем-то так и думал.
А зайти на сайт не пробовал?
Там вверху большими буковками написано ДОКУМЕНТАЦИЯ
AC>>PPS: Умиляет твоя безапелляционность. IB>Меня умиляет ваша безграмотность и наивный троллизм.
Проверено спеллчекером. Ошибок не обнаружено.
Попрошу не возводить на меня напраслину!
Здравствуйте, IB, Вы писали:
SM>> — Непротиворечивость данных поддерживает сервер. Он просто не даст что-то сделать криво в рамках реляционной структуры базы данных. IB>Сервер не даст, а вот на клиенте обойти это можно запросто — чем вы и занимаетесь...
Иван, а через два подключения значит этим заниматься низя...?
А, даже в голову не приходит?
И ты значит отвечаешь за всех программистов "нормальных" серверов? Ты их всех знаешь по-именно?
А все пользователи FB/IB в обязательном порядке делают это?
Иван, это тупик рассуждения...
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Здравствуйте, IB, Вы писали:
IB>Здравствуйте, SmlMouse, Вы писали:
SM>>Твои ответы уводят в сторону. IB>Я не виноват, что ты их не читаешь...
Я их очень внимательно читаю
SM>>Так как в них нет ни одного аргумента в пользу того, что моё утверждение не верно. IB>Вних аргументов более чем достаточно.
Аргуметов, показывающих, что подход one-connection:many-transactions хуже one-connection:one-transaction я не вижу.
Как внимательно не читаю — не вижу
SM>> — ACID для клиента ни к месту. Не будем же мы в самом деле забирать хлеб у сервера. IB>Тот же вопрос. Ты правда считаешь, что если ACID нарушится на клиенте, то перевод базы из одного состояния в другое станет более согласованным?
Ты правда считаешь, что такая ситуация в рамках моего примера не возможна в модели one-connection:one-transaction?
Ещё раз. Серверу-серверово. Клиенту — клиентово. Реализовывать логику сервера на клиенте задача лишняя и неблагодарная.
SM>> — Непротиворечивость данных поддерживает сервер. Он просто не даст что-то сделать криво в рамках реляционной структуры базы данных. IB>Сервер не даст, а вот на клиенте обойти это можно запросто — чем вы и занимаетесь...
SM>> Объясни те же для тупых, чем плоха модель one-connection:many-transactions!!!!! IB>Для тупых похоже не получается.
Значит, сказать нечего.
Жаль
--
WBR и ничего личного
... << RSDN@Home 1.2.0 alpha rev. 743>>
Здравствуйте, mmaxx, Вы писали:
M>Знаю, что тема не нова, но время не стоит на месте...
M>Может, насоветуете альтернативную СУБД: M>* бесплатная; M>* параллельные транзакции; M>* хранимые процедуры, триггеры; M>* защита от юзверя (что раздражает в Firebird — так это божественное всемогущие SYSDBA).
M>Работать будет на клиентской машине, объем данных небольший, сотни Мб. Желательно embedded. M>Ну и чтоб Data Provider для .NET был достойный
Мда. Я вот решил перечитать. Начальное сообщение.
Короче парень, выпей йайду и убей себя об стену. Тебе никто не поможет.
Думаю одна из причин в том что у ADO.NET нет интерфейса для поддержки "параллельных" транзакций. То есть типа это два противоречивых требования.
Но если религия не мешает, можно соорудить свой .NET движок к серверу, который поддерживает несколько транзакций в одном подключении. Полагаю на роль последнего подходит только семейство IB-серверов
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
КД>Мда. Я вот решил перечитать. Начальное сообщение. КД>Короче парень, выпей йайду и убей себя об стену. КД>Тебе никто не поможет. КД>Думаю одна из причин в том что у ADO.NET нет интерфейса для поддержки "параллельных" транзакций. То есть типа это два противоречивых требования. КД>Но если религия не мешает, можно соорудить свой .NET движок к серверу, который поддерживает несколько транзакций в одном подключении. Полагаю на роль последнего подходит только семейство IB-серверов
Ни пойдёть.
Тама есть всемогущий SYSDBA и ещё более всемогущий embeded, которому вообще по большому с высокой колокольни на права пользователей
Так что если базу того (сп*?:%) — то всё — оёк
Пару вариантов решения проблемы:
— взять исходники fb и прикрутить свои параметры в хидеры страниц, что бы стандартными сбоками такая база не подымалась.
— Связаться с Олегом (Лоа) Ивановым, на предмет дятла с возможностью шифрации самой БД.
--
WBR и ничего личного
... << RSDN@Home 1.2.0 alpha rev. 743>>
Здравствуйте, IB, Вы писали:
IB>Ну открой ты MSDN, если бы это было что-то не тривиальное я бы код написал, но если тебе лень в MSDN залезть, то извините...
интересно. когда на ibase.ru посылают — отмаз типа "лень смотреть или лень прямую ссылку искать". А в MSDN
абстрактно посылать — нормально?
Мы уже победили, просто это еще не так заметно...
