Przemysław Kwiatkowski 9 Napisano 21 Kwietnia 2020 Udostępnij Napisano 21 Kwietnia 2020 w vwPolaWlasne_Towar Co się stało z widokiem vwPolaWlasne_Towar ??? Ta sama baza w wersji 1.62HF2: SELECT pwd_Fk03, pwd_Fk04 FROM vwPolaWlasne_Towar where tw_Id=6350 pwd_Fk03 pwd_Fk04 NULL 228 W poprzedniej wersji: SELECT pwd_Fk03, pwd_Fk04 FROM vwPolaWlasne_Towar where tw_Id=6350 pwd_Fk03 pwd_Fk04 228 NULL Czemu pola zamieniły się miejscami? O co tu chodzi? Rozwaliło mi to połowę wzorców wydruku i własnych zestawień... Czy jakaś mądra dusza powie jak przywrócić poprzednią definicję widoku? Link to postu
Daniel Kozłowski 1 161 Napisano 21 Kwietnia 2020 Udostępnij Napisano 21 Kwietnia 2020 w vwPolaWlasne_Towar Dlaczego Pan zgaduje zamiast sprawdzić ? Proszę porównać definicje widoków (u mnie definicja zaczyna się od "select *"), ale wcześniej proponuję porównać dane... Link to postu
Przemysław Kwiatkowski 9 Napisano 21 Kwietnia 2020 Autor Udostępnij Napisano 21 Kwietnia 2020 w vwPolaWlasne_Towar Sprawdzić nie umiem, bo SSMS twierdzi, że definicja jest rzekomo jakoś zaszyfrowana. Wiem, że w Internecie są gdzieś informacje jak to odszyfrować, ale chwilowo nie jestem w stanie się skupić na ich czytaniu za zrozumieniem... (w przerwach między zdalną biologią a fizyką w ramach e-szkoły...) Tym niemniej - dane na pewno są dobre, a wyniki z widoku złe, bo dwa teoretycznie tożsame zapytania w tej samej bazie dają dwa różne wyniki. Przykład: SELECT pwd_Fk03, pwd_Fk04 FROM vwPolaWlasne_Towar where tw_Id=6350 pwd_Fk03 pwd_Fk04 NULL 228 SELECT pwd_Fk03, pwd_Fk04 FROM pw_Dane where pwd_IdObiektu=6350 AND pwd_TypObiektu = -14 pwd_Fk03 pwd_Fk04 228 NULL Link to postu
Daniel Kozłowski 1 161 Napisano 22 Kwietnia 2020 Udostępnij Napisano 22 Kwietnia 2020 w vwPolaWlasne_Towar 15 godzin temu, Przemysław Kwiatkowski napisał: Sprawdzić nie umiem Na prawdę muszę pisać co należy robić w takich sytuacjach i jak być do nich przygotowanym ? 15 godzin temu, Przemysław Kwiatkowski napisał: bo SSMS twierdzi, że definicja jest rzekomo jakoś zaszyfrowana. Tak, wszystkie obiekty pochodzące od Insertu są (powinny być) zaszyfrowanie. 15 godzin temu, Przemysław Kwiatkowski napisał: Tym niemniej - dane na pewno są dobre, a wyniki z widoku złe, bo dwa teoretycznie tożsame zapytania w tej samej bazie dają dwa różne wyniki. Nie powtarzam problemu na podmiocie demo, zarówno konwertowanym jak i nowym, więc jak napisałem w pierwszej odpowiedzi - należy sprawdzić co się u Pana dzieje - skoro "zagląda" Pan sam do bazy danych to niestety "wszystko jest możliwe". Link to postu
Kamil Goleń 115 Napisano 22 Kwietnia 2020 Udostępnij Napisano 22 Kwietnia 2020 w vwPolaWlasne_Towar Nic nie zmienialiśmy z tym widokiem. Zawsze może Pan wysłać do nas bazę danych sprzed konwersji w celu analizy. Link to postu
Przemysław Kwiatkowski 9 Napisano 22 Kwietnia 2020 Autor Udostępnij Napisano 22 Kwietnia 2020 w vwPolaWlasne_Towar 40 minut temu, Kamil Goleń napisał: Nic nie zmienialiśmy z tym widokiem. Dziękuję. W takim razie mogłem spokojnie przywrócić wersję sprzed konwersji. Działa. ? Ciekawostka: tekst widoku po odszyfrowaniu był zupełnie poprawny ("SELECT * FROM tw__Towar LEFT JOIN pw_Dane ON tw_Id = pwd_IdObiektu AND pwd_TypObiektu = -14"), ale ewidentnie działał źle. Serwer dawał inną odpowiedź zapytany "o widok", a inną wprost z tabel z powyższego selecta. Nadpisanie treści widoku (alter view) tym samym kodem naprawiło problem. To bardzo dziwne zachowanie i zastanawiam się jak sprawdzić czy nie ma więcej takich kwiatków... Acha, kontrola bazy w programie serwisowym nic nie wykazała. Jedynym sensownym wyjaśnieniem, jakie przychodzi mi do głowy jest, że serwer prawdopodobnie przechowuje kod w postaci skompilowanej (?) i nadpisanie wymusiło ponowną kompilację tego samego kodu - tym razem już bez błędu. Ale jak to możliwe, że serwer przy poprzedniej kompilacji (kiedy? przy konwersji?) mógł się "pomylić"? (Hm... neutrina ze słońca...?) Link to postu
Przemysław Kwiatkowski 9 Napisano 22 Kwietnia 2020 Autor Udostępnij Napisano 22 Kwietnia 2020 w vwPolaWlasne_Towar 1 godzinę temu, Daniel Kozłowski napisał: Na prawdę muszę pisać co należy robić w takich sytuacjach i jak być do nich przygotowanym ? Wieloletnia praktyka wykazała, że nigdy nie było potrzeby odszyfrowywania kodu. Po co więc miałbym się tego uczyć na wszelki wypadek z góry? Teraz już umiem. ? Rozwiązywanie problemów wygląda u mnie mniej więcej tak: 1. Sam rozwiązuję, bo tak jest najszybciej, a znam swoje umiejętności i im ufam. 2. Sprawdzam na forach, bo tam jest dużo wiedzy dostępnej od ręki. 3. Pytam na forach, bo praktyka wykazała, że daje to wymierne efekty. 4. Dzwonię do serwisanta, co zajmuje na ogół najwięcej czasu. Do czwartego punktu rzadko dochodzę, ale za to ostatnio usłyszałem od niego "Panie Przemku, skoro Pan dzwoni, to znaczy że zadanie jest trudne". ? I w zasadzie każdy powinien mieć identyczny schemat postępowania - łącznie z punktem pierwszym, choć każdy indywidualnie powinien ustawić granicę na owe "umiejętności". ? Link to postu
Daniel Kozłowski 1 161 Napisano 22 Kwietnia 2020 Udostępnij Napisano 22 Kwietnia 2020 w vwPolaWlasne_Towar 1 godzinę temu, Przemysław Kwiatkowski napisał: 2 godziny temu, Kamil Goleń napisał: Nic nie zmienialiśmy z tym widokiem. Dziękuję. W takim razie mogłem spokojnie przywrócić wersję sprzed konwersji. Działa. ? Ciekawostka: tekst widoku po odszyfrowaniu był zupełnie poprawny ("SELECT * FROM tw__Towar LEFT JOIN pw_Dane ON tw_Id = pwd_IdObiektu AND pwd_TypObiektu = -14"), ale ewidentnie działał źle. Serwer dawał inną odpowiedź zapytany "o widok", a inną wprost z tabel z powyższego selecta. Nadpisanie treści widoku (alter view) tym samym kodem naprawiło problem. To bardzo dziwne zachowanie i zastanawiam się jak sprawdzić czy nie ma więcej takich kwiatków... Tak, to zastanawiające zachowanie. 1 godzinę temu, Przemysław Kwiatkowski napisał: Acha, kontrola bazy w programie serwisowym nic nie wykazała. Zadaniem kontroli danych jest praktycznie tylko kontrola identyfikatorów/kluczy głównych tabel, więc w tym przypadku nie miała zastosowania. 1 godzinę temu, Przemysław Kwiatkowski napisał: 2 godziny temu, Daniel Kozłowski napisał: Na prawdę muszę pisać co należy robić w takich sytuacjach i jak być do nich przygotowanym ? Wieloletnia praktyka wykazała, że nigdy nie było potrzeby odszyfrowywania kodu. Po co więc miałbym się tego uczyć na wszelki wypadek z góry? Teraz już umiem. ? Nie pisałem o odszyfrowywaniu obiektów bazy danych tylko ogólnie o zagłębianie się w tego typu techniczne informacje, a już każdy sam musi zdecydować czym się chce zajmować, czego się uczyć i kiedy, a co zlecić innej firmie, która się w tym specjalizuje - moja wieloletnia praktyka pokazała, że taka wiedza jest jest niezbędna/bardzo się przydaje w mojej pracy i jak najwięcej staram się dowiedzieć wcześniej (z góry), aby móc tę wiedzę wykorzystać do jak najszybszej analizy problemu i jego rozwiązania. 1 godzinę temu, Przemysław Kwiatkowski napisał: Rozwiązywanie problemów wygląda u mnie mniej więcej tak: 1. Sam rozwiązuję, bo tak jest najszybciej, a znam swoje umiejętności i im ufam. 2. Sprawdzam na forach, bo tam jest dużo wiedzy dostępnej od ręki. 3. Pytam na forach, bo praktyka wykazała, że daje to wymierne efekty. 4. Dzwonię do serwisanta, co zajmuje na ogół najwięcej czasu. Do czwartego punktu rzadko dochodzę, ale za to ostatnio usłyszałem od niego "Panie Przemku, skoro Pan dzwoni, to znaczy że zadanie jest trudne". ? Niestety ten przykład pokazał, że należy te kroki zweryfikować i się do nich stosować - dotarł Pan do punktu 3, zasugerowałem kierunek poszukiwań, według mnie należało wtedy wrócić do punktu 1 lub przejść do 4. 1 godzinę temu, Przemysław Kwiatkowski napisał: I w zasadzie każdy powinien mieć identyczny schemat postępowania - łącznie z punktem pierwszym, choć każdy indywidualnie powinien ustawić granicę na owe "umiejętności". ? Zgadzam, się podkreśleniem wyróżnionego fragmentu Link to postu
Polecane posty