InsERT GT => Subiekt GT => Wątek zaczęty przez: micha w Grudzień 17, 2015, 08:41:06
-
Matka Boska mnie nie lubi:
Nie powiodło się wykonanie polecenia:
EXECUTE #add_sl_KalendWyjatek_1_42 @aId = 4 ,@aIdKalend = 3,@aIdAtrybut = NULL,@aData = '2016-08-15 00:00:00.000',@aNazwa = 'Wniebowzięcie Najświętszej Marii Panny' , @aRodzaj =2 , @aIleDziennie =0 , @aIleNocne =0 , @aUstawowy =1
Błąd 0x80040E07: Error converting data type varchar to datetime.
Aktualizacja podmiotu nie powiodła się: 0x80040e07: Error converting data type varchar to datetime.
Co teraz? Ratujcie dobrzy ludzie. :-)
-
Matka Boska mnie nie lubi:
Nie, po prostu sam prosisz się o problemy...
Co teraz? Ratujcie dobrzy ludzie. :-)
Sprawdź ustawienia regionalne w systemie operacyjnym, zwłaszcza format daty.
-
Czy udało się rozwiązać ten problem? u mnie się pojawia informacja że "baza podmiotu jest konwertowana" po aktualizacji dostaję komunikat: "aktualizacja bazy nie powiodła się", w logu pojawia się taka informacja:
"Nie powiod≥o siÍ wykonanie polecenia:
EXECUTE #add_sl_KalendWyjatek_1_42 @aId = 4 ,@aIdKalend = 3,@aIdAtrybut = NULL,@aData = '2016-08-15 00:00:00.000',@aNazwa = 'WniebowziÍcie NajúwiÍtszej Marii Panny' , @aRodzaj =2 , @aIleDziennie =0 , @aIleNocne =0 , @aUstawowy =1
B≥πd 0x80040E07: B≥πd podczas konwertowania typu danych varchar na datetime.
Aktualizacja podmiotu nie powiod≥a siÍ: 0x80040e07: B≥πd podczas konwertowania typu danych varchar na datetime.
PrzywrÛcenie podmiotu powiod≥o siÍ."
ktoś ma jakąś radę na taki przypadek? zresetowałem ustawienia daty nic nie pomogło. baza jest zainstalowana na windows serwer 2012 R2.
-
Czy udało się rozwiązać ten problem?
Przeprowadziłem konwersję za pomocą programu serwisowego, a nie przy uruchamianiu Subiekta, oraz przy użyciu autentykacji Windows, a nie poprzez serwer sql. Powiodło się. (Także mam 2012 R2.)
-
To nie jest problem ustawienia daty.
Występuje to już w zbyt wielu przypadkach. Raczej jest błąd w dopisaniu nowego święta do słownika.
-
Dla mnie cały czas wskazuje to ewidentnie na problem z ustawieniami regionalnymi, jak widać błąd ujawnia się tylko w niektórych środowiskach (zmiana sposobu logowania do serwera SQL może zmienić kontekst użytkownika w systemie operacyjnym).
-
Dla mnie cały czas wskazuje to ewidentnie na problem z ustawieniami regionalnymi, jak widać błąd ujawnia się tylko w niektórych środowiskach (zmiana sposobu logowania do serwera SQL może zmienić kontekst użytkownika w systemie operacyjnym).
Sprawdzałem wpisy regionalne w rejestrze i dla wszystkich użytkownikow sa prawidłowe, a problem i tak występuje.
A po drugie, co zrobić jak autentykacja windows jest wyłączona? I nie chcę jej włączać.
-
Dla mnie cały czas wskazuje to ewidentnie na problem z ustawieniami regionalnymi, jak widać błąd ujawnia się tylko w niektórych środowiskach (zmiana sposobu logowania do serwera SQL może zmienić kontekst użytkownika w systemie operacyjnym).
Sprawdzałem wpisy regionalne w rejestrze i dla wszystkich użytkownikow sa prawidłowe, a problem i tak występuje.
A po drugie, co zrobić jak autentykacja windows jest wyłączona? I nie chcę jej włączać.
Na jakim użytkowniku Windows pracuje serwer SQL, z jakiej autentykacji korzystasz ?
-
Jeszcze jedno - w jakiej wersji językowej były "instalowane" systemy operacyjne ?
-
Dla mnie cały czas wskazuje to ewidentnie na problem z ustawieniami regionalnymi, jak widać błąd ujawnia się tylko w niektórych środowiskach (zmiana sposobu logowania do serwera SQL może zmienić kontekst użytkownika w systemie operacyjnym).
Sprawdzałem wpisy regionalne w rejestrze i dla wszystkich użytkownikow sa prawidłowe, a problem i tak występuje.
A po drugie, co zrobić jak autentykacja windows jest wyłączona? I nie chcę jej włączać.
Na jakim użytkowniku Windows pracuje serwer SQL, z jakiej autentykacji korzystasz ?
Z autentykacji uzytkownika sql, nie sa, który jest zablokowany.
-
Jeszcze jedno - w jakiej wersji językowej były "instalowane" systemy operacyjne ?
Pl.
-
Jeszcze jedno - w jakiej wersji językowej były "instalowane" systemy operacyjne ?
Ważny jest język ustawiony w użytkowniku sql. Niby proste, ale trudniejsze do znależienia.
-
Jeszcze jedno - w jakiej wersji językowej były "instalowane" systemy operacyjne ?
Ważny jest język ustawiony w użytkowniku sql. Niby proste, ale trudniejsze do znależienia.
To teraz jak na "spowiedzi" - kto i po co dotykał loginów ? ;)
-
Jeszcze jedno - w jakiej wersji językowej były "instalowane" systemy operacyjne ?
Ważny jest język ustawiony w użytkowniku sql. Niby proste, ale trudniejsze do znależienia.
To teraz jak na "spowiedzi" - kto i po co dotykał loginów ? ;)
Domyślnie login do sql jest jeden - sa, i w dodatku bez hasła. Zostawiasz tak?
-
No ale co ma hasło do języka ?
-
No ale co ma hasło do języka ?
sa nic.
Ale dodając nowy login utworzył się z ustawionym polskim, a tego nawet nie sprawdzałem.
Tym bardziej, że od wielu lat i wersji nigdy nie było z tym problemów.
-
To wszystko tylko dowodzi, że każda informacja ma znaczenie, a wiele takich informacji nie da się lub jest bardzo ciężko dostrzec przez forum.
-
U mnie dodanie użytkownika domeny (autentykacja Windows była włączona) nie pomogło. Przestawiłem temu użytkownikowi domyślny język z polskiego na angielski i to się okazało rozwiązaniem. Prawdopodobnie gdyby userowi SA ustawić język angielski, to zadziałałoby i na nim.
-
U mnie dodanie użytkownika domeny (autentykacja Windows była włączona) nie pomogło. Przestawiłem temu użytkownikowi domyślny język z polskiego na angielski i to się okazało rozwiązaniem. Prawdopodobnie gdyby userowi SA ustawić język angielski, to zadziałałoby i na nim.
sa nie jest userem windows, tylko SQL Server, a to dwie zupelnie inne sprawy. I dmyślnie sa ma ustawiony język angielski.