Nic nie szkodzi, że ich baza jest w formacie DBF, a więc nieco zatęchła, niemniej wymienność istnieje, bo ktoś mądry wpadł kiedyś na pomysł stworzenia instytucji driverów. Ich szef bąkał najpierw coś o wymianie na poziomie plików tekstowych, ale z miejsca go zmyłem, traktując koncepcję jak bredzenie przedszkolaka o seksie. Wobec tego rzucili się na głębokie wody, zaprzęgając do roboty jakże pomocny w wymianie danych mechanizm DTS (Data Transformation Services) dostępny na MS SQL Server.

Pewnie nie byłoby ambarasu, gdybym nie utrzymywał poziomu bezpieczeństwa zalecanego przez Microsoft. Otóż stosuję na serwerze SQL autentykację na poziomie Windows, zalecaną zawsze gdy tylko możliwe, w przeciwieństwie do alternatywnego sposobu, jakim jest autentykacja na poziomie SQL, która w zasadzie może być używana tylko w przypadkach, gdy klient nie ma możliwości zalogowania się do domeny Windows, a więc np. przy dostępie z Internetu. Projektując pakiet w DTS, określamy sposób weryfikacji użytkownika na wejściu i wyjściu. Jest jednak pewien szkopuł, bowiem łącząc dwa serwery, z których jeden ma autentykację typu Windows, należy zapewnić, aby na obu był ten sam domenowy użytkownik, na konto którego uruchamia się zadanie i który może być uwierzytelniony przez system operacyjny. Planując zadanie w DTS, nie ma możliwości wskazania, na czyje konto jest ono wykonywane (w przeciwieństwie np. do usług typu "zaplanowane zadania" systemu Windows), jedyną możliwością obejścia jest więc aby zweryfikowany użytkownik był stale zalogowany, co raczej nie jest poprawnym rozwiązaniem, albo też uruchamianie pakietu DTS jako wsadowego (DTSRUN) i zaplanowanie go jako zadania Windows na konto wskazanego użytkownika.

Panowie raczyli zmitrężyć nad tym tydzień. Co rusz przychodzili do mnie, twierdząc, że jednak będą musieli wybrać inną metodę, bo to im nie idzie. Ja im perswadowałem, jak mogłem, żeby nie powątpiewali i nie zbaczali z raz obranego kursu, podsuwając im małymi kroczkami kolejne podpowiedzi. Nie kwapiłem się do przedstawienia gotowego rozwiązania końcowego, bo, po pierwsze, nic tak dobrze nie zapada w pamięć, jak nauka na własnych błędach, a po drugie, to była ich działka, za którą mieli otrzymać wynagrodzenie, po trzecie, nie prosili mnie nawet o to. Wszelka pomoc ode mnie płynąca wynikała z pobudek czysto humanitarnych, bowiem żal mi, gdy ktoś za bardzo się męczy. W międzyczasie, po cichu, wypróbowałem cały scenariusz, upewniając się na sto procent, że działa. Zajęło mi wszystkiego z godzinę. Dnia siódmego już nieco zniecierpliwiony zaszedłem do nich, pokazując i uruchamiając na ich serwerze wszystko krok po kroku. Okazało się, że jednak może działać. Pożegnałem ich słowami: "a teraz zapakujecie to w plik wsadowy, ustawicie czasy wykonania i konto użytkownika". W dniu ósmym widzę, że jednak nie sprawili się. Ich szef otrzymuje ode mnie monit i przychodzi na rozmowę.

Zarzuca mi, że męczą się od trzech dni (sic!) i to nie ich wina, tylko ja im nie udostępniłem zasobów. Wyrzucam go z pokoju.

Nie oczekiwałem, że ktoś mi podziękuje za wspomaganie. Nie twierdzę, że każdy musi działać sprawnie i nie popełniać błędów. Nie odżegnuję się od pomocy za "Bóg zapłać" - wystarczy poprosić. Jednak do szewskiej pasji doprowadza mnie wykręcanie kota ogonem, wmawianie prosto w oczy nieprawdy, przerzucanie winy na innych, zaprzeczanie oczywistym faktom - a wszystko w imię ratowania twarzy wobec osób postronnych.

"Ludzie znają dziś cenę wszystkiego, nie znając wartości niczego" - napisał już ponad sto lat temu Oskar Wilde.

I nic się nie zmieniło, niestety.