Konwersja typu danych varchar na typ danych smalldatetime PROBLEM

0

Mam dość ciekawy problem z datą (datetime i smalldatetime) w SQL Server:

Proste zapytanie:

INSERT INTO list (enddate) VALUES ('2019-10-24 10:05')

I teraz:
W SQL Server 14.00.3038 gdy wykonujemy tą komendę przez PDO PHP lub SQL Managment to jest OK
W SQL Server 13.00.1742 gdy wykonujemy tą komendę przez SQL Managment to jest OK ale gdy wykonujemy przez PDO PHP to otrzymuje

SQLSTATE[22007]: [Microsoft][ODBC Driver 17 for SQL Server][SQL Server]Konwersja typu danych varchar na typ danych smalldatetime spowodowała utworzenie wartości leżącej poza zakresem.

Zmiana typu na smaldatetime2 rozwiązuje problem ale jest to dość zastanawiające, wygląda jakby ODBC Driver 17 for SQL Server w połączeniu do SQL Server 14.00.3038 miał tu jakiegoś buga, to dość niebezpieczne bo po aktualizacji SQL, aplikacje działające na php pdo się wywalą,

A może odpowiada za to jakieś ustawienie bazy ? mieliście podobny problem ?

Pozdrawiam.

0

A jak zadasz to pytanie w ten sposób:

INSERT INTO list (enddate) VALUES (convert(datetime,'2019-10-24 10:05',121))
0

Jak przekonwertuje wg twojego sposobu to działa, lecz nie chciałbym w przyszłości zmieniać wszystkich zapytań w ten sposób.
Dlaczego '2019-10-24 10:05' nie mieści się w typie datetime w tym akurat zestawieniu (php pdo, sql13) ?

edit:

Jak dam '2019-10-12 10:05' to DZIAŁA : wygląda jakby sql zamieniał miesiąc z dniem i tym sposobem faktycznie nie ma 13 czy 24 miesiąca, orientuje się ktoś gdzie się to konfiguruje ?

edit2:

Nie ma siły, to musi być jakiś bug, gdy insertuje do pola datetime to wygląda że sql myli dzień z miesiącem, gdy insertuje do datetime2 to wszystko jest porządku i poprawnie zapisuje date.

0

Dataime i datetime2 róznią sie zakresem pierwszy startuje od 1753 roku drugi od 1. Dodatkowo zależnie od typu danych, stringi mogą być róznie interpretowane...

Pamietaj, że ty przekazujesz string a baza go interpretuje wg. swoich ustawień lokalnych, aby mieć pewnośc, że jest ok, przy aktualizacji/dodawaniu/szukaniu danych z datami używaj zapisu ISO 8601, takie stringi są interpretowane nizależnie od formatu daty na serwerze.

Czyli (przetestuj nie mam PHP z MsSQL)

INSERT INTO list (enddate) VALUES ('2019-10-24T10:05:00')

Powinno zadzialać bezboleśnie

Szczegóły: https://docs.microsoft.com/en-us/sql/t-sql/statements/set-dateformat-transact-sql?view=sql-server-ver15

0

Insert z formatem ISO 8601 działa. Lecz od wielu lat na wielu wersjach sql poprawnie działał też zapis standardowy tzn '2018-12-03 10:33', doświadczeni programiści też przekazywali datę w ten sposób i te projekty działały, coś musiało się zbugować w między czasie, w mojej instancji sql server 2017 działa po staremu.

Jeśli wykonuje tego problematycznego inserta przez sql managment studio czy przez sql manager to też działa ok, więc prawdopodobnie problem leży w sterowniku PDO sql w połączeniu z bazą SQL 2016, lub jakiś ustawieniach środowiskowych bo z 2017 już działa ok.

Dobrze że problem wyszedł na teście a nie na produkcji :)

1

Co zwraca zapytanie:

select  @@LANGUAGE  

Na "dobrej" i "złej" maszynie

UPDATE:
Jeszcze to

DBCC useroptions
0

Dobry trop:

DBCC USEROPTIONS;

DZIAŁAJĄCY
textsize -1
language us_english
dateformat mdy
datefirst 7

NIE DZIAŁAJĄCY
textsize -1
language polski
dateformat dmy
datefirst 1

Wygląda na to że w ustawieniach globalnych wystarczyło zmienić język usera na ** angielski. **
Nie przyszło mi na myśl że to będzie miało wpływ na interpretację zapytań do sql w temacie daty.

Dziękuje @Panczo za pomoc.

1 użytkowników online, w tym zalogowanych: 0, gości: 1