|
IF и FOR SELECT на удаляемое поле
|
|||
---|---|---|---|
#18+
Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9.
Ошибка обращения к T1.TXT при повторном запуске скрипта. получается for select парсится или выполняется игнорируя результат условия IF ? IF проверил работает как и ожидается. FB 2.1.7 ... |
|||
:
Нравится:
Не нравится:
|
|||
13.09.2017, 16:06 |
|
IF и FOR SELECT на удаляемое поле
|
|||
---|---|---|---|
#18+
Нет, конечно. Как "проверял", отладчиком? "Повторном запуске" после коммита или без коммита? Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
13.09.2017, 16:08 |
|
IF и FOR SELECT на удаляемое поле
|
|||
---|---|---|---|
#18+
Вся процедура парсится и препарируется одновременно. Тут тебе не MS SQL, интерпретирующий батч по отдельным запросам. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
13.09.2017, 16:08 |
|
IF и FOR SELECT на удаляемое поле
|
|||
---|---|---|---|
#18+
А, он ещё и селектит дропнутое поле... Да, так нельзя, будет ошибка на препаре. Решение очевидно, конечно, но кривь. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
13.09.2017, 16:10 |
|
IF и FOR SELECT на удаляемое поле
|
|||
---|---|---|---|
#18+
1. конечно коммит после каждого выполнения. 2. IF проверял, вместо FOR SELECT, вставлял update заведомо существующего поля/записи. В логах: все как должно быть. 3. Задача: одним скриптом вытащить данные в таблицу Т2, а в Т1 удалить эти поля. Вот и я думал что это очевидное решение. Оказалось парсер не пускает такую конструкцию. Баг/недоработка СУБД? ... |
|||
:
Нравится:
Не нравится:
|
|||
13.09.2017, 16:21 |
|
IF и FOR SELECT на удаляемое поле
|
|||
---|---|---|---|
#18+
Гаджимурадов РустамА, он ещё и селектит дропнутое поле... Да, так нельзя, будет ошибка на препаре. Решение очевидно, конечно, но кривь. Вообще-то по логике можно. IF не должен давать зайти внутрь. п.с. Да, можно, как оказалось парсер MERGE пропускает как и должен. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.09.2017, 16:25 |
|
IF и FOR SELECT на удаляемое поле
|
|||
---|---|---|---|
#18+
Epox0UA, это на уровне архитектуры, EXECUTE BLOCK препарируется как единый statement. Если поля нет, значит ошибка препарирования. Не нравится иди туда где такое можно MS SQL, MySQL. В Firebird метаданные "на лету" изменять не принято ... |
|||
:
Нравится:
Не нравится:
|
|||
13.09.2017, 16:27 |
|
IF и FOR SELECT на удаляемое поле
|
|||
---|---|---|---|
#18+
Epox0UA1. конечно коммит после каждого выполнения. 2. IF проверял, вместо FOR SELECT, вставлял update заведомо существующего поля/записи. В логах: все как должно быть. 3. Задача: одним скриптом вытащить данные в таблицу Т2, а в Т1 удалить эти поля. Вот и я думал что это очевидное решение. Оказалось парсер не пускает такую конструкцию. Баг/недоработка СУБД? 1. COMMIT не означает unprepare 3. подмена понятий/смена контекста если делается через EXECUTE STATEMENT, то и делать надо через него все, в т.ч. UPDATE. это граната специальной системы :) ... |
|||
:
Нравится:
Не нравится:
|
|||
13.09.2017, 16:47 |
|
IF и FOR SELECT на удаляемое поле
|
|||
---|---|---|---|
#18+
Epox0UA> 3. Задача: одним скриптом вытащить данные Epox0UA> в таблицу Т2, а в Т1 удалить эти поля. Стоит задуматься о кривой архитектуре, ибо DDL и DML (да ещё в зависимости от DDL) смешивать не принято. Epox0UA> Оказалось парсер не пускает такую конструкцию. Epox0UA> Баг/недоработка СУБД? Не баг и не недоработка, а правила. В Оракле, к примеру, правила ещё строже. Нельзя на ходу выкидывать мотор и возмущаться, что машина не едет дальше. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
13.09.2017, 17:12 |
|
IF и FOR SELECT на удаляемое поле
|
|||
---|---|---|---|
#18+
Epox0UAЗадача: одним скриптом вытащить данные в таблицу Т2, а в Т1 удалить эти поля. Это не задача. Это твой способ решения некой задачи. Если расскажешь про задачу, может быть, здесь подскажут, как решить её без убиения столбцов на лету. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.09.2017, 18:06 |
|
IF и FOR SELECT на удаляемое поле
|
|||
---|---|---|---|
#18+
мне гранат не жалко Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9.
... |
|||
:
Нравится:
Не нравится:
|
|||
13.09.2017, 19:07 |
|
IF и FOR SELECT на удаляемое поле
|
|||
---|---|---|---|
#18+
Нехай все обезьяны подорвутся, да здравствует естественный отбор? Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
13.09.2017, 19:37 |
|
IF и FOR SELECT на удаляемое поле
|
|||
---|---|---|---|
#18+
Epox0UAБаг/недоработка СУБД? Баг и недоработка. Но не СУБД. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.09.2017, 20:09 |
|
IF и FOR SELECT на удаляемое поле
|
|||
---|---|---|---|
#18+
Гаджимурадов Рустам, если это делается один раз, монопольно, для обновления структуры бд, то почему бы и нет ... |
|||
:
Нравится:
Не нравится:
|
|||
14.09.2017, 12:12 |
|
IF и FOR SELECT на удаляемое поле
|
|||
---|---|---|---|
#18+
vvvait, если это делается для обновления структуры БД, то и не фиг EXECUTE BLOCK делать. Пиши нормальный скрипт ... |
|||
:
Нравится:
Не нравится:
|
|||
14.09.2017, 12:18 |
|
IF и FOR SELECT на удаляемое поле
|
|||
---|---|---|---|
#18+
Симонов Денис, suum cuique ... |
|||
:
Нравится:
Не нравится:
|
|||
14.09.2017, 12:20 |
|
IF и FOR SELECT на удаляемое поле
|
|||
---|---|---|---|
#18+
vvvait> если это делается один раз Если делается один раз, то не бывает никаких "повторно". > монопольно, для обновления структуры бд, то почему бы и нет Если для обновления структуры, то делается скрипт (и обычно два отдельных - один на весь DDL, затем отдельный на DML), а не смешанный EB на 2 строчки. И обычно обновляя структуры, знают с какой версии (и структуры БД), а не проверяют (хотя бывает и такое). Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
14.09.2017, 12:38 |
|
IF и FOR SELECT на удаляемое поле
|
|||
---|---|---|---|
#18+
Гаджимурадов Рустамvvvait> если это делается один раз Если делается один раз, то не бывает никаких "повторно". > монопольно, для обновления структуры бд, то почему бы и нет Если для обновления структуры, то делается скрипт (и обычно два отдельных - один на весь DDL, затем отдельный на DML), а не смешанный EB на 2 строчки. И обычно обновляя структуры, знают с какой версии (и структуры БД), а не проверяют (хотя бывает и такое). обычно, правильно, удобно - три разных сущности перенос на новую структуру БД у нас делается выполнением нескольких десятков блоков. в старой БД создаются поля (если их нет), заполняются по правилам, или по дефолту. что должно быть - берется из новой структуры БД, там же скрипты и правила переноса. и клиентские exe/ потом данные тупо переливаются в новую БД. гарантированно правильной структуры. в прежней ничего не удаляется. все равно на помойку. скорость - 2 гб база за 20 мин. бонусом тождественная структура БД у всех заказчиков, клиентские экзешники в точности соответствуют структуре. пункт № 0 - бакап. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.09.2017, 12:47 |
|
|
start [/forum/topic.php?fid=40&fpage=41&tid=1561425]: |
0ms |
get settings: |
10ms |
get forum list: |
15ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
38ms |
get topic data: |
12ms |
get forum data: |
2ms |
get page messages: |
61ms |
get tp. blocked users: |
2ms |
others: | 298ms |
total: | 446ms |
0 / 0 |