Ошибка ORA-01400 у одного пользователя

@DKbru · Регистрация: 29.08.2011

Author24 — интернет-сервис помощи студентам

Здравствуйте, уважаемые форумчане! Проблема следущего плана: У нашей БД Oracle 10g XE есть GUI через который пользоваетель рассчитывает начисления по датам. Так вот у одного пользователя (у Админа такой проблемы нет) они не добавляются и выдает ошибку Ошибка ORA-01400: cannot insert NULL. Все триггеры и процедуры, указаные в ошибке валидны и работают прекрасно. Строка в которую триггер, по каким то причинам, пытается забить null,- это дата платежа (NOT NULL).
В чем вообще ТЕОРИТИЧЕСКИ может быть проблема? О_о

@Grossmeister · 29.08.2011, 11:08

Чудес не бывает. Если Oracle говорит, что в какую-то колонку пытаются передать NULL, хотя там его быть не может (например, колонка объявлена как NOT NULL) - значит так оно и есть. Попытайся увидеть те значения, которые передаются в INSERT (например, записать их в какую-то таблицу типа лога, возможно в автономной транзакции).

@DKbru · 29.08.2011, 11:21 **[ТС]**

Grossmeister, я верю в чудеса

Проблема в том, что мы делали уже и SQL логи. Событие не ловится. Вводимые значения у всех других пользователей верные. Триггеры те же, процедуры те же. Если было неверное значение, то GUI бы его не пропустил и проблема была бы у всех пользователей, а не у одного.

@Grossmeister · 29.08.2011, 11:26

Не понял, как это "не ловится"?
Создаешь функцию логирования с прагмой автономной транзакции (чтобы лог заполнялся даже при откате основной). Перед вызовом INSERT с помощью этой фунции записываешь все передаваемые значения в свою таблицу, созданную для логирования. Потом вызываешь действие под "нехорошим пользователем".
А насчет того, что "ГУИ не пропустил" - мало ли какие бывают ошибки.

@DKbru · 29.08.2011, 11:46 **[ТС]**

Grossmeister, спасибо, конечно, попробуем, но де-факто там стопятсот триггеров, в половине из которых есть рекурсия и циклы и найти null будет сложно. Тем более лог уже создавали и значение "потерялось" после обработки триггером, который его никак не должен был терять. Может ли быть проблема в привелегиях или ролях? Или в праймари айди?

@Grossmeister · 29.08.2011, 12:10

Сообщение от DKbru

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

Смотря что у вас в триггере. А в чем проблема сравнить привилегии "хорошего" и "нехорошего" пользователя? Или права тоже черезчур навороченные?

@DKbru · 29.08.2011, 12:20 **[ТС]**

Grossmeister, на тестовой системе мы создавали пользователя с теми же привелегиями и он все прекрасно добавлял. К сожалению проделать то же с оригиналом не представляется возможности. Мне важно определить алгоритм инфификации "нехорошести" пользователя. Какие у него могут быть координальные отличия от всех других, которые приводят к такой ошибке?

@rug1976 · 29.08.2011, 15:21

Думаю, проблема в правах пользователя. Надо попробовать сравнить права этого пользователя с правами пользователя, у которого проблемы нет (но не Админа).

@Laba · 29.08.2011, 22:08

Сообщение от DKbru

Grossmeister, спасибо, конечно, попробуем, но де-факто...

О-те какой "упертый"... ему дело говорят, а он: это-же работать надо

))

Я солидарен с Grossmeister Вряд ли это права и привилегии (если конечно в топике не лукавите). Скорее всего, банальная фича зависящая от данных.

Ваше клиентское приложение конечно же контролирует данные и формирует правильный инсерт, но вот только значение в колонке при обработке этого инсерта отчего-то превращается в нуль.

Для поиска этого "волшебника" можно ещё в стек ошибки глубже заглянуть.

@NETClient · 30.08.2011, 09:06

Как хорошо что есть Grossmeister, что бы ламеры без него делали.

@DKbru 0 / 0 / 0 Регистрация: 29.08.2011 Сообщений: 6
		1
	Ошибка ORA-01400 у одного пользователя 29.08.2011, 10:46. Показов 11229. Ответов 9 Метки нет (Все метки) Здравствуйте, уважаемые форумчане! Проблема следущего плана: У нашей БД Oracle 10g XE есть GUI через который пользоваетель рассчитывает начисления по датам. Так вот у одного пользователя (у Админа такой проблемы нет) они не добавляются и выдает ошибку Ошибка ORA-01400: cannot insert NULL. Все триггеры и процедуры, указаные в ошибке валидны и работают прекрасно. Строка в которую триггер, по каким то причинам, пытается забить null,- это дата платежа (NOT NULL). В чем вообще ТЕОРИТИЧЕСКИ может быть проблема? О_о 0

@Grossmeister Модератор 4217 / 3058 / 583 Регистрация: 21.01.2011 Сообщений: 13,205
	29.08.2011, 11:08	2
	Чудес не бывает. Если Oracle говорит, что в какую-то колонку пытаются передать NULL, хотя там его быть не может (например, колонка объявлена как NOT NULL) - значит так оно и есть. Попытайся увидеть те значения, которые передаются в INSERT (например, записать их в какую-то таблицу типа лога, возможно в автономной транзакции). 1

@DKbru 0 / 0 / 0 Регистрация: 29.08.2011 Сообщений: 6
	29.08.2011, 11:21 [ТС]	3
	Grossmeister, я верю в чудеса Проблема в том, что мы делали уже и SQL логи. Событие не ловится. Вводимые значения у всех других пользователей верные. Триггеры те же, процедуры те же. Если было неверное значение, то GUI бы его не пропустил и проблема была бы у всех пользователей, а не у одного. 0

@Grossmeister Модератор 4217 / 3058 / 583 Регистрация: 21.01.2011 Сообщений: 13,205
	29.08.2011, 11:26	4
	Не понял, как это "не ловится"? Создаешь функцию логирования с прагмой автономной транзакции (чтобы лог заполнялся даже при откате основной). Перед вызовом INSERT с помощью этой фунции записываешь все передаваемые значения в свою таблицу, созданную для логирования. Потом вызываешь действие под "нехорошим пользователем". А насчет того, что "ГУИ не пропустил" - мало ли какие бывают ошибки. 0

@DKbru 0 / 0 / 0 Регистрация: 29.08.2011 Сообщений: 6
	29.08.2011, 11:46 [ТС]	5
	Grossmeister, спасибо, конечно, попробуем, но де-факто там стопятсот триггеров, в половине из которых есть рекурсия и циклы и найти null будет сложно. Тем более лог уже создавали и значение "потерялось" после обработки триггером, который его никак не должен был терять. Может ли быть проблема в привелегиях или ролях? Или в праймари айди? 0

@Grossmeister Модератор 4217 / 3058 / 583 Регистрация: 21.01.2011 Сообщений: 13,205
	29.08.2011, 12:10	6
	Сообщение от DKbru Тем более лог уже создавали и значение "потерялось" после обработки триггером, который его никак не должен был терять. Может ли быть проблема в привелегиях или ролях? Или в праймари айди? Смотря что у вас в триггере. А в чем проблема сравнить привилегии "хорошего" и "нехорошего" пользователя? Или права тоже черезчур навороченные? 0

@DKbru 0 / 0 / 0 Регистрация: 29.08.2011 Сообщений: 6
	29.08.2011, 12:20 [ТС]	7
	Grossmeister, на тестовой системе мы создавали пользователя с теми же привелегиями и он все прекрасно добавлял. К сожалению проделать то же с оригиналом не представляется возможности. Мне важно определить алгоритм инфификации "нехорошести" пользователя. Какие у него могут быть координальные отличия от всех других, которые приводят к такой ошибке? 0

@rug1976 3 / 3 / 0 Регистрация: 07.06.2011 Сообщений: 17
	29.08.2011, 15:21	8
	Думаю, проблема в правах пользователя. Надо попробовать сравнить права этого пользователя с правами пользователя, у которого проблемы нет (но не Админа). 0

@Laba 105 / 75 / 0 Регистрация: 29.06.2009 Сообщений: 328
	29.08.2011, 22:08	9
	Сообщение от DKbru Grossmeister, спасибо, конечно, попробуем, но де-факто... О-те какой "упертый"... ему дело говорят, а он: это-же работать надо )) Я солидарен с Grossmeister Вряд ли это права и привилегии (если конечно в топике не лукавите). Скорее всего, банальная фича зависящая от данных. Ваше клиентское приложение конечно же контролирует данные и формирует правильный инсерт, но вот только значение в колонке при обработке этого инсерта отчего-то превращается в нуль. Для поиска этого "волшебника" можно ещё в стек ошибки глубже заглянуть. 0

@NETClient 3 / 3 / 0 Регистрация: 28.05.2011 Сообщений: 18
	30.08.2011, 09:06	10
	Как хорошо что есть Grossmeister, что бы ламеры без него делали. 0