|
|
|
Триггер на Insert
|
|||
|---|---|---|---|
|
#18+
К концу дня тупость какая-то. Подскажите короткий триггер. При Insert в таблицу во вставляемой строке заменить одно поле на специальное значение. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.05.2003, 16:27 |
|
||
|
Триггер на Insert
|
|||
|---|---|---|---|
|
#18+
Код: plaintext 1. 2. 3. 4. 5. 6. 7. null заменится на значение из последовательности. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.05.2003, 16:36 |
|
||
|
Триггер на Insert
|
|||
|---|---|---|---|
|
#18+
Данке шон, как у вас по-местному. А то тупость какая-то - на все ошибки натыкаться. лепил в ".nextval into :new.имя_таблицы.имя_поля" , after, в теле триггера запрещенные DML тыкал, ... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.05.2003, 16:54 |
|
||
|
Триггер на Insert
|
|||
|---|---|---|---|
|
#18+
.DBA! А в Oracle есть такое, чтобы с наступлением нового дня некий счетчик обнулялся. Конечно можно табличку с дата положить в БД, а потом когда нужен очередной номер вызывать процедурку, которая сравнивала бы sysdate с той датой и когда отличие, то обнуляла бы счетчик и дату меняла. Но ... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.05.2003, 17:21 |
|
||
|
Триггер на Insert
|
|||
|---|---|---|---|
|
#18+
>А в Oracle есть такое, чтобы с наступлением нового дня некий счетчик >обнулялся. не совсем понял что ты хочешь сделать, но мне кажется, что можно сделать job, который будет каждую ночь дропать и создавать заново последовательность. Хотя это не очень надежно, но можно ввести дополнительные проверки. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.05.2003, 17:56 |
|
||
|
Триггер на Insert
|
|||
|---|---|---|---|
|
#18+
>не совсем понял что ты хочешь сделать, но мне кажется, что можно сделать >job, который будет каждую ночь дропать и создавать заново >последовательность. Хотя это не очень надежно, но можно ввести >дополнительные проверки А еще проще. Так: пропуска на территорию из инфосистемы выдаются и каждый день номерация новая. А такое вот: create table pass.pass_counter ( curr_n_pass number, curr_date date ) и функция get_num_pass, которая каждый раз проверяет sysdate, сравнивая с curr_date и как только отличие, то заменяет curr_date=sysdate и curr_n_pass=0 в pass.pass_counter. И дальше тащит номер и заменяет curr_n_pass до новых суток. Но это грубо. Что-то же элегантное интеллектуальное должно быть! :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.05.2003, 18:21 |
|
||
|
Триггер на Insert
|
|||
|---|---|---|---|
|
#18+
Сделать что-то типа: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. Надеюсь идея понятна? Хотя, я бы вынес сие в autonomous transaction, или придумал бы, как защититься от параллельного сброса. Ну или в полночь запускать job, который будет делать запись в таблицу. Тогда вообще, в лоб выбираешь seq_reason_tid.nextval-last_value и радуешься. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.05.2003, 00:21 |
|
||
|
Триггер на Insert
|
|||
|---|---|---|---|
|
#18+
Лаб диен VSKV! (так вроде у вас говорят) Первое - это вариация того, что описано - функция или триггер, который присваивает номера и проверяет наступило ли завтра, меняя при наступлении контесты реперных точек (начал отсчета, фиксации даты). >Ну или в полночь запускать job, который будет делать запись в таблицу. Это вариация того, что предлагал .DBA - job, дропающий и создающий последовательность. Please, если не в лом, не можешь ли нарисовать процедурку с помощью DBMS_JOB, создающую job, который запускался бы в полночь каждые сутки, а то Enterprise Manager-а может не быть при дистрибуциях. Не пробовал ни разу без Enterprise Manager. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.05.2003, 10:36 |
|
||
|
|

start [/forum/topic.php?fid=52&fpage=2778&tid=1990544]: |
0ms |
get settings: |
6ms |
get forum list: |
14ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
51ms |
get topic data: |
7ms |
get forum data: |
2ms |
get page messages: |
37ms |
get tp. blocked users: |
1ms |
| others: | 211ms |
| total: | 335ms |

| 0 / 0 |
