2017-01-03 99 views
7

Próbuję wykonać kwerendę aktualizacji scalania w serwerze sql.Problem z kwerendą aktualizacji scalającej nie działa tak jak powinien

tabela "my_table" ma 4 kolumny "Pole" (znak), "Date" (data), "val" (numeryczna), "rewizja" (datetime)

zapytanie jest jako takie:

MERGE "my_table" AS Target USING (VALUES ('field_example','2017-01-04','0','2017-01-03 12:02:02')) AS Source ("field","date","val","revision") 
        ON (Target."field" = Source."field" AND Target."date" = Source."date") 
        WHEN MATCHED 
        THEN UPDATE SET Target."val" = Source."val",Target."revision" = Source."revision" 
        WHEN NOT MATCHED BY TARGET 
        THEN INSERT ("field","date","val","revision") 
        VALUES (Source."field", Source."date", Source."val", Source."revision") 
        OUTPUT $action, Inserted.*, Deleted.*; 

Ponieważ istnieje już wiersz „my_table” z pole = „field_example” i date = „04.01.2017”, spodziewam tę kwerendę, aby zaktualizować 2 inne kolumny „Val”, "rewizji ".

uzyskać następujący wynik zapytania:

$action   field  date   revision val   field.1  date.1   revision.1 val.1 
1 UPDATE field_example 2017-01-04 2017-01-03 12:02:02 0 field_example 2017-01-04 2017-01-03 10:09:25 161250 

więc wygląda dobrze (aby zostały zaktualizowane tak jak powinien)

Jednak kiedy patrzę w bazie danych, wiersz nie został zaktualizowany (= wartość val nadal wynosi 161250 zamiast 0, a wersja wciąż jest 2017-01-03 10:09:25)

Każdy pomysł, dlaczego?

+0

Czy możesz dodać przykładowe dane z tabeli. –

+0

Mam nadzieję, że tam nie ma ROLLBACK lub przywróć instrukcję/trigger istnieje. –

Odpowiedz

7

Jednak kiedy patrzę w bazie danych, wiersz nie został zaktualizowany (= val jest nadal 161.250 zamiast 0, a korekta jest wciąż 2017-01-03 10:09:25)

Każdy pomysł, dlaczego?

Być może pytasz o inną tabelę/bazę danych lub transakcja została wycofana. Poniższy skrypt działa zgodnie z oczekiwaniami, zgadując rzeczywiste typy danych.

CREATE TABLE dbo.my_table(
    "field" varchar(100) 
    ,"date" date 
    ,"val" int 
    ,"revision" datetime 
    ); 

INSERT INTO my_table ("field","date","val","revision") 
    VALUES ('field_example','2017-01-04','161250','2017-01-03 10:09:25'); 

MERGE "my_table" AS Target USING (VALUES ('field_example','2017-01-04','0','2017-01-03 12:02:02')) AS Source ("field","date","val","revision") 
    ON (Target."field" = Source."field" AND Target."date" = Source."date") 
    WHEN MATCHED THEN 
     UPDATE SET Target."val" = Source."val",Target."revision" = Source."revision" 
    WHEN NOT MATCHED BY TARGET THEN 
     INSERT ("field","date","val","revision") 
      VALUES (Source."field", Source."date", Source."val", Source."revision") 
    OUTPUT $action, Inserted.*, Deleted.*; 

SELECT "field","date","val","revision" 
FROM my_table; 
+1

Przypuszczam, że nie jest możliwe, aby polecenie MERGE został wycofany, a na wyjściu jest nadal to, co dostaje. Sądzę więc, że założenie, że użytkownik wysyła zapytanie do niewłaściwego db/table, jest bardziej prawdopodobne. PS: I tak, Merge działało zgodnie z oczekiwaniami. –

+4

@AndreasVenieris, moja uwaga dotycząca wycofywania zmian miałaby zastosowanie tylko w przypadku jawnej transakcji przed wyciągiem "MERGE" i kolejnym wycofywaniem. Poprawne wyniki klauzuli "WYJŚCIE" będą nadal zwracane w takim przypadku. –

+0

Przepraszam @ Dan Guzman, po prostu cię dopadłam. Tak to mozliwe. Myślałem, że masz na myśli sam "MERGE". Przepraszam za nieporozumienie. Mea culpa ;) –