Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Хочу услышать мнения знающих людей
|
|||
|---|---|---|---|
|
#18+
Итак: 1. Есть у меня конструкция на Delphi ADOConnection.BeginTrans; try (*) ADOConnection.Execute(<вставка записи в Т1> // на серваке у Т1 есть триггер на вставку ADOConnection.Execute(<Update Т2 таблицы> ADOConnection.Execute(<Update Т3 таблицы> (**) ADOConnection.CommitTrans; except ADOConnection.Rollback; end; В триггере так: SET XACT_ABORT on BEGIN TRANSACTION tran_1 <вставка в Т4 таблицу из deleted> COMMIT TRANSACTION tran_1 Так вот, в этом случае после (*) возникает ошибка "Cannot create new connection because in manual or distribution transaction mode". Зато if <вставка записи в Т1> перенести в (**), то все работает. :-0 ПОЧЕМУ? 2. Почему совокупность запросов, которая по сути дела объединяет содержимое 2-х таблиц: SELECT * INTO ##opa FROM t1 WHERE ... INSERT INTO ##opa FROM t2 WHERE ... SELECT * FROM ##opa работает быстрее (на небольших массивах, на больших одинакого), чем: SELECT * FROM t1 UNION SELECT * FROM t2 :-0 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.12.2001, 06:44 |
|
||
|
Хочу услышать мнения знающих людей
|
|||
|---|---|---|---|
|
#18+
2. Скорее всего дело в том, что вы используете UNION, а не UNION ALL. При простом UNION происходит еще и удаление повторяющихся записей, что конечно требует дополнительного времени. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.12.2001, 07:25 |
|
||
|
Хочу услышать мнения знающих людей
|
|||
|---|---|---|---|
|
#18+
1. А не асинхронное ли выполнение задано? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.12.2001, 08:56 |
|
||
|
Хочу услышать мнения знающих людей
|
|||
|---|---|---|---|
|
#18+
Для Glory: Вы, конечно, правы, но к сожалению это не мой случай. Ради интереса я попробовал сделать как Вы посоветовали, результат тотже. Ж8-( Я вот где-то видел или слышал, но давно, что скорость выполнения операций UNION, INNER JOIN, LEFT JOIN и им подобные в MS SQL Servere на больших массивах работают быстрее, if поменять синтаксис написания запросов. Например: вместо LEFT JOIN пименять в WHERE *=. Никто не встречал какие-либо статьи по этому поводу? Для Глеба if Вы имеете ввиду св-во ConnectOptions, то они у меня выставлено в coConnectUnspecified. Вообще-то проблема эта решена, но фак, как говориться, факом. Кстати, а как может повлиять на выполнение программы асинхронность. Команды-то все равно поступают друг за дружкой или как? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.12.2001, 10:32 |
|
||
|
Хочу услышать мнения знающих людей
|
|||
|---|---|---|---|
|
#18+
1. В зависимости от установленных параметров архивной политики select into может выполняться в транзакции, а может и вне транзакции. Выполнение вне транзакции происходит гораздо быстрее. Правда, такая операция не находит отражения в журнале транзакций, и при восстановлении архивной копии журнала транзакций можно просто потерыть результаты, полученные данной командой. 2. union вне всяких сомнений работает медленнее, недели union all. В этом я согласен с Glory. 3. По поводу Connection - Глеб Уфимцев высказал наиболее вероятное предположение. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.12.2001, 10:46 |
|
||
|
|

start [/forum/topic.php?fid=46&msg=32018932&tid=1824627]: |
0ms |
get settings: |
7ms |
get forum list: |
10ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
79ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
34ms |
get tp. blocked users: |
1ms |
| others: | 238ms |
| total: | 386ms |

| 0 / 0 |
