InsERT GT => Subiekt GT => Wątek zaczęty przez: pucio12 w Grudzień 06, 2015, 23:37:07
-
Mam problem jak w personelu zaznaczam pracownika jako nie aktywnego gdy zatwierdzam zmianę dostaje komunikat "błąd zapisu do bazy danych, dane zostały zmienione w tle", wszystko inne mogę zmienić bez problemu (uprawnienia itp.). Nikt inny nie jest podłączony do subiekta, po włączeniu programu od razu włączyłem personel i próbowałem robić zmiany.
O co tu chodzi ? Pomocy.
-
Były instalowane jakieś dodatki, które ingerują w bazę danych?
Co pokaże następujące zestawienie?
SELECT
sysobjects.name AS trigger_name
,OBJECT_NAME(parent_obj) AS table_name
FROM sysobjects
INNER JOIN sys.tables t
ON sysobjects.parent_obj = t.object_id
WHERE sysobjects.type = 'TR'
AND OBJECT_NAME(parent_obj)='pd_uzytkownik'
-
trigger_name table_name
zzz_tr_del_pd_uzytkownik pd_Uzytkownik
zzz_tr_ins_pd_uzytkownik pd_Uzytkownik
tr_pd_Uzytkownik pd_Uzytkownik
tr_pd_Uzytkownik_Inserting_Updating pd_Uzytkownik
pd_Uzytkownik_DodajUzRok pd_Uzytkownik
pd_Uzytkownik_DodajUzOkr pd_Uzytkownik
tr_pd_Uzytkownik_update pd_Uzytkownik
pd_Uzytkownik_DodajUzMag pd_Uzytkownik
-
Masz /próbowałeś rozwiązania dodatkowego. Czy nie był to "Detektyw"? Nie pamiętam teraz kto używa" zzz-tów"
-
Ja nic nie kombinowałem z żadnymi dodatkami w tej sprawie.
Do subiekta jest używany dodatek FirmesLink do integracji ze sklepem internetowym ale to raczej nie ma wiele wspólnego z personelem (ale oczywiście mogę się mylić).
Po prostu potrzebuje zmniejszyć listę osób przy logowaniu do subiekta.
-
Nie wiem czy kombinowałeś czy też nie, ale tak jak napisał @candy - te triggery zaczynające się na zzz są przez kogoś dopisane
Ten tr_pd_Uzytkownik_update też mi nie pasuje.
Rozwiązaniem jest zajrzenie do triggerów i sprawdzenie co z nimi jest nie tak jak trzeba.
-
Ja nic nie kombinowałem z żadnymi dodatkami w tej sprawie.
Sam "dostarczyłeś dowodów", że były uruchamiane na podmiocie inne rozwiązania ;)
Ten tr_pd_Uzytkownik_update też mi nie pasuje.
Z tego co zajrzałem to wygląda na to, że pochodzi on z Mobilnego Subiekta.
-
Jeszcze coś.
Oprócz ekstra triggerów "zzz_coś-tam-coś-tam", których nie ma w standardzie w Twojej bazie coś zjadło trigger "tr_pd_Uzytkownik_Deleting".
Krótko mówiąc, jak napisał Daniel - w bazie było grzebane.
Ja zacząłbym od kontaktu z autorem/dostawcą FirmesLinka, który powinien wiedzieć bez specjalnego dochodzenia co zrobił jego dodatek, a czego nie.
-
Problem występował zanim został uruchomiony FirmesLink wiec to coś wcześniej musiało się stać no naprawdę super, a nie mam pojęcia kto wcześniej grzebał i po co.
A nie ma jakiejś innej możliwości wyłączenia pokazywania użytkowników przy logowaniu bez kompleksowego rozwiązywania problemów w bazie. Zapisanie bezpośrednio do bazy informacji o nie aktywnym użytkowniku ?
A jeszcze zauważyłem, miałem kilku nie aktywnych użytkowników jak jednego zaznaczyłem jako aktywnego to zapisało się bez problemu ale ponowne odhaczenie jako nie aktywny zwróciło błąd jak w temacie.
-
A nie ma jakiejś innej możliwości wyłączenia pokazywania użytkowników przy logowaniu bez kompleksowego rozwiązywania problemów w bazie. Zapisanie bezpośrednio do bazy informacji o nie aktywnym użytkowniku ?
Można zrobić tak jak napisałeś - bezpośrednio zmienić dane w bazie danych.
-
A nie ma jakiejś innej możliwości wyłączenia pokazywania użytkowników przy logowaniu bez kompleksowego rozwiązywania problemów w bazie.
Tak jak napisał Daniel można.
Zamiast naprawiać spłuczki można przecież spłukiwać WC wiaderkiem ;)
"Na teraz" każde rozwiązanie dobre, które zadziała, ale ogólnie problemy w bazie lepiej usuwać zanim narosną, a nie dopiero kiedy już zupełnie nie można sobie z nimi poradzić.
-
Moje pytanie zawierało podtekst "jak się nazywa pole odpowiedzialne za aktywny/nie aktywny użytkownik" :)
-
uz_Status
-
Dzięki ale jestem jełop wczoraj przeglądałem dokumentację i tego nie znalazłem a jest i pisze jak byk.
Teraz po próbuję zobaczymy co z tego wyjdzie, może nie wybuchnie.
-
Jak zobaczysz co wyjdzie to się podziel wynikami.
-
Jest jak chciałem mam nadzieje że nic więcej się nie porąbało ale w sumie to nie powinno.
oczywiście poleciałem lenistwem i zrobiłem tak:
update pd_Uzytkownik set uz_Status = '0'
update pd_Uzytkownik set uz_Status = '1' where uz_Id = '1' - szef żebym mógł się zalogować
nie chciało mi się klepać 80 linijek z czego aktywnych miało zostać tylko 15. Aktywowałem ich z poziomu subiekta bez problemu.
tak dla sprawdzenia spróbowałem deaktywować ale dalej to samo błąd zapisu trudno trzeba będzie się za to kiedyś zabrać.
Na razie zrobiłem to na bazie testowej jak koś ma obiekcje do tego to proszę informację.
-
Witam. Miałem ten sam błąd. Firma polecana przez Inserta stwierdził błąd bazy danych przez zewnętrzną aplikację. Już miałem oddać bazę danych do naprawy a błąd sam ustąpił po ostatniej aktualizacji Subiekta do wersji 1.42 HF1
-
Taki komunikat może wiele przyczyn, więc jeśli nie została znaleziona przyczyna w Twoim przypadku to nie możesz stwierdzić, że miałeś ten sam błąd - miałeś jedynie taki sam komunikat błędu... Niestety na bazach danych zna się na prawdę niewiele osób.
-
Pierwsze udzielenie się na forum a już zostałem zrugany ;) Wskazałem tylko rozwiązanie, które u mnie wyeliminowało błąd - sorry komunikat błędu dzięki czemu nie poniosłem kosztów 360pln i może też uchronię przed tym kolegę, który umieścił zapytanie.
-
Nie zostałeś zrugany, tylko wyjaśniono Ci że wyciągasz nieuprawnione wnioski.
Może zaoszczędziłeś, może odłożyłeś wydatki na później, tego nie wiemy. Co do zasady "przyklepywanie sprawy" bez usunięcia przyczyny problemu opłaca się słabo, ale czasem można mieć szczęście.