Witam
Mam program, który zapisuje całe pliki w typie danych image. Architektura aplikacji wygląda w ten sposób, iż aplikacja desktopowa łączy się z webservicem wysyła cały plik danych, następnie webservice przy wykorzystaniu transakcji ładuje plik do bazy MSSQL. Klient twierdzi, iż miał przypadek, że dane później odczytane były błędne mimo prawidłowego procesu wgrania do bazy danych. W mojej opinii jeżeli ładujemy do bazy coś przy wykorzystaniu transakcji no to nie ma siły by cała operacja była źle zrealizowana. Czy ktoś miał podobny problem ? Czy jest w ogóle jakaś szansa, że coś w tej operacji jest nie tak ? Osobiście nie jestem zwolennikiem wczytywania całych plików do bazy, wolę jeżeli w bazie przechowujemy tylko adres do pliku.
0
0
Szczerze, to byłbym ostrożny z mówieniem "Nie ma takiej siły". Co to znaczy, że dane były błędne?Za mało, zduplikowane?Transakcja ma jakieś save pointy?Odbierasz jakieś potwierdzenie z bazy na temat udanego ładowania tych danych? Ja zawsze staram się przy swoich apkach odebrać potwierdzenie typu-rozmiar==rozmiar wrzucony, lub liczba wierszy wstawiona == liczba obiektów w ArrayList.Jeżeli klient sprecyzował kiedy był ten błąd, to przejrzyj loga i może tam coś znajdziesz.
Pozdrawiam
0
Mikajlo8 napisał(a):
Szczerze, to byłbym ostrożny z mówieniem "Nie ma takiej siły". Co to znaczy, że dane były błędne?Za mało, zduplikowane?Transakcja ma jakieś save pointy?Odbierasz jakieś potwierdzenie z bazy na temat udanego ładowania tych danych? Ja zawsze staram się przy swoich apkach odebrać potwierdzenie typu-rozmiar==rozmiar wrzucony, lub liczba wierszy wstawiona == liczba obiektów w ArrayList.Jeżeli klient sprecyzował kiedy był ten błąd, to przejrzyj loga i może tam coś znajdziesz.
Pozdrawiam
Błędne dane oznacza, że danych jest za mało. Nie ma żadnych save pointów w transakcji.
0
W tej sytuacji zostaje Ci sprawdzenie loga.Inna sprawa, że na Twoim miejscu wprowadziłbym pewien rodzaj walidacji, tj. Porównałbym rozmiar danych wysłanych ,odebranych i wrzuconych do bazy.Są pewne błędy które sprawiają, że transakcja nie jest odwracana pomimo, że ten błąd wystąpił np. błędy integralności danych..Sprawdź loga, tam pewnie jest odpowiedź.
Uruchom coś takiego w SQL SERVER:
Select *
from test1
begin transaction
insert into test1(id) values (44)
insert into test1(id) values (44)
commit tran
Select *
from test1
W tabeli masz 44, pomimo, że drugi dał błąd.SQL SERVER nie cofnął pierwszego insertu.
0
Nie cofnął, bo domyślnie transakcja nie jest zwijana w przypadku błędu. Ale wystarczy ustawić SET XACT_ABORT ON przed transakcją i już tak się stanie.
0
@somekind nie do końca.
Jeżeli ustawisz XACT_ABORT ON rzeczywiście złapie Ci każdy błąd i odwróci transakcję.Jednak przy SET XACT_ABORT OFF, są błędy które odwracają transakcję(np.conversion failed) ale są także takie które jej nie odwracają np.primary key violation.
Transakcja odwrócona:
SET XACT_ABORT OFF
go
Select *
from test1
begin transaction
insert into test1(id) values (49)
insert into test1(id) values ('jjk')
commit tran
Select *
from test1
Transakcja nieodwrócona:
SET XACT_ABORT OFF
go
SELECT *
FROM test1
BEGIN TRANSACTION
INSERT INTO test1(id) VALUES (44)
INSERT INTO test1(id) VALUES (44)
commit tran
SELECT *
FROM test1
Pozdrawiam