Problem:
Tabela przestawna działa fajnie, gdy dane numeryczne znajdują się
w jednej kolumnie, a obok, w tych samych wierszach, ale innych
kolumnach znajduje się możliwie jak najwięcej atrybutów, tych
danych dotyczących.
Ale nie zawsze tak jest. Czasami eksporty różnych systemów na
siłę ustawiają nam dane w różnych kolumnach, a czasami...
robimy to sami, bo tak w Excelu najłatwiej się dane wpisuje - w
końcu arkusz Excela to fajna tabelka ;)
Filmik:
http://afin.net/webcasts/Demo_DataConsolidation.swf
Opis:
1. Najpierw kwerenda, wzbogacona o wymiary, które nas 'bolą':
Dni - bo dane w kolumnach, a my chcemy w jednej
Miesiące - bo dane w arkuszach, a my chcemy w jednym
2. Pobranie definicji kwerendy do szablonu AFIN.NET.IS
3. Parametryzacja definicji na dwa powyższe parametry
4. Skopiowanie w tyle wierszy, ile jest kombinacji parametrów
(Informatyk zauważy, że można to zrobić lepiej, czyli dużo
krócej. Tu celem jest prostota, nie efektywność)
5. Goł!
Zero VBA, zero formuł - łatwe. Powtarzalne, szybkie, efektywne,
bezbłędne...
czwartek, 26 listopada 2009
piątek, 20 listopada 2009
Własna funkcja - VLOOKUP do plików zamkniętych
Problem:
http://www.goldenline.pl/forum/excel-vba/1303380/s/1
Filmik:
http://afin.net/webcasts/HowTo_CreateMyFunctionVLOOKUP.swf
Opis:
Excel czegoś nie potrafi? Zrób to sam w AFIN.NET.
http://www.goldenline.pl/forum/excel-vba/1303380/s/1
Filmik:
http://afin.net/webcasts/HowTo_CreateMyFunctionVLOOKUP.swf
Opis:
Excel czegoś nie potrafi? Zrób to sam w AFIN.NET.
poniedziałek, 16 listopada 2009
Publikacja raportu na... grupie dyskusyjnej Google
Film:
http://afin.net/webcasts/Demo_PublishingOnGoogle.swf
Opis:
Opublikuj coś AFINEM!
(Coś mało ważnego, bo Cię Prezes okrzyczy ;) )
afinnet@googlegroups.com
Link do grupy (pliki na grupie mogą się zmieniać i być kasowane)
http://groups.google.pl/group/afinnet
Wnioski:
Jednym z koronnych "dowodów" na wyższość systemów Business
Intelligence nad Excelem jest możliwość publikowania raportów w
sieci rozległej, czyli Internecie.
Że serwer jest firmowy, że strasznie zabezpieczony, itp., itd.
Czy może być coś bardziej DOSTĘPNEGO i bardziej ZABEZPIECZONEGO
od Google'a - tam pracuje nad tym ogromny sztab ludzi!
Tu grupa jest otwarta dla wszystkich, nawet nie trzeba być
zalogowanym (co pokazano na filmie) żeby zarówno publikować, jak
i przeglądać - normalnie oczywiście tak być nie może i Google
to zapewnia.
Koszt takiego firmowego serwera publikacji raportow = 0 zł.
A publikacja jest prosta - jak to w AFIN.NET...
http://afin.net/webcasts/Demo_PublishingOnGoogle.swf
Opis:
Opublikuj coś AFINEM!
(Coś mało ważnego, bo Cię Prezes okrzyczy ;) )
afinnet@googlegroups.com
Link do grupy (pliki na grupie mogą się zmieniać i być kasowane)
http://groups.google.pl/group/afinnet
Wnioski:
Jednym z koronnych "dowodów" na wyższość systemów Business
Intelligence nad Excelem jest możliwość publikowania raportów w
sieci rozległej, czyli Internecie.
Że serwer jest firmowy, że strasznie zabezpieczony, itp., itd.
Czy może być coś bardziej DOSTĘPNEGO i bardziej ZABEZPIECZONEGO
od Google'a - tam pracuje nad tym ogromny sztab ludzi!
Tu grupa jest otwarta dla wszystkich, nawet nie trzeba być
zalogowanym (co pokazano na filmie) żeby zarówno publikować, jak
i przeglądać - normalnie oczywiście tak być nie może i Google
to zapewnia.
Koszt takiego firmowego serwera publikacji raportow = 0 zł.
A publikacja jest prosta - jak to w AFIN.NET...
piątek, 13 listopada 2009
Funkcja GETDATAOLAP - Raportowanie z hurtowni danych OLAP
Film:
http://afin.net/webcasts/HowTo_InsertFunction_GETDATAOLAP.swf
Opis:
Załóżmy, ze posiadamy już tzw. wielowymiarową hurtownię danych
OLAP.
Może ona być w wersji "profesjonalnej", czyli np. w MS SQL Server
Analysis Services (SSAS) lub w plikach .cub, tj. wersji dla
mniejszej firmy lub wersji prototypowej - nie ma to najmniejszego
znaczenia - w obu przypadkach istnieje możliwość "zrzutu" danych
do Excela w formie excelowej tabeli przestawnej, podłączonej
bezpośrednio do zewnętrznego, OLAP-owego źródła danych.
Gdzie jest problem?
Właściwie nigdzie - tabela przestawna na zewnętrznym źródle
danych działa bardzo dobrze - bardzo szybko i wygodnie.
Ale...
Gdy chcemy stworzyć raport - nasz własny raport - w którym
poszczególne informacje mają znaleźć się w bardzo konkretnych
miejscach naszego raportu - tabela przestawna staje się
ograniczeniem!
Tabela ma jedno źródło danych, w tabeli nie wszystkie elementy
widać naraz, tabeli nie da się ustawić w dowolny sposób, tabeli
nie da się zmieścić w jednej komórce arkusza (a my chcemy mieć
dane z różnych tabel bezpośrenio jedna pod drugą...), itp.
Prowizorycznym rozwiązaniem jest excelowa funkcja WEŹDANETABELI,
ale ma ona wadę - tabela MUSI być otwarta, a dane MUSZĄ być w
niej "widoczne" - Jest z tym problem.
Gdy tabel (takich źródeł danych) jest dużo, albo tabele są
duże (np. wykraczają poza arkusz), funkcja WEŹDANETABELI staje
się bezużyteczna - poza tym, trzeba pamiętać o otworzeniu
wszystkich tabel...
Najczęściej stosuje się w tym celu dodatkowy program pakietu SQL
Server - SQLS Reporting Services, ale stworzenie w nim jakichkolwiek
definicji wymaga dużej wiedzy informatycznej (znajomość języka
MDX), a stworzenie na jednym raporcie wielu źródeł danych stanowi
duży problem.
Poza tym, raportów nie tworzy się tam tak łatwo i intuicyjnie,
jak w Excelu...
AFIN.NET oferuje funkcję GETDATAOLAP, której działanie jest, w
gruncie rzeczy, bardzo podobne do WEŹDANETABELI. Dane z tabeli
pobiera się równie prosto - 'prawy przycisk myszy' / 'AFIN.NET...'
/ 'Pobierz jako funkcję'...
I gotowe!
Ale funkcja GETDATAOLAP nie wymaga, żeby tabela przestawna była
otwarta (a nawet w ogóle istniała) - tabela jest potrzebna
wyłącznie do STWORZENIA FUNKCJI.
A parametryzowanie wartościami wymiarów - już standardowo, jak
wszystkie funkcje w AFIN.NET
Parametryzowanie jedną wartością wielu funkcji, odwołujących
się do różnych źródeł danych, różnych wymiarów kostek itp.
- jak wyżej, bezproblemowo.
http://afin.net/webcasts/HowTo_InsertFunction_GETDATAOLAP.swf
Opis:
Załóżmy, ze posiadamy już tzw. wielowymiarową hurtownię danych
OLAP.
Może ona być w wersji "profesjonalnej", czyli np. w MS SQL Server
Analysis Services (SSAS) lub w plikach .cub, tj. wersji dla
mniejszej firmy lub wersji prototypowej - nie ma to najmniejszego
znaczenia - w obu przypadkach istnieje możliwość "zrzutu" danych
do Excela w formie excelowej tabeli przestawnej, podłączonej
bezpośrednio do zewnętrznego, OLAP-owego źródła danych.
Gdzie jest problem?
Właściwie nigdzie - tabela przestawna na zewnętrznym źródle
danych działa bardzo dobrze - bardzo szybko i wygodnie.
Ale...
Gdy chcemy stworzyć raport - nasz własny raport - w którym
poszczególne informacje mają znaleźć się w bardzo konkretnych
miejscach naszego raportu - tabela przestawna staje się
ograniczeniem!
Tabela ma jedno źródło danych, w tabeli nie wszystkie elementy
widać naraz, tabeli nie da się ustawić w dowolny sposób, tabeli
nie da się zmieścić w jednej komórce arkusza (a my chcemy mieć
dane z różnych tabel bezpośrenio jedna pod drugą...), itp.
Prowizorycznym rozwiązaniem jest excelowa funkcja WEŹDANETABELI,
ale ma ona wadę - tabela MUSI być otwarta, a dane MUSZĄ być w
niej "widoczne" - Jest z tym problem.
Gdy tabel (takich źródeł danych) jest dużo, albo tabele są
duże (np. wykraczają poza arkusz), funkcja WEŹDANETABELI staje
się bezużyteczna - poza tym, trzeba pamiętać o otworzeniu
wszystkich tabel...
Najczęściej stosuje się w tym celu dodatkowy program pakietu SQL
Server - SQLS Reporting Services, ale stworzenie w nim jakichkolwiek
definicji wymaga dużej wiedzy informatycznej (znajomość języka
MDX), a stworzenie na jednym raporcie wielu źródeł danych stanowi
duży problem.
Poza tym, raportów nie tworzy się tam tak łatwo i intuicyjnie,
jak w Excelu...
AFIN.NET oferuje funkcję GETDATAOLAP, której działanie jest, w
gruncie rzeczy, bardzo podobne do WEŹDANETABELI. Dane z tabeli
pobiera się równie prosto - 'prawy przycisk myszy' / 'AFIN.NET...'
/ 'Pobierz jako funkcję'...
I gotowe!
Ale funkcja GETDATAOLAP nie wymaga, żeby tabela przestawna była
otwarta (a nawet w ogóle istniała) - tabela jest potrzebna
wyłącznie do STWORZENIA FUNKCJI.
A parametryzowanie wartościami wymiarów - już standardowo, jak
wszystkie funkcje w AFIN.NET
Parametryzowanie jedną wartością wielu funkcji, odwołujących
się do różnych źródeł danych, różnych wymiarów kostek itp.
- jak wyżej, bezproblemowo.
czwartek, 12 listopada 2009
Funkcja GETDATAODBC - Uniwersalna funkcja bazodanowa
Film:
http://afin.net/webcasts/HowTo_InsertFunction_GETDATAODBC.swf
Opis:
Excel jest naprawdę bardzo sympatyczną i pełną możliwości
tabelką.
Ale, w swoim standardzie, nie posiada funkcji, które potrafią
sięgnąć "na zewnątrz", do innego, dowolnego środowiska
bazodanowego, własnych skoroszytów Excela, hurtowni danych, itp.
W AFIN.NET funkcja GETDATAODBC() to potrafi - jest to uniwersalna
funkcja do poboru dowolnych danych przez ADO/ODBC itp.
Jedynym problemem jest znajomość systemu zapisu jej argumentów:
ConnStr - tzw. ciąg połączenia bazodanowego
SQLStr - tzw. zdanie SQL - zapytanie do bazy danych
Ale tu w sukurs przychodzi MS Query - definiujemy kwerendę i jednym
prostym ruchem "importujemy" jej ustwienia (tj. w/w parametry) do
funkcji GETDATAODBC() jako jej gotowe argumenty. Działa!
Oczywiście, wszystko możemy robić ręcznie albo kopiować z
biblioteki przykładów. Argumenty funkcji są tekstowe - możemy je
dowolnie zmieniać (edytować), a także parametryzować
wartościami w arkuszu.
Na filmie sparametryzowano w ten sposób ciąg połączenia
bazodanowego do skoroszytu Excela; ponieważ jest używany w wielu
funkcjach na arkuszu, nie ma sensu przechowywać go w postaci
argumentu we wszystkich funkcjach - tu: jest w jednym miejscu jako
parametr arkusza.
http://afin.net/webcasts/HowTo_InsertFunction_GETDATAODBC.swf
Opis:
Excel jest naprawdę bardzo sympatyczną i pełną możliwości
tabelką.
Ale, w swoim standardzie, nie posiada funkcji, które potrafią
sięgnąć "na zewnątrz", do innego, dowolnego środowiska
bazodanowego, własnych skoroszytów Excela, hurtowni danych, itp.
W AFIN.NET funkcja GETDATAODBC() to potrafi - jest to uniwersalna
funkcja do poboru dowolnych danych przez ADO/ODBC itp.
Jedynym problemem jest znajomość systemu zapisu jej argumentów:
ConnStr - tzw. ciąg połączenia bazodanowego
SQLStr - tzw. zdanie SQL - zapytanie do bazy danych
Ale tu w sukurs przychodzi MS Query - definiujemy kwerendę i jednym
prostym ruchem "importujemy" jej ustwienia (tj. w/w parametry) do
funkcji GETDATAODBC() jako jej gotowe argumenty. Działa!
Oczywiście, wszystko możemy robić ręcznie albo kopiować z
biblioteki przykładów. Argumenty funkcji są tekstowe - możemy je
dowolnie zmieniać (edytować), a także parametryzować
wartościami w arkuszu.
Na filmie sparametryzowano w ten sposób ciąg połączenia
bazodanowego do skoroszytu Excela; ponieważ jest używany w wielu
funkcjach na arkuszu, nie ma sensu przechowywać go w postaci
argumentu we wszystkich funkcjach - tu: jest w jednym miejscu jako
parametr arkusza.
wtorek, 10 listopada 2009
Funkcja GETDATALINK - alternatywa dla łącz międzyskoroszytowych
Film:
http://afin.net/webcasts/HowTo_InsertFunction_GETDATALINK.swf
Opis:
Film pokazuje, w jaki sposób wpisać i parametryzować funkcję
zastępującą awaryjne łącza międzyskoroszytowe w arkuszu.
Pokazane są dwa sposoby:
1. Poprzez stworzenie fizycznego łącza do innego skoroszytu
Excela, zamianę go na funkcję GETDATALINK, a nastepnie
sparametryzowanie nazwą skoroszytu i adresem odwołania.
2. Poprzez użycie funkcji GETDATA (polski alias: DANE) z
predefiniowanymi ustawieniami do prezentowanego, przykładowego
modelu skoroszytów.
W tym przypadku wstępne otwieranie pliku-źródła nie jest
wymagane.
Wnioski:
Koniec z problemami, związanymi z awaryjnością łącz Excela -
funkcje AFIN.NET mogą je zastąpić i, dodatkowo, mogą być
dowolnie parametryzowane.
http://afin.net/webcasts/HowTo_InsertFunction_GETDATALINK.swf
Opis:
Film pokazuje, w jaki sposób wpisać i parametryzować funkcję
zastępującą awaryjne łącza międzyskoroszytowe w arkuszu.
Pokazane są dwa sposoby:
1. Poprzez stworzenie fizycznego łącza do innego skoroszytu
Excela, zamianę go na funkcję GETDATALINK, a nastepnie
sparametryzowanie nazwą skoroszytu i adresem odwołania.
2. Poprzez użycie funkcji GETDATA (polski alias: DANE) z
predefiniowanymi ustawieniami do prezentowanego, przykładowego
modelu skoroszytów.
W tym przypadku wstępne otwieranie pliku-źródła nie jest
wymagane.
Wnioski:
Koniec z problemami, związanymi z awaryjnością łącz Excela -
funkcje AFIN.NET mogą je zastąpić i, dodatkowo, mogą być
dowolnie parametryzowane.
piątek, 6 listopada 2009
Konsolidacja rejestrów z eksportami filtrowanymi
Problem:
Jak skonsolidować wiele rejestrów z wielu ustrukturalizowanych
katalogów (system zabezpieczeń na poziomie katalogów), a
następnie udostępnić wyniki konsolidacji różnym osobom o
ograniczonych uprawnieniach?
Filmik:
http://afin.net/webcasts/Demo_RegisterConsolidation.swf
Opis:
Wiele katalogów, wiele plików
(w przykładzie: wszystkie pliki takie same)
1. Pokaz środowiska - organizacji katalogów oraz zawartości
plików
2. Stworzenie kwerendy do pierwszego z plików oraz dodanie
atrybutów dodatkowych, identyfikujących miejsce pliku w hierarchii
oraz nazwę pliku (jako jego identyfikator)
3. Otwarcie odpowiedniego szablonu AFIN.NET i pobranie definicji
kwerendy do programu
4. Parametryzacja programu wartościami parametrów, dot. katalogu
(miejsca w hierarchii plików) oraz nazwy pliku, wyciągniętych do
komórek arkusza programu
5. Testowe uruchomienie programu i przegląd wartości - filtrowanie
wg dowolnych atrybutów
6. Uzupełnienie programu o część eksportową - dodanie wierszy
eksportujących oraz, również, sparametryzowanie ich komórkami w
arkuszu (tu: w pierwszym etapie, podczas nagrywania filmu,
pomyliłem się i dodałem za mało atrybutów - dlatego dwa razy)
7. Przegląd gotowych plików eksportowych.
Oczywiście, pliki eksportowe można od razu zapisywać do
odpowiednich katalogów, tak, aby każdy z ich użytkowników miał
swój i tylko swój do wglądu.
Dystrybucję tego "systemu" można również zorganizować inaczej,
bez wykonywania plików 'eksportowych': każdy z zainteresowanych
użytkowników ma taki sam plik-program. Dane jednak pobierają się
każdemu inaczej - tak, jak pozwalają na to ograniczenia
dostępności na poziomie systemu plików. Gdzie nie ma dostępu -
dane się nie pobiorą. Program nie zwróci żadnego błędu - brak
będzie jedynie tych danych, do których dany użytkownik nie
posiada uprawnień.
Jak skonsolidować wiele rejestrów z wielu ustrukturalizowanych
katalogów (system zabezpieczeń na poziomie katalogów), a
następnie udostępnić wyniki konsolidacji różnym osobom o
ograniczonych uprawnieniach?
Filmik:
http://afin.net/webcasts/Demo_RegisterConsolidation.swf
Opis:
Wiele katalogów, wiele plików
(w przykładzie: wszystkie pliki takie same)
1. Pokaz środowiska - organizacji katalogów oraz zawartości
plików
2. Stworzenie kwerendy do pierwszego z plików oraz dodanie
atrybutów dodatkowych, identyfikujących miejsce pliku w hierarchii
oraz nazwę pliku (jako jego identyfikator)
3. Otwarcie odpowiedniego szablonu AFIN.NET i pobranie definicji
kwerendy do programu
4. Parametryzacja programu wartościami parametrów, dot. katalogu
(miejsca w hierarchii plików) oraz nazwy pliku, wyciągniętych do
komórek arkusza programu
5. Testowe uruchomienie programu i przegląd wartości - filtrowanie
wg dowolnych atrybutów
6. Uzupełnienie programu o część eksportową - dodanie wierszy
eksportujących oraz, również, sparametryzowanie ich komórkami w
arkuszu (tu: w pierwszym etapie, podczas nagrywania filmu,
pomyliłem się i dodałem za mało atrybutów - dlatego dwa razy)
7. Przegląd gotowych plików eksportowych.
Oczywiście, pliki eksportowe można od razu zapisywać do
odpowiednich katalogów, tak, aby każdy z ich użytkowników miał
swój i tylko swój do wglądu.
Dystrybucję tego "systemu" można również zorganizować inaczej,
bez wykonywania plików 'eksportowych': każdy z zainteresowanych
użytkowników ma taki sam plik-program. Dane jednak pobierają się
każdemu inaczej - tak, jak pozwalają na to ograniczenia
dostępności na poziomie systemu plików. Gdzie nie ma dostępu -
dane się nie pobiorą. Program nie zwróci żadnego błędu - brak
będzie jedynie tych danych, do których dany użytkownik nie
posiada uprawnień.
Subskrybuj:
Posty (Atom)