2015-02-27 18 views
6

Używamy dwóch schematów w naszym projekcie (dbo + kal).SQL71501 - Jak pozbyć się tego błędu?

Kiedy próbujemy utworzyć widok z następującą instrukcją SQL, Visual Studio wyświetla się jako błąd na liście błędów.

CREATE VIEW [dbo].[RechenketteFuerAbkommenOderLieferantenView] 
AS 
    SELECT 
     r.Id as RechenkettenId, 
     r.AbkommenId, 
     r.LieferantId, 
     rTerm.GueltigVon, 
     rTerm.GueltigBis, 
     rs.Bezeichnung, 
     rs.As400Name 
    FROM 
     [kal].[Rechenkette] r 
    JOIN 
     [kal].[RechenketteTerm] rTerm ON rTerm.RechenketteId = r.Id 
    JOIN 
     [kal].[Basisrechenkette] br ON rTerm.BasisrechenketteId = br.Id 
    JOIN 
     [kal].[Rechenkettenschema] rs ON rs.Id = br.Id 
    WHERE 
     r.RechenkettenTyp = 0 

Komunikat o błędzie wygląda następująco:

SQL71501: Kolumna komputerowa. [Dbo] [RechenketteFuerAbkommenOderLieferantenView] [AbkommenId] zawiera nierozwiązane odniesienie do obiektu.. Obiekt nie istnieje lub odniesienie jest niejednoznaczne, ponieważ może odnosić się do dowolnego z następujących obiektów:
[kal]. [Basisrechenkette]. [R] :: [AbkommenId], [kal]. [Rechenkette]. [ AbkommenId], [kal]. [Rechenkette]. [R] :: [AbkommenId], [kal]. [Rechenkettenschema]. [R] :: [AbkommenId] lub [kal]. [RechenketteTerm]. [R] :: [AbkommenId].

Publikowanie widoku i pracy jest w porządku, ale dość denerwujące jest wyświetlanie komunikatu o błędzie przez cały czas, gdy budujemy nasz projekt, po tym jak wszystkie poważne błędy zostaną utracone podczas przetasowania tych błędów sql.

Czy masz pojęcie, jaki może być problem?

+0

Zmień nazwę 'Alias' z' r.Id jako RechenkettenId, 'na' r.Id as someI, ' –

+0

Nic się nie zmieniło – Jannik

Odpowiedz

2

Właśnie znalazłem rozwiązanie. Chociaż nie mogę odczytać Twojego (co wydaje się być Niemcem) wystarczająco dużo, aby wiedzieć, czy mówisz o widokach systemowych, jeśli tak, musisz podać odniesienie do bazy danych do wzorca. W przeciwnym razie dodanie innych wymaganych odniesień do bazy danych powinno rozwiązać problem.

ta opisana jest tutaj dla widoków systemowych: Resolve reference to object information schema tables

i for other database references.

Dodatkowe informacje można znaleźć tutaj: Resolving ambiguous references in SSDT project for SQL Server

+0

Dzięki za spóźnioną odpowiedź. Przeprowadziłem się do innej firmy, niestety nie mogę już tego przetestować. – Jannik

2

Mamy projekt, który zawiera widok odwołujący funkcję wycenione tabeli w innej bazie danych. Po dodaniu odwołania do bazy danych, które jest wymagane do rozwiązania pól używanych ze zdalnej bazy danych, nadal otrzymywaliśmy ten błąd. Zauważyłem, że funkcja wyceniana w tabeli została zdefiniowana za pomocą "SELECT * FROM ...", która była starym kodem stworzonym przez kogoś, kto nie znał dobrych praktyk kodowania. Wymieniłem część "*" na wyliczone pola potrzebne i skompilowałem tę funkcję, a następnie ponownie utworzyłem dacpac dla tej bazy danych, aby uchwycić wynikowy schemat i włączyłem nowy dacpac jako odniesienie do bazy danych. Woo Hoo! niejednoznaczne odniesienia odeszły! Wygląda na to, że silnik SSDT nie może (lub nie ma) zawsze mieć możliwość dotarcia do wnętrza referencyjnego dacpaca, aby wrócić z wszystkimi polami. Z pewnością projekty, nad którymi pracuję, są zwykle dość duże, więc myślę, że sensowne jest udzielenie narzędziom wszelkiej pomocy, kiedy poprosimy ich o sprawdzenie kodu.

Powiązane problemy