subject:"Re\: Немного флейма. Транзакции"



Alexey Popov пишет:



Serge Buzadzhy wrote:

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


Надо просто бросать исключение при попытке последующего фетча закрытого 
датасета.


И что это дает? На этапе разработки ты на это исключение можешь и не 
нарваться.

Re: Немного флейма. Транзакции



Hello, Serge!

Serge Buzadzhy wrote:


БДЕ по моему дофетчивало втихую.


когда как.
www.ibase.ru/devinfo/bde.htm

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


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

--
Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34

Re: Немного флейма. Транзакции



Alexey Popov пишет:



Serge Buzadzhy wrote:

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


Надо просто бросать исключение при попытке последующего фетча закрытого 
датасета.




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

предлагаются.

Re: Немного флейма. Транзакции

2007-09-20 Пенетрантность Alexander A. Venikov

Serge Buzadzhy ...

Vlad Khorsun пишет:

Dmitri Kuzmenko ...

тут ведь еще есть вот какой момент. Любовь к параллельным транзакциям
пошла из-за того, что BDE

БДЕ по моему дофетчивало втихую.

Угу. Но БДЕ писалось во времена, когда клиент-сервер только начинал входить
в массы и толком было не понятно как с ним работать. Т.е. теоритически все всё
знали
и понимали, а вот практических навыков (по крайней мере в Б) не было.

а потом и FreeIBComponents, и IBX/FIBPlus

убивают кэш в датасетах,

т.е. закрывают запросы.
Ну... запрос закрыть это один вопрос. Второй вопрос это кэш в датасетах. Запрос закрыть необходимо. Он просто перестает быть
валидным при закрытии транзакции в рамках которой был открыт. Что собственно и понятно.

А при чём тут мои локальные, с таким трудом отфетченные, данные ?

Знать бы ещё - нафига они это делают...

Наша песня хороша - начинай сначала :) Обсуждали ужо.

Значит я пропустил тот раз ;)

Хочешь - обсудм еще раз.

Как скажешь ;) Скажу сразу - это камень не в твой огород, а скорее в огород
Грегори

Недофетченный запрос, чего с ним делать при закрытии транзакции?

А что - надо что-то делать ?

Дофетчивать втихаря перед закрытием? Нехорошо. Оставлять недофетченным тоже
плохо.

Чем ? Тем что бедненький кодер испугается ошибки, которую выдаст
злобный сервер при попытке фетча из закрытого курсора ? Ай, как его жалко

Оба варианта плохи еще тем что девелопер вообще может не заметить, что что-то
делается без его ведома.

А вот не надо ничего делать без его ведома. Не надо. Это так просто :)

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

Конечно - мы же лучше знаем, что девелоперу нужно на самом деле...

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

ЗЫ. Кстати в FIBPlus ( а может и в ИБХ) если датасет в режиме CachedUpdates то при закрытии транзакции, датасет все-таки не
закрывается, а дофетчивается.

Меня это всё не волнует лет этак 8-9 - с тех пор как я пользую CDS и не имею
проблем с нижележащими уровнями вообще :)

--
Хорсун Влад

Re: Немного флейма. Транзакции



Hello, Alexey!
You wrote  on Wed, 19 Sep 2007 12:40:13 +0400:

 1. В чем именно удобство стартовать много транзакций в одном соединении?
AP Удобно при работе с многими формами. В каждой форме своя
AP транзакция и они совершенно изолированы друг от друга.
AP В противном случае надо как то извращаться что бы работа
AP в разных формах/модулях не противоречила друг другу.
Ты немного не понял. С этой точки зрения ничто не мешает использовать в каждой 
форме отдельное подключение. Почему это плохо - уже ответили.

--
Удач
Alexander A. Venikov, Tobolsk, Russia

Re: Немного флейма. Транзакции

2007-09-20 Пенетрантность Alexey Popov



Serge Buzadzhy wrote:

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

предлагаются.


Почему случайным? Где стабильная реакция? Сейчас запрос просто закрывается,
что само по себе тихо, незаметно и может привести с странным глюкам.
При выбросе исключения автоматически выскочит мессадж бокс с точной 
причиной. Юзер сразу отпинает девелопера без всяких стуков в подвале.




--
--- Home Page http://ok.novgorod.net/ap ---

Re: Немного флейма. Транзакции

2007-09-20 Пенетрантность Alex Cherednichenko


Привет, Vlad!
Вы пишешь  20 сентября 2007:

[Sorry, skipped] 
 VK А вот не надо ничего делать без его ведома. Не надо. Это так просто :)

Аааа!!
Ты знал!!!
Ты знал :)))

-- 
With best regards, Alex Cherednichenko.

Re: Немного флейма. Транзакции



Vlad Khorsun wrote:


   Меня это всё не волнует лет этак 8-9 - с тех пор как я пользую CDS и 
не имею

проблем с нижележащими уровнями вообще :)


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


--
Regards. Ded.

Re: Немного флейма. Транзакции

Alexey Popov пишет:

Serge Buzadzhy wrote:

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

предлагаются.

Почему случайным?
Потому что возникновение предполагаемого эксепшна зависит от случайных
факторов.

1. Много или мало записей в запросе (это для одного и того же запроса
меняется во времени)

2. Успел юзер отфетчить записи или нет до того как кто-то вызвал коммит.

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

Где стабильная реакция? Сейчас запрос просто закрывается,

Стабильно закрывается.

что само по себе тихо, незаметно и может привести с странным глюкам.

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

Re: Немного флейма. Транзакции

Ded ...

Vlad Khorsun wrote:

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

Может у мну (с) крынка резиновая, но никогда на это не напарывался.
Может я не тяну сотни тысяч на клиента (отчёты делаются другими ср-вами) ?
Единицы и, возможно, десятки тысяч пролетают без заметных проблем (редко,
но иногда бывает и такое). Это при том, что есть и более быстрые in-memory
таблицы, чем CDS. Да и менее глючные тоже, надеюсь, есть :)

парцайками тягать муторно. Правда меня это тоже отродясь не волновало, ибо с малолетства разделял пишущие и читающие транзакции.
Лично мне

У меня это тоже две разные тр-ции. Но только для того, чтобы дать им
(возможно)
разный набор параметров, а не для обхода проблемы закрытия датасетов.

текущее поведение внучков Грегори представляется более логичным и простым в использовании чорным ящиком, нежели борьба с
недофетченными курсорами, невалидными дбкеями и, пожалуй, для человека неискушённого, отсутствием конфликтов модификации там, где
они должны быть. Может, конечно, дело привычки...

Поведение _может_ быть настраиваемым, но не _должно_ быть железобетонно-
непробиваемым в стиле : ты туда не ходи, ты сюда ходи... и только сюда

Я, с точки зрения пользователя компонент, не вижу ничего логичного и
простого в
закрытии всех датасетов по окончании тр-ции. Наооброт - это приводит в
недоумение
и заставляет _бороться_ с компонентами\сервером вместо решения моих собственных
прикладных задач.

--
Хорсун Влад

Re: Немного флейма. Транзакции

Vlad Khorsun пишет:

а потом и FreeIBComponents, и IBX/FIBPlus

убивают кэш в датасетах,

т.е. закрывают запросы.
Ну... запрос закрыть это один вопрос. Второй вопрос это кэш в
датасетах. Запрос закрыть необходимо. Он просто перестает быть
валидным при закрытии транзакции в рамках которой был открыт. Что
собственно и понятно.

А при чём тут мои локальные, с таким трудом отфетченные, данные ?

Дык включаем CachedUpdates и можем вообще коннект обрубить не то что
транзакцию закрыть. :) С трудом отфетченные данные остаются на месте.

Хочешь - обсудм еще раз.

Как скажешь ;) Скажу сразу - это камень не в твой огород, а скорее в
огород

Грегори

Мой огород давно не боится камней. :)

Недофетченный запрос, чего с ним делать при закрытии транзакции?

А что - надо что-то делать ?

Дофетчивать втихаря перед закрытием? Нехорошо. Оставлять недофетченным
тоже плохо.

Мне больше жалко не его, а себя обычно. :)

Оба варианта плохи еще тем что девелопер вообще может не заметить, что
что-то делается без его ведома.

А вот не надо ничего делать без его ведома. Не надо. Это так просто :)
Это идеал. Недостижимый. Но по крайней мере если что-то делаешь без его
ведома, нужно чтоб он сразу же видел что произошло и собственно понял
причину по которой это произошло. Закрыть кэш - это как раз из этой
серии. Сразу же и всегда видно, причина выясняется немедленно.

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

Конечно - мы же лучше знаем, что девелоперу нужно на самом деле...

Девелоперу нужно чтоб он мог реализовать свои собственные извращения и
ему хватало для этого средств.

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

и навязанной множеству
кодеров, которые просто слепо верят в инструмент и не задумываются
причинах.

ЗЫ. Кстати в FIBPlus ( а может и в ИБХ) если датасет в режиме
CachedUpdates то при закрытии транзакции, датасет все-таки не
закрывается, а дофетчивается.

Меня это всё не волнует лет этак 8-9 - с тех пор как я пользую CDS и
не имею

проблем с нижележащими уровнями вообще :)

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

Удачи

Re: Немного флейма. Транзакции




Я про себя скажу просто. Что бы я не делал в этой ситуации - меня все равно 
будут бить.  :)


   Я знал, что ты знал :)

Или за то что закрываю кэш, или за то что вдруг эксепшны выскакивают, или что дофетчиваю или что не дофетчиваю. Собственно разницы 
никакой, бить все равно будут, не одни так другие. :)


   Согласен...

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


   ...потому и не предлагаю ничего менять или устраивать революции :)
Просто тема навеяла :)

   И я так и не узнал - нафига Грег сбрил, тьфу, закрыл датасеты ;)

--
Хорсун Влад

Re: Немного флейма. Транзакции

Vlad Khorsun wrote:

Десятки тысяч не проблема. У меня в филиальской briefcase справочной
подсистеме десятками и тягается. С тех пор, как наладил репликацию
изменией в базовых справочниках и сборку визуализации на месте из
засасываемых оперативных числовых данных и названий в локальной базе,
вполне шустренько так летает. А вот спервоначалу, когда отправлял туда
резалтсет джойна из центра, в какой-нить Тюмени на модеме минут 40 могло
грузиться. То есть, к работе с кеширующими фулл фетч датасетами в общем
случае надо технологически подходить не как к клиент-серверу. А это не
всегда хорошо. Про работу с миллионными архивами, которые в
клиент-сервере до конца вообще практически никогда не дофетчиваются, я
уж молчу. И никаких специальных приседаний с IBX/FIBPlus для этого не
надо, технология на это и заточена. Наоборот, надо приседать, когда
нужны отступления от этой технологии. Мы с тобой приседаем при помощи
CDS, а Серж строит настраиваемые гибриды с локальными
сортировками-фильтрациями. Мне кажется, что правильней иметь и молоток и
гвоздодёр отдельно и хвататься за то, что нужно в конкретный момент.

парцайками тягать муторно. Правда меня это тоже отродясь не волновало,
ибо с малолетства разделял пишущие и читающие транзакции. Лично мне

У меня это тоже две разные тр-ции. Но только для того, чтобы дать им
(возможно)

разный набор параметров, а не для обхода проблемы закрытия датасетов.

У меня этой проблемы вообще никогда не было. Основное чтение в
единой транзакции по умолчанию r_c read, открывающейся на запуске
приложения и закрывающейся на выгрузке, запись в коротких по месту
снапшотах, с прдварительным рефрешем в них именно модифицируемых данных,
если нужно. И фсё.

текущее поведение внучков Грегори представляется более логичным и
простым в использовании чорным ящиком, нежели борьба с недофетченными
курсорами, невалидными дбкеями и, пожалуй, для человека неискушённого,
отсутствием конфликтов модификации там, где они должны быть. Может,
конечно, дело привычки...

См. выше про молоток и гвоздодёр :)

прикладных задач.

Не вижу в упор борьбы, если разделять транзакции. И Серж в плюсах это
сделал, и Алекс для нас в IBX, причём ещё более радикально, можем на
каждый ...SQL отдельную закатать. А раньше мы просто не пользовались
технологией Edit-Post, а выполняли модификации автономными запросами. Да
и сейчас преимущественно так.

--
Regards. Ded.

Re: Немного флейма. Транзакции

Ded ...

Vlad Khorsun wrote:

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

И никаких специальных приседаний с IBX/FIBPlus для этого не надо, технология на это и заточена. Наоборот, надо приседать, когда
нужны отступления от этой технологии. Мы с тобой приседаем при помощи CDS, а Серж строит настраиваемые гибриды с локальными
сортировками-фильтрациями. Мне кажется, что правильней иметь и молоток и гвоздодёр отдельно и хвататься за то, что нужно в
конкретный момент.

Конечно. Но, согласись, я _сам_ должен выбирать чем гвозди заколачивать,
а чем - выдирать.

У меня этой проблемы вообще никогда не было.

А я не про тебя это написал :)

В обчем - все позиции всех всем давно известны, копья давно сломаны,
говорить тут не о чем :)

--
Хорсун Влад

Re: Немного флейма. Транзакции

2007-09-20 Пенетрантность Kovalenko Dmitry



Vlad Khorsun wrote:


   В обчем - все позиции всех всем давно известны, копья давно сломаны,
говорить тут не о чем :)


   Ну воооттт... А по314деть? :-(

--
Regards. Ded/

Re: Немного флейма. Транзакции

 В обчем - все позиции всех всем давно известны, копья давно сломаны,
  говорить тут не о чем :)

 Ну воооттт... А по314деть? :-(

по314деть?

Бл#, я не понимаю, как можно быть модератором такого авторитетного
ресурса как RSDN и так тупить!!!

Сказать что я расстроен, это бл# вообще ничего не сказать.

Коваленко Дмитрий.

Re: Немного флейма. Транзакции

2007-09-20 Пенетрантность Kovalenko Dmitry

 Бл#, я не понимаю, как можно быть модератором такого авторитетного
 ресурса как RSDN и так тупить!!!

Бл#. Уверен, он делает класс ради одного объекта с одним методом с
единственным return-ом. Потому что процедурное программирование уже не
модно, а объектное - не асилил. И обращается к нему через глобальный
указатель.

А когда MS разродится вещами о которых ему там целых два дня
вталкивали, не сумеет увязать вчера и сегодня. Про завтра, я
вообще молчу.

Коваленко Дмитрий.

Re: Немного флейма. Транзакции



Kovalenko Dmitry ...

В обчем - все позиции всех всем давно известны, копья давно сломаны,
 говорить тут не о чем :)

Ну воооттт... А по314деть? :-(


по314деть?

Бл#, я не понимаю, как можно быть модератором такого авторитетного
ресурса как RSDN и так тупить!!!


   В каком месте оно авторитетное ? Уж не в СУБД точно :)))

--
Хорсун Влад

Re: Немного флейма. Транзакции



Hello, Vlad!

Vlad Khorsun wrote:

   Угу. Но БДЕ писалось во времена, когда клиент-сервер только начинал 
входить
в массы и толком было не понятно как с ним работать. Т.е. теоритически 
все всё знали

и понимали, а вот практических навыков (по крайней мере в Б) не было.


я позволю себе восстановить историческую справедливость.
В те давние времена Б, Н и еще кто-то создали архитектуру
IDAPI. М для себя сделал ODBC. IDAPI был лучше, но закрыт.
А ODBC был глюкавый, но простой и открыт.
Так ODBC победил IDAPI.

А чего было наверчено в BDE, было более-менее оптимально
по тем временам именно как универсальное решение.

--
Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34

Re: Немного флейма. Транзакции

Dmitri Kuzmenko ...

Hello, Vlad!

Vlad Khorsun wrote:

я позволю себе восстановить историческую справедливость.

Я в курсе этого, но

В те давние времена Б, Н и еще кто-то создали архитектуру
IDAPI. М для себя сделал ODBC. IDAPI был лучше, но закрыт.

Не факт, что он был лучше для _клиент-сервера_

А ODBC был глюкавый, но простой и открыт.
Так ODBC победил IDAPI.

М, между прочим, в то время был далеко не так силён и богат, а вот
Б была на подъёме. Но с плохим пищеварением

А чего было наверчено в BDE, было более-менее оптимально
по тем временам именно как универсальное решение.

Оптимально для _клиент-сервера_ ? Ох, не уверен... Но ОДБЦ
тогдашний тоже был не фонтан...

--
Хорсун Влад

Re: Немного флейма. Транзакции

2007-09-20 Пенетрантность Alex Cherednichenko



Kovalenko Dmitry wrote:

RSDN 


   Ля, и когда вы всё успеваете, да ещё и работать...

--
Regards. Ded.

Re: Немного флейма. Транзакции


Привет, Dmitri!
Вы пишешь  20 сентября 2007:

[Sorry, skipped] 
 DK В те давние времена Б, Н и еще кто-то создали архитектуру
 DK IDAPI. М для себя сделал ODBC. IDAPI был лучше, но закрыт.
 DK А ODBC был глюкавый, но простой и открыт.
 DK Так ODBC победил IDAPI.

Вообще-то, спецификация ODBC базируется на CLI (Call Level Interface),
который был _изначально_ ориентирован на SQL-based DBMS
История мутная и с истинными прародителями не всё ясно.
http://en.wikipedia.org/wiki/Call_Level_Interface
И кто у кого кораллы закларил, тоже не совсем понятно...

-- 
With best regards, Alex Cherednichenko.

Re: Немного флейма. Транзакции

2007-09-20 Пенетрантность Kovalenko Dmitry

 Форум по плюсам, там - я вздрагиваю. В базах данных тоже думал что
 вроде ничего. Но за последние два дня - ниже плинтуса.

Я вот смотрю на ответы Ивана. Там в каждом сообщении слова -
напрягаться, сложно, устал, тупо ...

Однако,тяжела работа у программиста MSSQL. Изматывает и отупляет :))

Коваленко Дмитрий.

Re: Немного флейма. Транзакции

Kovalenko Dmitry ...

Я вот смотрю на ответы Ивана. Там в каждом сообщении слова -
напрягаться, сложно, устал, тупо ...

Он не понимает, что

а) в IB\FB нет implicit тр-ций, т.е. тр-циями управляет _только_ клиент

в MSSQL это не так и можно увидеть тысячи строк кода как клиентского, так
и серверного (процедуры) без BEGIN TRAN. В процедурах, кстати, управление
тр-циями разрешено и обычно там его и делают (если делают)

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

в) 1-я тр-ция видит изменения 2-ой, т.к. она read-committed, а не по другой
причине

--
Хорсун Влад

Re: Немного флейма. Транзакции



Hello, Vlad!

Vlad Khorsun wrote:


IDAPI. М для себя сделал ODBC. IDAPI был лучше, но закрыт.


   Не факт, что он был лучше для _клиент-сервера_


не спорю.


   М, между прочим, в то время был далеко не так силён и богат, а вот
Б была на подъёме. Но с плохим пищеварением


да эта шайка-лейка вообще ведь развалилась. Кто там был
кроме Б и Н - сейчас уже не помню.

--
Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34

Re: Немного флейма. Транзакции

2007-09-19 Пенетрантность Константин



Hello, Alex!

Alex Cherednichenko wrote:


Вообще-то, спецификация ODBC базируется на CLI (Call Level Interface),
который был _изначально_ ориентирован на SQL-based DBMS
История мутная и с истинными прародителями не всё ясно.
http://en.wikipedia.org/wiki/Call_Level_Interface
И кто у кого кораллы закларил, тоже не совсем понятно...


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

--
Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34

Re: Немного флейма. Транзакции


MR 2. Чем режим 1 соединение - 2 транзакции отличаеться от режима 2
MR соединения в каждом по транзакции.

 А затраты на создание 2-го подключения ?

С уважением,
Константин Григорьевич.
===

Re: Немного флейма. Транзакции

2007-09-19 Пенетрантность Vlad Khorsun




Собственно вопросов 2 :)
1. В чем именно удобство стартовать много транзакций в одном соединении?
2. Чем режим 1 соединение - 2 транзакции отличаеться от режима 2
соединения в каждом по транзакции.


   А ты попробуй использовать, например, временную таблицу (ON COMMIT PRESERVE
ROWS), из разных коннектов. В общем - любые данные уровня сессии (вспомним 
пакеты
в том же Оракле)

--
Хорсун Влад

Re: Немного флейма. Транзакции

2007-09-19 Пенетрантность Alexey Popov



Max Rezanov wrote:


1. В чем именно удобство стартовать много транзакций в одном соединении?


Удобно при работе с многими формами. В каждой форме своя транзакция
и они совершенно изолированы друг от друга. В противном случае надо
как то извращаться что бы работа в разных формах/модулях
не противоречила друг другу.


--
--- Home Page http://ok.novgorod.net/ap ---

Re: Немного флейма. Транзакции

Наткунался щас на пост на рсдне по поводу невозможности в FB ADO.NET
провайдере юзать несколько транзакций. Хотя похожий вопрос и тут уже
возникал.
p/s/
Возможно ноги растуть из лицензий еще на IB но насколько я помню в 5.6
на одну лицензию допускалось пять коннектов.

Макс, ты же вроде не первый год замужем. Ноги растут из другого места.

И вот этим самым местом и были придуманы вещи весьма сомнительной
ценности, однако, с помощью граммотной маркентиговой политики,
возведенные в ранг истины в последней инстанции.

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

Вот только дети, которые с радостью едят то, что им суют в рот, про
это не догадываются.

Коваленко Дмитрий.

PS. Я помню сильно позабавил Диму Еманова, моей уверенностью что
останется только один, и этот один будет - Firebird :)))

Re: Немного флейма. Транзакции

2007-09-19 Пенетрантность Alex Cherednichenko

   Наткунался щас на пост на рсдне по поводу невозможности в FB ADO.NET

Такой аблом Вот только я гвоздик под шкуру очередного барана в
стену забил, как злой модератор почистил все ветки.

Коваленко Дмитрий.

Re: Немного флейма. Транзакции


Привет, Kovalenko!
Вы пишешь  19 сентября 2007:

 KD Такой аблом Вот только я гвоздик под шкуру очередного барана в
 KD стену забил, как злой модератор почистил все ветки.

Гы-гы-гы  :)
Иван всё ещё простить не может того, 
как его мокали носом в блюдце, по поводу MGA.
Свято оберегает свой заповедник...

-- 
With best regards, Alex Cherednichenko.

Re: Немного флейма. Транзакции

  KD Такой аблом Вот только я гвоздик под шкуру очередного барана в
  KD стену забил, как злой модератор почистил все ветки.

 Гы-гы-гы  :)
 Иван всё ещё простить не может того,
 как его мокали носом в блюдце, по поводу MGA.
 Свято оберегает свой заповедник...

Может написать ему за это - Иван, ты #%@ ! ?

Такого развлечения лишил.

Требую чтобы этот неверный отказался от ника IB!

Коваленко Дмитрий.

Re: Немного флейма. Транзакции

2007-09-19 Пенетрантность Vlad Khorsun



Alex Cherednichenko ...


Иван всё ещё простить не может того,
как его мокали носом в блюдце, по поводу MGA.
Свято оберегает свой заповедник...


   Надеюсь до него дошло, что MARS'у до нескольких тр-ций в одном коннекте
как... как... как до Марса пешком ? ;)

--
Хорсун Влад

Re: Немного флейма. Транзакции

Иван всё ещё простить не может того,
как его мокали носом в блюдце, по поводу MGA.
Свято оберегает свой заповедник...

Надеюсь до него дошло, что MARS'у до нескольких тр-ций в одном коннекте
как... как... как до Марса пешком ? ;)

Ваня наступил на эти грабли?

Эко как ... :shuffle:

Тогда понятно, почему он затер мой пост, в котором я начал стебаться
над неким kuj...

Кстати, мне там IB (он долго думал, наверное) написал, что транзакции
в MARS'e будут разные - я в 2005 не копенгаген, но думаю что что-то
тут не то. Хотя...

---
Whereas OLEDB used to disallow the implicit spawning of connections
whenever a transaction was active in the session, and ODBC used to
fail additional requests with the connection busy error, in the MARS-
enabled world these combinations now succeed. If the session has a
transaction active, all new requests run under the specified
transaction; if the session has no transaction active, each batch runs
in auto commit mode, implying that each statement executed runs under
its own transaction.
---

И неужто для этих own transaction отдельное подключение не
создается? :))

Коваленко Дмитрий.

Re: Немного флейма. Транзакции