Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

[MS SQL] Oblsuga bledow

25 views
Skip to first unread message

szym...@poczta.onet.pl

unread,
Jun 6, 2002, 11:00:57 AM6/6/02
to
czy w procedurze jezeli mam

CREATE PROCEDURE ZZZ
AS
INSERT INTO XX VALUES(@X, @Y)
GO

to czy trzeba dodawac
np

CREATE PROCEDURE ZZZ
AS
INSERT INTO XX VALUES(@X, @Y)
IF @@ERROR<>0
BEGIN
RAISEERROR 20000 N'AAAA'
END
GO


To chyba nie trzeba bo jak wystapi blad w insertie to i tak nie wykona mojego
raiserrora, czy tak?

sz

--
Wysłano z serwisu OnetNiusy: http://niusy.onet.pl

Paweł Filipiak

unread,
Jun 6, 2002, 11:14:26 AM6/6/02
to
Użytkownik <szym...@poczta.onet.pl> napisał w wiadomości
news:1546.000013...@newsgate.onet.pl...
[...]

>
> to czy trzeba dodawac
> np
> BEGIN
> RAISEERROR 20000 N'AAAA'
> END

nie, nie trzeba. Jeżeli insert się nie powiedzie z powodu na przykład
naruszenia klucza obcego błąd podniesie automatycznie engine bazy danych.
Możesz, jak chcesz, zwrócić wartość @@ERROR na zewnątrz procedury, jeżeli
chcesz go jakoś obsługiwać. Raiseerror służy do podnoszenia błędów
użytkownika.


--
pozdrawiam,
Paweł Filipiak
pfil...@poczta.fm; gg 2791867


Jacek Zaleski

unread,
Jun 7, 2002, 2:32:36 AM6/7/02
to
Sprawa nie jest taka prosta jak napisał mój przedmówca.
Ma rację, że jeżeli wystąpi błąd podczas jakiejś operacji
bazodanowej, to błąd zostanie zgłoszony automatycznie.
Dodatkowo musisz wiedzieć, że nie wszystkie błędy
powodują przerwanie wykonywania kodu (dopiero od
severity >=16, chyba). Jeżeli Twoja procedura będzie
zawierała więcej niż jedną instrukcję i któraś z nich wywoła
niekrytyczny błąd, to pozostałe wykonają się, chociaż nie
powinny. Dlatego dobrym zwyczajem jest sprawdzanie
zmiennej @ERROR i ew. przerywanie kodu.

Paweł Filipiak

unread,
Jun 7, 2002, 5:19:30 AM6/7/02
to
Użytkownik "Jacek Zaleski" <j...@simple.com.pl> napisał w wiadomości
news:adpk3v$1e70$1...@news2.ipartners.pl...
[...]

> severity >=16, chyba). Jeżeli Twoja procedura będzie
> zawierała więcej niż jedną instrukcję i któraś z nich wywoła
> niekrytyczny błąd, to pozostałe wykonają się, chociaż nie
> powinny. Dlatego dobrym zwyczajem jest sprawdzanie
> zmiennej @ERROR i ew. przerywanie kodu.

to prawda. Innym rozwiązaniem problemu opisanego wyżej jest zapięcie bloku
instrukcji w transakcję, przy wcześniejszym wymuszeniu przerywania i
wycofania transakcji w przypadku błędu. Kod będzie wyglądał następująco:
SET XACT_ABORT ON
BEGIN TRAN
INSERT1...
INSERT2...
...
INSERTn...
COMMIT TRAN
SET XACT_ABORT OFF

BooksOnLine mówi, że:
When SET XACT_ABORT is ON, if a Transact-SQL statement raises a run-time
error, the entire transaction is terminated and rolled back
Jeśli dobrze rozumiem chodzi o każdy runtime-error, bez względu na severity,
czy się mylę?

Jacek Zaleski

unread,
Jun 7, 2002, 6:10:00 AM6/7/02
to
> BooksOnLine mówi, że:
> When SET XACT_ABORT is ON, if a Transact-SQL statement raises a run-time
> error, the entire transaction is terminated and rolled back
> Jeśli dobrze rozumiem chodzi o każdy runtime-error, bez względu na
severity,
> czy się mylę?
Masz oczywiście rację. Zupełnie zapomniałem o tej możliwości.

Ireneusz Pełka

unread,
Jun 10, 2002, 3:01:04 AM6/10/02
to
A co powiecie na taka sytuacje:

set xact_abort on
begin tran
select * from cokolwiek
select @@error
rollback

go
select @@trancount

--
Pozdrawiam
Irek

0 new messages