Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

Обработка ошибок в MSSQL [D5, MSSQL]

Страницы: 1 2 >
Vick © (2003-12-04 18:01:00)

Доброго всем вечера!!!

Можно ли в MSSQL производить обработку исключений, таки мобразом, чтобы выдавалось сообщение об ошибке, но процесс выполнения процедуры продолжался дальше???

Задача такая: идет запись данных в таблицу в цикле, на каком-то конкретном шаге попадается запись с неверной датой, типа 01.12.1003, возникает ошибка Error converting data type DBTYPE_DBDATE to datetimeи выполнение процедуры обрывается, а я хочу, чтобы процесс продолжался дальше...

MDFE (2003-12-07 06:31:00) [1]

>Процедура действительно запускается из job-а, и все работает классно (прием почты, загрузка отчетов) до того момента, пока не появится корявый файл.

По опыту, при любых(?которые мне попадались) ошибках job заканчивает свою работу

>А что же тогда делать, так же все время будет натыкаться процесс а неправильный файл и останавливаться и не будет возможности выяснить, какой файл неверен, кроме как перебором. :(((( Или может есть другой способ?

Динамично создать job, в job`e - step с @step_name="имя обрабатываемого файла" и телом из @S, и запустить.

>и не будет возможности выяснить, какой файл неверен, кроме как перебором.

в job history смотрим result - @step_name у нас название файла

LordOfSilence (2003-12-05 18:06:00) [2]

Постарайся показать себя специалистом, который ПРЕДЛАГАЕТ
технические решения и пути выхода из затруднительных ситуаций,
иначе тебе придется идти на поводу у дилентантов в области
автоматизации. В итоге будет хуже всем.

Vick (2003-12-05 17:55:00) [3]

Удалено модератором

sniknik (2003-12-05 17:48:00) [4]

Удалено модератором

Vick (2003-12-05 17:21:00) [5]

>Конструктор
В филиале с кассой работает программа утвержденная налоговой испекцией, она то и формирует эти файл отчетов, так что у меня к ним никакого доступа, кроме как почитать их.... Да собственно никто другого и не даст сделать.

На данный момент нужно решить докальную задачу: принять отчеты, загрузить, те которые не грузятся откинуть и грузить дальше остальные

sniknik (2003-12-05 17:08:00) [6]

дельфи он не обязательно с кнопками. о, мудрая мысль (!!!). ;о)))

Vick © (05.12.03 15:37) [23]
> И что самое страшное - это не банк!!!!! Это МАГАЗИНЫ!!!!!!!
в какой системе работаеш? а то может конкуренту помагаю... :о))

Delirium (2003-12-05 16:30:00) [7]

"делфи надоел со своими кнопками, нам нужно загружать отчеты силой мысли... " - приведи дельфёвый проект к Extended Stored Procedure и все дела - начальство довольно, и ты создала "видимость работы" :)))

Конструктор (2003-12-05 16:28:00) [8]

>Vick
>посему контролировать все 27 полей на наличие в них ошибок не имеет смысла.
Но к сожалению придется, и я рекомендую встраивать контроль в софт в филиале для полей по которым строиться отчет, если конечно этот отчет нужен бизнесу.
P.S.
1.Интересно посмотреть на лицо клиента, которому выдали документы на туристическую поездку на 01.12.1003 или платежку на аналогичную дату.
2.Не рекомендую связываться с курсорами в MSSQL

ppcat (2003-12-05 16:27:00) [9]

В [20] и [21] был вопрос: будет ли хранимая процедура продолжать работать после ошибки?

Нет, она действительно прервется, но выход есть. Если загрузку файла поручить другой процедуре, то она-то и срубится, а в вызывающей просто проверить результат. Если файл не загрузился, пропустить эту итерацию.

Artem03 (2003-12-05 15:47:00) [10]

CREATE PROCEDURE spDelCountry
@ID int
AS

DELETE FROM Countries WHERE ID = @ID
IF (@@ERROR <> 0)
BEGIN
RAISERROR ("Ошибка выполнения ХП", 16, 1)
ROLLBACK TRANSACTION
END

Вот этот RAISEERROR надо отловить и подавить вывод системного сообщения.

try
...
ADOCommand.Execute
except
on E: EOleException do Message("EOleException : "+ E.Message); end;

EOleException : Ошибка выполнения ХП

Vick (2003-12-05 15:37:00) [11]

>Конструктор

Супер!!!!! Именно так все сейчас и работет!!!! Но как я написала в [20] мы придумываем проблемы из ничего, посему нам уже делфи надоел со своими кнопками, нам нужно загружать отчеты силой мысли... На самом деле даты хранятся в полях типа "дата", но юзер может загнать дату типа 01.01.1003 - чем не дата???? Но умный SQL начинает свою жизнь с 01.01.1753 :)))))) Для него это не дата..... А такие отчеты мне грузить нельзя, т.к. потом из принцыпу звониться в филиал и возиться его мордой по радиатору!!!!

И что самое страшное - это не банк!!!!! Это МАГАЗИНЫ!!!!!!!

Конструктор (2003-12-05 15:30:00) [12]

>Vick
На основании Vick © (05.12.03 11:32) [8] - у вас прежде всего технологическая проблема и раз вы работаете в банке, то постройте правильно банковскую технологию:формирование данных –отправка –прием-сохранение данных-формирование отчетности.
Если вы будете в текстовых полях хранить даты, суммы,то имея на входе мусор – и получите мусорный отчет и задачку свою не решите.
Я бы сделал так:
1. Как рекомендовали мастера (sniknik © (05.12.03 11:47) [10] )– утвердите структуры данных в dbf и MSSQL, которые обеспечат правильный ввод данных именно в dbf и назначьте ответственных за этот ввод.
2. На MSSQL создайте пару сервисных табличек, хранящих информацию о процессе загрузки типа сеанс загрузки и основные данные о приходящей информации по файлам.
3.Напишите загрузчик (dbf->MSSQL) на Delphi.
4.А отчеты получайте вашим инструментарием. Вы про него ничего не написали.

Успехов в банковской автоматизации.

Vick (2003-12-05 15:22:00) [13]

>ppcat

Ну словиться ошибка, и прекратит работу процедуры навечно, а мне нужно продолжить!!!! Или нет?

Vick (2003-12-05 15:21:00) [14]

>LordOfSilence

Начальство меня и близко к серверу не подпускает, сижу тут как в танке!!!

Сейчас загрузка отчетов работает через делфи - и никаких проблем, следовательно проблемы нужно создать, чтобы показать видимость работы...

>sniknik

Процедура действительно запускается из job-а, и все работает классно (прием почты, загрузка отчетов) до того момента, пока не появится корявый файл.

Хорошо, а можно ли продолжить работу следуюих действий процедуры после сбоя в этой транзакции? Или это в принцыпе не возможно?

ppcat (2003-12-05 15:15:00) [15]

Да на сервере тоже можно ошибки ловить:

... Кусок кода SQL где могут быть ошибки ...
if (@@ERROR > 0)
begin
exec master..xp_cmdshell
"@echo "мать, мать, мать, такой-то файл... >> err.log"
или
raiserror("мать, мать, мать, такой-то файл...",16,-1)
end

LordOfSilence (2003-12-05 14:34:00) [16]

2 sniknik © (05.12.03 14:22) [17]
это я к тому, что можно написать маленький делфийский таск,
а начальство будет по-прежнему думать, что "у нас все чисто на SQL" :-)

sniknik (2003-12-05 14:22:00) [17]

> посему все должон выполнять SQL.
т.е. процедура запускается из job-а? если всена SQL.

тогда причем сдесь D5? если же всетаки причем то зачем кнопка? поток и слежение за почтовой директорией и все будет на автомате. (external task по моему будет гораздо сложнее, да и приемка будет дискретной (по определенным часам), а так почти в реале)

LordOfSilence (2003-12-05 13:34:00) [18]

В DTS-package есть возможность выполнить external task

Vick (2003-12-05 13:29:00) [19]

Как по мне - проще нажать кнопку - принять почту, а потом кнопку принять отчеты в программе.

Но начальство решило прыгнуть выше головы, посему все должон выполнять SQL.

sniknik (2003-12-05 12:45:00) [20]

Vick © (05.12.03 12:31) [13]
а вот этого условия в вопросе не было. ;о))

это проверить проще до запуска sql-ной процедуры. (мне так кажется)

Страницы: 1 2 >

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »