Здравствуйте, IB, Вы писали:

КД>>Не перегибай палку
IB>Я вообще с палками не очень...

КД>>Блин, я вот не могу понять — в чем именно проявлется усложнение?
IB>Может ты просто по другому не пробовал?

Ну я может не пробовал. Точнее, я таким нюансам никогда внимание не придавал. Как удобно в конкретной задаче, так и делал. Однако разбирался с кодом клиентов IBProvider-a, ваявших для COM+, где именно так и делается. Ну дык там и подход и мышление другое. И есть скрытое глобальное место, где таки хранятся готовые подключения. Называется пулом. Пулом подключений. Не можно, конечно, без пула — да ради бога — указываем "OLE DB Services=0" и вперед к тормозам

КД>>IB, ни кто не заставляет обязательно делать многопоточное приложение.
IB>Расскажи ка мне, как ты собираешься работать с параллельными транзакциями из одного подключения в однопоточном приложении?
IB>Приостанавливать действие одной транзакции и запускать из того же потока другую? Вот уж действительно редкое извращение.

Мдаа... Берем тривиальную задачу — запись логического лога в базу данных. Объект, который это делает, должен гарантировано записать в базу что там пользователь пытался делать. Не зависимо от того — откатилась основная транзакция или нет. Ведь если это делать в основной транзакции, и она откатится, то записи протокола тоже откатятся. Поэтому у этого протоколирующего объекта должна быть собственная (короткая) транзакция.

Если тебе лень или ты принципиально не хочешь связываться с многопоточным приложением — то ради бога, держи эти две транзакции в одном потоке.

... Заявления что паралельные транзакции имееют смысл только в раздельных потоках очень похоже на требование работы с разными файлами исключительно в разных потоках. И реакция "С какого перепугу" — вполне подходит и к транзакциям.

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

КД>>И что же там делается?
IB>Где?

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

КД>>Тестили через OLEDB. Новая параллельная транзакция порождает НОВОЕ подключение И на 2000 и на 2005
IB>MARS не поддерживается OLEDB, только .Net провайдером.

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

КД>>Но практикующие ведущие собаководы иногда предлагают создавать по требованию именно транзакции. Понимаешь?
IB>И в чем проблема?

Не в чем, а в ком. Ты сказал

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

Я тебе ответил — никто тебе не навязывает число транзакций на одно подключение. И это есть хорошо.

КД>>Кроме того, сейчас, на сколько я понимаю, с появлением временных таблиц действующих на уровне соединения, весьма актульно что бы "параллельные" транзакции действительно оставались в рамках одного подключения. Потому что иначе — новая "параллельная" транзакция просто не увидит эту таблицу.
IB>А должна видеть? Скажем, в идеологии сиквела другая транзакция не должна видеть временные данные другой, думаю понятно почему.

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

IB>А вот зачем делать так чтобы временные данные можно было видеть — не понятно.

Иван, с тобой тяжко общаться... Понимаешь, Firebird это сервер для людей у которых как-то более продвинутая способность к восприятию мира и они не возможности сервера натягивают на предметную область, а наоборот (Лично мне всегда было на...ть на каноны баз данных). То есть проектируют так как представляют, а не так как им позволяют возможности сервера — им глубоко по-барабану технические нюансы RDBMS. И сервер создавался и развивается именно в том направлении, что бы удовлетворять этим вещам. Мда, спасибо Джиму.

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

Но пока, та модель БД которая 5 лет и 4 дня, работает в нашей Липецкой недвижимости, не сможет в чистом виде работать ни на Оракле, ни на MSSQL. А только на IB-подобном сервере