Łączyć Microsoft SQL Server do Excela, Arkuszy Google, AI i REST

Wdrożony w sposób, w jaki faktycznie działa SQL Server

Rzeczywiste przypadki rzadko są tak uporządkowane, jak domyślne. Szczegóły połączenia obejmują rzeczywiste ustawienia użytkowników, a nie te zawarte w dokumentacji.

• Nazwane instancje znajdują się w polu serwera jako SERVER\SQLEXPRESS lub SERVER\PROD. Nie ma osobnego pola do wyszukiwania ani portu do podania, chyba że został on przeniesiony.
• Zakłada się, że port 1433 jest portem 1433 i całkowicie go pomija w ciągu połączenia; wszystkie inne są używane bez zmian, więc wystąpienie portu 1435 nie wymaga niczego specjalnego.
• Jedno połączenie dotyczy jednej bazy danych, a kilka baz danych na tej samej instancji to po prostu kilka połączeń — każdy z własnym loginem i uprawnieniami, jeśli tak działa Twój sklep.
• Możesz skonfigurować szyfrowanie oraz określić, czy chcesz ufać certyfikatowi podpisanemu własnoręcznie.
• Uwierzytelnianie to uwierzytelnianie SQL Server — login i hasło. Uwierzytelnianie Windows i Microsoft Entra nie jest obsługiwane, a jeśli Twoja instancja jest ustawiona tylko na Windows, test połączenia to wykryje, zamiast niejasno zakończyć się niepowodzeniem.

Co dokładnie robi z Twoją instancją

Każdy, kto opiekuje się produkcyjnym serwerem SQL Server, będzie chciał wiedzieć, ile kosztuje nowy czytnik. Krótka odpowiedź: jedno połączenie na raz i nic nie zostanie pominięte.

• Pula połączeń jest celowo wyłączona. Żadna pula bezczynnych sesji nie gromadzi się w Twojej instancji między zapytaniami, co jest odwrotnością tego, co robi większość narzędzi do raportowania.
• Anulowanie faktycznie anuluje. Po zatrzymaniu zapytania, informacja o anulowaniu jest wysyłana do serwera SQL Server, co kończy wykonywanie. — zamiast tego, aby klient odszedł i zostawił serwer pracujący nad wynikiem, którego nikt nie przeczyta.
• Dostępność jest sprawdzana przed próbą logowania, więc nieprawidłowa nazwa hosta lub zamknięty port zostaną zgłoszone jako błąd sieciowy, zamiast zostać odnotowane jako nieudane logowanie w dzienniku błędów — co ma znaczenie, jeśli masz zasady blokowania.
• Limity czasu są jasno określone: domyślnie 30 sekund na połączenie i 35 sekund na rozpoczęcie zwracania zapytania. Długie wyniki są przesyłane strumieniowo tak długo, jak to konieczne.

Typy T-SQL, które przetrwają podróż

Wprowadzanie danych z SQL Server do arkusza kalkulacyjnego to obszar, w którym precyzja zazwyczaj po cichu zanika. To są przypadki, z którymi poradzono sobie celowo.

• datetimeoffset zachowuje swoją wartość natychmiastową, znormalizowaną do czasu UTC, zamiast być spłaszczonym do lokalnego czasu zegara ściennego, który nic nie znaczy dla kolejnego czytelnika.
• Liczby dziesiętne i numeryczne zachowują swoją precyzję i skalę. Poza tym, co mieści się w arkuszu kalkulacyjnym, wartość jest przekazywana jako dokładny tekst, a nie po cichu zaokrąglana. — złe pieniądze są gorsze niż niewygodne pieniądze.
• pieniądze i drobne kwoty pojawiają się jako dokładne liczby dziesiętne, a nie jako liczby zmiennoprzecinkowe.
• rowversion i timestamp są postrzegane jako osiem bajtów, którymi są w rzeczywistości, zamiast być mylone z datą, co jest najczęstszym powodem błędnego odczytywania tych kolumn.
• uniqueidentifier staje się ciągiem GUID złożonym z małych liter, a sql_variant i hierarchyid stają się czytelnym tekstem, zamiast zostać pominięte.

-- Niewygodne typy, obsługiwane zamiast przybliżane SELECT o.OrderId, o.PlacedAt, -- datetimeoffset -> UTC instant o.RowVersion, -- rowversion -> 8 bajtów, nie data o.Amount, -- money -> dokładna wartość dziesiętna o.LedgerBalance -- decimal(38,10) -> tekst bezstratny FROM dbo.Orders AS o WHERE o.PlacedAt >= DATEADD(day, -30, SYSUTCDATETIME()) ORDER BY o.PlacedAt DESC;