Pisząc makro w VBA chciałem żeby zmienna była widoczna nie tylko w ramach jednej procedury, ale także między nimi. Niekoniecznie zależało mi przy tym, aby zmienna była widoczna poza jednym modułem (czyli aby była publiczna lub globalna).

Próbowałem zadeklarować zmienną na zewnątrz procedury, ale to nie pomagało.

Okazuje się, że owszem wytarczy deklaracja zmiennej na zewnątrz procedury, ale MUSI się ona znajdować w części deklaracyjnej:

http://msdn.microsoft.com/en-us/library/office/gg264241(v=office.15).aspx

Załóżmy, że chcesz eksportować dane do excela, ale za każdym razem ma powstawać plik z nową nazwą. Nazwa może wynikać np z wartości parametru generowanego podczas pętli (patrz poprzedni wpis).

Samo przepisywanie danych ze źródła do celu to nic. Umieszczasz w Data Flow Tasku Data Source wskazujące np na SQL Server, definiujące zapytanie pobierające dane z SQL. Umieszczasz też excel destination. Podczas edytowania excel destinantion musisz podać nazwę pliku. Ta nazwa pliku potrzebna jest na czas developmentu paczki. Podczas uruchomienia będzie w locie zamieniana na inną wartość.

Jak zmienić tę stałą nazwę pliku? Podczas tworzenia Excel destination musiałeś zdefiniować Excel connection managera. Kliknij na nim i w okienku właściwości poszukaj wałaściwości Expressions:

Czytaj dalej »

Należało wyeksportować dane dla każdego pracownika do osobnego pliku. Ponieważ lista pracowników jest dość długa, aż prosi się o skorzystanie z paczki SSIS.

Zaczynamy od zdefiniowania listy pracowników gdzieś na serwerze SQL:

Tabela names zawiera kolumnę name, a wartości w niej znajdujące się to imiona (nazwiska, czy jakakolwiek inna informacja o pracowniku).

Budujemy projekt SSIS, a w nim umieszczamy i łączymy:

Najpierw task „Execute SQL Task”. Należy zmienić: Czytaj dalej »

Polecenie:

Get-Item C:\windows\system32\vbscript.dll | select -expand VersionInfo | select ProductVersion

zwraca:

ProductVersion
————–
5.8.7601.16978

Tymczasem eksplorator plików we właściwościach pokazuje:

Kto ma rację!? Tym bardziej, że czasami (dla większości plików) obie wersje się zgadzają! Czytaj dalej »

Jeżeli masz ten błąd to najprawdopodobniej… nie udaje się konwersja napisu na datę… Wiem, Ameryki nie odkryłem, ale sam ostatnio ugrzązłem w takim problemie. Serwer SQL z rosyjskim collation, laptop polski, SQL Server angielski i jak tu konwertować daty, panie premierze!?

Przyczyna:

Wysyłasz datę w formacie np. 20.12.2014, tymczasem podczas konwersji SQL lub SSIS lub jeszcze inne narzędzie zakłada, że data jest w formacie MM/DD/YYYY i klapa…

Rozwiązanie:

Wysyłaj daty w odpowiednim formacie…

Obejście:

1. Wysyłaj daty w formacie, co do którego inne narzędzia nie mają wątpliwości jak je parsować:

• YYYY-MM-DD – rok na początku (4 cyfry) myślnik jako znak rozdzielający
• YYYYMMDD – format ISO, bez żadnych znaków rozdzielających

2. Trochę szalone, ale co tam: konwertuj daty do napisów, a potem dalej pracuj na napisach. Np. w SQL użyj funkcji YEAR lub złożonego LEFT i CONVERT:

SELECT LEFT(CONVERT(NCHAR(50),GETDate(),102),4) –napis, który zawiera rok z daty

SELECT YEAR(GETDATE()) –liczba będąca rokiem

Tego typu zabawy pomogły mi znaleźć miejsce, gdzie daty rzeczywiście niepoprawnie były rozumiane podczas uruchomienia pakietu. A potem zostało już wyprowadzenie problemu. Jeśli wiesz co zepsuło działanie masz już 50% drogi do jego rozwiązania!

Prosty pakiet i podczas wykonania błąd: The value could not be converted because of a potential loss of data.

No jak to!? Przecież piszę do Excela, a komórki nie mają ustalonego rozmiaru! Cokolwiek wpiszę to, excel przyjmuje. Przecież to nie baza danych, gdzie każda kolumna musi mieć ustalony rozmiar! Zobaczmy to dokładniej:

• Kliknij prawym przyciskiem na OLE DB Source, wybierz „Advanced editor”
• Przejdź na zakładkę Input and Output Parameters
• Rozwiń OLE DB Source Output >> Output Columns >> Wybierz kolumnę i sprawwdź właściwość LENGHT Czytaj dalej »

Od lat kiedy chciałeś stworzyć pakiet Integration Services lub raport w Reporting Services lub kostkę w Analysis Services, korzystałeś z Visual Studio i dostępnych w nim szablonów, które pojawiały się po wykonaniu instalacji SQL Server z zaznaczonymi opcjami BIDS (Business Inteligence Development Studio – do SQL 2008 R2) lub SSDS (SQL Server Data Tools w wersji 2012). Jeśli na maszynie Visual Studio nie było zainstalowane, to instalator SQL doinstalowywał je.

Od wersji 2014 ten mechanizm się zmienia. SSDT nie instaluje się podczas standardowej instalacji. Pakiet należy ściągnąć. Do wyboru masz 2 możliwości:

• SSDT – pakiet jako rozszerzenie Visual Studio, ale on niestety pozwala tylko na tworzenie pakietów deploymentu baz danych, a nie o to nam przecież chodzi
• SSDT – BI – dostępny pod adresem: http://www.microsoft.com/en-us/download/details.aspx?id=42313
  

I to właśnie ten drugi pakiet zawiera to, czego szukamy!

Pakiet wygląda i instaluje się jakby był to SQL Server 😉 Mma na myśli wygląd i początkowe ekrany kreatora instalacji. Jest jednak pewien kruczek… Podczas instalacji otrzymasz pytanie czy pakiet ma się zainstalować jako nowa instancja, czy jako dodatkowa funkcjonalność do istniejącej instancji. Zakładam, że wcześniej był już instalowany SQL, więc dość naturalne wydaje się wskazanie istniejącej instalacji (instancji). A to może być błąd. Prawdopodobnie instalując SQL zainstalowałeś go w wersji x64. Tymczasem pakiet SSDT-BI jest dostępny TYLKO w wersji 32-bitowej. Pakietu x64 nie ma!!! Wystarczy jednak podczas instalacji wybrać instalację „do nowej instancji” i problemu nie ma. Tymczasem SSDT-BI to tylko narzędzie, które może śmiało pracować z istniejącym SQL x64.