Ktoś wysłał mi bazę danych (za pomocą pliku .mdf i .ldf), którą załączyłem na serwerze (bez błędów, ostrzeżeń itp.) i chociaż nie mam dowodu (ponieważ mam nie mają dostępu do serwera, z którego pochodzi DB), wygląda na to, że wartości klucza podstawowego (tożsamości) są inne niż pierwotnie. Wydaje się również, że są one „zresetowane” — wszystkie wartości klucza podstawowego zaczynają się od 1, podczas gdy na podstawie odwołań do klucza obcego jest jasne, że jest to niepoprawne (na przykład tabela z tylko 1 wierszem ma wartość klucza podstawowego wynoszącą 1, ale tabela, która się do niej odwołuje, odwołuje się do wartości 7).

Chociaż tak naprawdę nie obchodzi mnie to, jestem ciekaw, dlaczego tak się dzieje (jeśli jest wyjaśnienie)?

To, czego naprawdę potrzebuję, to dowiedzieć się, czy istnieje sposób na dołączenie bazy danych i zachowanie prawidłowych wartości?

Edytuj: O ile wiem, odniesienia do kluczy obcych są skonfigurowane prawidłowo.

Oto kilka zrzutów ekranu: relacja klucza obcego kolumny relacji kluczy zagranicznych WTF!?

2
Nate Pinchot 11 czerwiec 2011, 00:43
Nigdy nie załączałem pliku, w którym zmieniły się wartości tożsamości. Podejrzewam, że baza danych nie została poprawnie zaprojektowana pod kątem integralności danych. Czy w strukturze są skonfigurowane rzeczywiste klucze obce? Biorąc pod uwagę to, co opisałeś, podejrzewam, że nie.
 – 
HLGEM
11 czerwiec 2011, 01:19
Rzeczywiście, istnieją ustawione relacje klucza obcego (prawidłowo, o ile wiem). To właśnie sprawia, że ​​sytuacja posiadania nieprawidłowych danych referencyjnych jest tak myląca. Dodałem kilka zrzutów ekranu do pytania, sprawdź je.
 – 
Nate Pinchot
11 czerwiec 2011, 01:43

2 odpowiedzi

Najlepsza odpowiedź

Wszystko, o czym mogę myśleć, ponieważ istnieją FK, to to, że mieli zły projekt na początek, a potem ktoś zdał sobie sprawę, że potrzebuje FK, ale były już złe dane, których nie chcieli usunąć i w ten sposób utworzył FKs WITH NOCHECK

Czy wszystkie osierocone rekordy mają wczesne numery identyfikacyjne?

3
HLGEM 11 czerwiec 2011, 01:48
Wydaje się rozsądną możliwością, ale bardzo mało prawdopodobną, ponieważ: istnieje tabela z opcjami językowymi (z kolumną tożsamości PK o nazwie LanguageID), która ma tylko 1 wiersz; LanguageID tego wiersza to 1. We wszystkich wszystkich tabelach, które się do niego odwołują, LanguageID wierszy to 7.
 – 
Nate Pinchot
11 czerwiec 2011, 01:56
1
Rzeczywiście na zrzucie ekranu w pytaniu wybrano opcję „Nie” dla opcji „Sprawdź istniejące dane”.
 – 
Martin Smith
11 czerwiec 2011, 02:27
Ach przepraszam, przegapiłem to. Nadal tak naprawdę nie wyjaśnia, w jaki sposób baza danych przeszła od „rzekomo działającej” do posiadania nieprawidłowych danych w całym miejscu bez podejrzenia nieczystej gry, ale jak mówi przysłowie, świat może się nigdy nie dowiedzieć.
 – 
Nate Pinchot
11 czerwiec 2011, 02:39

Dołączanie bazy danych nigdy nie zmienia zawartości tabeli. Wszystkie widoczne wartości pochodzą z aplikacji, która utworzyła bazę danych. ``select” nie jest uszkodzony.

1
Remus Rusanu 11 czerwiec 2011, 01:36
Chociaż całkowicie zgadzam się z Tobą w koncepcji, aplikacja działała doskonale z tą bazą danych na innym serwerze. Co prowadzi mnie do przekonania, że ​​albo dzieje się coś dziwnego, gdy dołączam bazę danych, ktoś celowo schrzanił bazę danych przed wysłaniem jej do mnie, albo mam niewłaściwą bazę danych — żadna z nich nie wydaje się prawdopodobna.
 – 
Nate Pinchot
11 czerwiec 2011, 01:47
Jeśli jesteś wystarczająco odważny, aby zapuścić się w nieudokumentowane funkcje, możesz użyć select ... from ::fn_dblog(null, null) do przeanalizowania historii dziennika, w jaki sposób te wartości tożsamości zostały wstawione, przynajmniej dziennika, który jest obecny w twojej bazie danych. To szybko pokazałoby, czy stało się to przed, czy po dołączeniu. Zobacz sqskills.com/blogs/paul/post/… na przykład użycia fn_dblog
 – 
Remus Rusanu
11 czerwiec 2011, 01:50
Dzięki za pomysł. Niestety baza danych jest "prostym" modelem odzyskiwania i nie oferuje zbyt wiele dzienników transakcji (tylko 43 wiersze). Kiedy robię select * from ::fn_dblog(null, null), wydaje się, że nie ma żadnych wierszy, które byłyby pomocne (choć będę szukać dalej). Nie widzę żadnych wierszy, które oczywiście zmieniają dane, co wciąż pozostawia mnie do zastanowienia: jeśli dane nie zmieniły się podczas dołączania bazy danych, w jaki sposób @#%(& czy te FK mogą istnieć, jeśli dane referencyjne wartości są nieprawidłowe?!
 – 
Nate Pinchot
11 czerwiec 2011, 02:08