Проблема с запросом

← →
VadimSpb (2006-08-16 19:58) [0]

Добрый день!
Выполняю следующий запрос в программе обновления БД:
if tb_Name.IndexOf("Addresses")<>-1 then // Читаем список названий полей ElementConnection.GetFieldNames("Addresses",pl_Name); if pl_Name.IndexOf("PostIndexID")=-1 then begin // Создаем поле PostIndexID ADOCommand.CommandText := "ALTER TABLE Addresses ADD PostIndexID int"; ADOCommand.Execute; ADOCommand.CommandText := "UPDATE Addresses SET PostIndexID=1"; ADOCommand.Execute; end;
Иногда получается интересный результат: поле создается, а заполняется 1 только 80-90% всех записей !
Иногда все отрабатывает нормально. В чем м.б. причина?

← →
Val © (2006-08-16 20:18) [1]

успевают добавить новые записи после апдейта и до проверки?

← →
VadimSpb (2006-08-16 20:21) [2]

Если нового поля нет, создаем его и заполняем 1.
В результате иногда наблюдаю NULL в новом поле примерно на 10-20% записей.

← →
User_Name (2006-08-16 20:34) [3]

Если в программе действительно такой код, то почему не сделать

ALTER TABLE Addresses ADD PostIndexID int DEFAULT 1

← →
VadimSpb (2006-08-16 20:39) [4]

Согласен. Исторические корни :))
Все равно должно работать. Следом еще идут запросы, как они выполняются на сервере: строго последовательно?

← →
VadimSpb (2006-08-16 20:46) [5]

> ALTER TABLE Addresses ADD PostIndexID int DEFAULT 1

В моей задаче не прокатит.
DEFAULT определяет значение по умолчанию для столбца если пропущено значение при добавлении строки.
У меня добавляется столбец и необходимо всем существующим строкам дать значение 1

← →
User_Name (2006-08-16 20:52) [6]

Работать то возможно и должно :). ИМХО надо отрабатывать результат завершения таких операций.
А насчет запросов - представить трудно, что было бы с сотней активно работающих пользователей если бы "строго последовательно"

← →
VadimSpb (2006-08-16 20:54) [7]

> надо отрабатывать результат завершения таких операций.

Поподробнее можно?

← →
User_Name (2006-08-16 20:56) [8]

Вообще, то я бы вынес всю эту байду в отдельную ХП.
Естессно ИМХО.

← →
User_Name (2006-08-16 20:59) [9]

2 VadimSpb (16.08.06 20:54) [7]
Поиск по этому форуму рулит (должен) :)

← →
Val © (2006-08-17 10:43) [10]

>[8] User_Name (16.08.06 20:56)
вот...зачем?

← →
Val © (2006-08-17 10:47) [11]

>[2] VadimSpb (16.08.06 20:21)
я понимаю, что вы пытаетесь сделать.
я говорю о том, что возможно, после того, как вы сделали апдейт таблицы, пользователи успевают добавить новые записи, где это поле не заполнено.
вы проверяете таблицу и удивляетесь...
все-таки ответьте - во время обновления БД у вас к ней монопольный доступ?

← →
Desdechado © (2006-08-17 11:19) [12]

> я бы вынес всю эту байду в отдельную ХП.
А что, в ХП можно менять метаданные?!

> Иногда получается интересный результат
Триггеры активны? Что в них? Может, они препятствуют обновлению, не вызывая исключений.

← →
VadimSpb (2006-08-17 11:21) [13]

> Вообще, то я бы вынес всю эту байду в отдельную ХП.

Зачем держать в БД процедуру, которая д.б. выполнена только один раз?
ИМХО, это решение из области философии :-))

> во время обновления БД у вас к ней монопольный доступ?

Все производится локально. Больше с БД никто не работает.
В базе более 10000 записей, новые не добавляются.

← →
VadimSpb (2006-08-17 11:25) [14]

> Desdechado © (17.08.06 11:19) [12]

Проблема основная в том, что нет закономерности. В большинстве случаев все отрабатывает как надо, без ошибок.

← →
Val © (2006-08-17 11:29) [15]

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

← →
VadimSpb (2006-08-17 11:51) [16]

> Val © (17.08.06 11:29) [15]

В этой таблице триггеров нет.

← →
Val © (2006-08-17 12:08) [17]

тогда в коде :
1. явный старт транзакции
2. апдейт
3. коммит, при исключении - роллбэк.

← →
User_Name (2006-08-17 13:20) [18]

2 Desdechado © (17.08.06 11:19) [12]
То, что он хочет МОЖНО сделать через ХП

... (Кусок реально работающей ХП. Влом было переписывать под даннный случай :) )
EXEC("ALTER TABLE "+@TempTableName+" ADD " + @FiledName + " Int DEFAULT 1")
SELECT @SQL="UPDATE "+@TempTableName + " SET " + @FiledName + "=1 "
EXEC(@SQL)
...
Какие проблемы ???

← →
VadimSpb (2006-08-17 13:31) [19]

> Val © (17.08.06 12:08) [17]

Согласен, так и надо делать. Обновление влияет на целостность данных и при ошибках лучше делать откат с выдачей сообщения.
Всем спасибо!

← →
Desdechado © (2006-08-17 13:34) [20]

> МОЖНО сделать через ХП
но НЕ нужно!
Надобность менять метаданные возникает редко. Менять их через такую задницу у меня возникала 2 раза и по моей же вине, когда было:
- либо лень писать длинный скрипт, проще было сделать цикл по системной вьюхе
- либо надо было написать общий случай для заранее неизвестных системных имен индексов

← →
User_Name (2006-08-17 13:56) [21]

Ну да, а писать в клиенте тоже самое видимо нормально. Н-да уж.

такое пишется не в клиенте, а в специальных утилитах обслуживания (патчах, например)
либо, при особой лени, выполняется в виде скрипта во встроенных в СУБД сприптогонялках

> [20] Desdechado © (17.08.06 13:34)
> - либо лень писать длинный скрипт, проще было сделать цикл
> по системной вьюхе

Я обычно из нее получаю имена, кидаю в Excel, там формирую наглядно скрипт и копирую в скриптодвижок. Мне так проще

← →
User_Name (2006-08-17 14:56) [24]

2 Desdechado © (17.08.06 14:13) [22]

Вот - вот проходил (и к сожалению прохожу сейчас). Патч где-то под метр, который выполняет пару тривиальных команд, которые проще скриптом сделать, потом оказывается, что он что-то делает не то, и приходится качать второй патч ....

Патч - понятие растяжимое. И руки у всех разные.
Если патч сделать:
1. кумулятивным, т.е. включающим всю последовательность изменений от начала времен
2. интеллектуальным, т.е. он сам определяет текущее состояние и необходимость апдейта
3. со встроенной скриптогонялкой, т.е. не использующим внешние средства и не насилующим пользователя
то все выполняется легко, быстро и всегда актуален в единственном числе.

← →
User_Name (2006-08-17 19:09) [26]

2 Desdechado © (17.08.06 18:12) [25]

Скажу еще раз свое ИМХО (не более того), как пользователь, который использует ту хрень, которую пишут разработчики (уже 12 лет).
Я привел ранее огрызок ПРАВИЛЬНОГО скрипта, где можно задавать имя таблицы, поля (в оригинале еще тип и значения) и т.п.
Это ИМХО правильных подход. В таком случае мне спускают не тот самый кумулятивный, интеллектуальный и т.п. патч. а скрипт типа
exec ....

И это правильно.

Все вышесказанное естессно ИМХО.

мое имхо:
Если пользователю дать скрипт, то, согласно законам Мерфи (подтверждающимися моим 10-летним опытом), они его запустят не так, не тогда или не в том порядке.
Доведение до юзера патча в виде EXE с одной кнопкой самая, имхо, разумная затея, если не хочешь сидетьпотом с каждым индивидуально и разгребать гигабайтовые БД, порченые кривыми руками пользователей.
Они, как водится, сначала что-то делают, а потом думают.
Так что если у вас 1-2 юзера, ваш подход имеет право на жизнь. Но когда их многие сотни-тысячи по всему миру, я вас пожалею...

← →
User_Name (2006-08-17 19:45) [28]

2 Desdechado © (17.08.06 19:15) [27]
Да-да конечно, тот самый админ (мы же про MSSQL говорим) который сидит ниже по умолчанию не сможет запустить скрипт и т.д и т.п. проходили уже тоже, а тот недоучившийся студент (разрабюотчик ..........) который пишет подобные (пример) скрипты
..
elsif substr(p_account_no,1,4) in ("3400")
then
return "7";
..
и запихивающий это в ехе даже не может понять что там не только 7 должно быть, а потом месячная отчетность падает

И юзеров у меня гораздо брльше чем 1-2 :)
И база в 26 Гиг (не много но все-таки)

> недоучившийся студент (разработчик) даже не может понять что там не только 7 должно быть
О кривых руках я говорил уже. И лучше распрямить руки десятку разработчиков, чем сотням "типа админов".
Естественно, и среди админов попадаются толковые, как и среди разрабов - дятлы. Но статистика - вещь упрямая.

PS под юзерами я подразумевал не кноподавов, а заказчиков у разработчиков (т.е. и админов, раскиданных со своими пользователями по миру). Они друг о друге могут и не знать вовсе.

Проблема с запросом Найти похожие ветки