Czy można zautomatyzować proces cyklicznego łączenia się i
poboru danych?
Czy temat "odświeżanie hurtowni w nocy" można załatwić tanio,
czy też jest to domeną drogich systemów?
Czy można to (z)robić nie tylko z baz lokalnych, ale także tych
internetowych?
Film
http://afin.net/webcasts/Demo_AfinNetIs_AutoStart_QueryFromMySqlInternet.swf
Pewnie, że można. I to już. 'Pyk' i jest.
czwartek, 3 czerwca 2010
środa, 2 czerwca 2010
Własna funkcja DANE() (alias GETDATA)
Od podstaw:
Chcemy mieć raport.
Chcemy w nim mieć funkcje, której wartości (Sprzedaż czegoś tam
w danym mieście) będą zależne od nazwy miasta, czyli
=DANE("NazwaZmiennej", "NazwaMiasta")
Funkcja, oczywiście, ma być Excelowa, łatwowpisywalna,
szybkoprzeliczalna, niepsująca się i takie tam, oczywistości.
Jest jednak problem, a właściwie parę problemów:
1) Dane trzeba sumować w locie, tzn. nie interesuje nas wartość
jednej pozycji (faktury) - więcej: nie interesuje nas sprzedaż dla
pojedynczego kontrahenta - nas interesuje MIASTO.
No to SUMA.JEŻELI() albo tabela przestawna... , ale...
2) Dane są w dwóch tabelach - jedna ('faktura') zawiera dane
numeryczne, druga ('odbiorca') to jej słownik - tu są dane
kontrahentów, czyli m.in. miasto.
Co to za problem? przecież jest wspaniała funkcja WYSZUKAJ.PIONOWO
- ona nam ściągnie miasto do faktur... ale...
3) Dane są zmienne - codziennie się zmieniają. Zmieniają się
dane numeryczne, ale także rozrasta się słownik.
No to czekają nas długie godzinki przeklejania, modyfikacji
zakresów, pilnowania, żeby otwarcie plików czegoś tam nie
zablokowało, tysiące kopii, dziesiątki poprawek, itp. taki sobie,
comiesięczny, standard analityka...
Chyba że...
...zrobimy sobie WŁASNĄ FUNKCJĘ!
Film:
http://afin.net/webcasts/HowTo_GetdataFunction_Basic.swf
Chcemy mieć raport.
Chcemy w nim mieć funkcje, której wartości (Sprzedaż czegoś tam
w danym mieście) będą zależne od nazwy miasta, czyli
=DANE("NazwaZmiennej", "NazwaMiasta")
Funkcja, oczywiście, ma być Excelowa, łatwowpisywalna,
szybkoprzeliczalna, niepsująca się i takie tam, oczywistości.
Jest jednak problem, a właściwie parę problemów:
1) Dane trzeba sumować w locie, tzn. nie interesuje nas wartość
jednej pozycji (faktury) - więcej: nie interesuje nas sprzedaż dla
pojedynczego kontrahenta - nas interesuje MIASTO.
No to SUMA.JEŻELI() albo tabela przestawna... , ale...
2) Dane są w dwóch tabelach - jedna ('faktura') zawiera dane
numeryczne, druga ('odbiorca') to jej słownik - tu są dane
kontrahentów, czyli m.in. miasto.
Co to za problem? przecież jest wspaniała funkcja WYSZUKAJ.PIONOWO
- ona nam ściągnie miasto do faktur... ale...
3) Dane są zmienne - codziennie się zmieniają. Zmieniają się
dane numeryczne, ale także rozrasta się słownik.
No to czekają nas długie godzinki przeklejania, modyfikacji
zakresów, pilnowania, żeby otwarcie plików czegoś tam nie
zablokowało, tysiące kopii, dziesiątki poprawek, itp. taki sobie,
comiesięczny, standard analityka...
Chyba że...
...zrobimy sobie WŁASNĄ FUNKCJĘ!
Film:
http://afin.net/webcasts/HowTo_GetdataFunction_Basic.swf
wtorek, 1 czerwca 2010
SQL - ciekawostki
MySQL: Funkcja GROUP_CONCAT
Kolejna ciekawostka - tym razem rodem z MySQL - informacyjne
łączenie tekstów elementów, tworzących grupę (podlegających
grupowaniu) w jednym polu tekstowym.
(=nowa funkcja agregująca na polu tekstowym)
MIASTO Klienci Sprzedaż
WROCLAW JARIMPEX,SIANEX,HANIMPEX,AREX,FRANEX 284,8
WARSZAWA JUREX,KOWALSKI,IMPEX 199,2
OPOLE BRONEX,DAREX 87,5
LEGNICA EDEX,EXIMP 45,7
SZCZECIN CELIMP 19,4
BIALYSTOK NOWAK 16,2
CIECHANOW ANEX 5,5
GDANSK GRZESIEX 4,5
I, oczywiście, SQLek:
SELECT odbiorca_0.MIASTO, GROUP_CONCAT(DISTINCT faktura_0.NAZWA) AS
'Klienci', Sum(faktura_0.WART_NET) AS 'Sprzedaż'
FROM afin_Sales.faktura faktura_0, afin_Sales.odbiorca odbiorca_0
WHERE faktura_0.NAZWA = odbiorca_0.NAZWA
GROUP BY odbiorca_0.MIASTO
ORDER BY Sum(faktura_0.WART_NET) DESC
Kolejna ciekawostka - tym razem rodem z MySQL - informacyjne
łączenie tekstów elementów, tworzących grupę (podlegających
grupowaniu) w jednym polu tekstowym.
(=nowa funkcja agregująca na polu tekstowym)
MIASTO Klienci Sprzedaż
WROCLAW JARIMPEX,SIANEX,HANIMPEX,AREX,FRANEX 284,8
WARSZAWA JUREX,KOWALSKI,IMPEX 199,2
OPOLE BRONEX,DAREX 87,5
LEGNICA EDEX,EXIMP 45,7
SZCZECIN CELIMP 19,4
BIALYSTOK NOWAK 16,2
CIECHANOW ANEX 5,5
GDANSK GRZESIEX 4,5
I, oczywiście, SQLek:
SELECT odbiorca_0.MIASTO, GROUP_CONCAT(DISTINCT faktura_0.NAZWA) AS
'Klienci', Sum(faktura_0.WART_NET) AS 'Sprzedaż'
FROM afin_Sales.faktura faktura_0, afin_Sales.odbiorca odbiorca_0
WHERE faktura_0.NAZWA = odbiorca_0.NAZWA
GROUP BY odbiorca_0.MIASTO
ORDER BY Sum(faktura_0.WART_NET) DESC
wtorek, 25 maja 2010
Pobierz plik z Internetu i go użyj
Problem:
Aby pobrać i odczytać dane z pliku, wystawionego w Internecie
(HTTP) trzeba:
1) uruchomić przeglądarkę internetową (1 kliknięcie + dwie
sekundy na załadowanie)
2) przejść do strony z plikiem lub katalogu webowego (1
kliknięcie, jeśli w 'ulubionych' + sekunda na załadowanie)
3) kliknąć na wybrany plik (1 kliknięcie)
4) potwierdzić, że chce się go zapisać, ew. wskazanie katalogu
do zapisu (min. 1 kliknięcie)
5) otworzenie pliku np. w Excelu (min. 2 kiknięcia)
RAZEM: Min. 5 kliknięć + ok. 10 sekund życia utracone
bezpowrotnie :(
...albo...
otwierać plik w Excelu z HTTP://...
(trzeba wpisywać ścieżkę, zwykle długą i potem zapisywać plik
na swoim dysku poprzez 'zapisz jako')
...albo...
Film:
http://afin.net/webcasts/Demo_DownloadAFileFromInternetAndUseIt.swf
Oczywiście można tak ściągnąć dowolną ilość plików jednym
'procesem', czyli jednym kliknięciem.
Aby pobrać i odczytać dane z pliku, wystawionego w Internecie
(HTTP) trzeba:
1) uruchomić przeglądarkę internetową (1 kliknięcie + dwie
sekundy na załadowanie)
2) przejść do strony z plikiem lub katalogu webowego (1
kliknięcie, jeśli w 'ulubionych' + sekunda na załadowanie)
3) kliknąć na wybrany plik (1 kliknięcie)
4) potwierdzić, że chce się go zapisać, ew. wskazanie katalogu
do zapisu (min. 1 kliknięcie)
5) otworzenie pliku np. w Excelu (min. 2 kiknięcia)
RAZEM: Min. 5 kliknięć + ok. 10 sekund życia utracone
bezpowrotnie :(
...albo...
otwierać plik w Excelu z HTTP://...
(trzeba wpisywać ścieżkę, zwykle długą i potem zapisywać plik
na swoim dysku poprzez 'zapisz jako')
...albo...
Film:
http://afin.net/webcasts/Demo_DownloadAFileFromInternetAndUseIt.swf
Oczywiście można tak ściągnąć dowolną ilość plików jednym
'procesem', czyli jednym kliknięciem.
poniedziałek, 24 maja 2010
Import tekstu przez ODBC
Pokaz wydajności powyższego.
Dokładnie taki sam film, jak powyżej, ale plik tekstowy ma
PONAD 2 MILIONY WIERSZY
Film:
http://afin.net/webcasts/Demo_ImportTextViaOdbc2M.swf
Wydajność:
Sam filtrowany import do tabeli Accessa = 40 SEKUND
(50.000 wierszy / sek)
Całość - ze wszystkimi przeróbkami, kopiami, obliczeniami,
wyklejkami - razem 212 sekund
(Komputer: cieniutki - 1.5 GHz, 1 GB RAM)
To mniej więcej sprzedaż dużej firmy z całego roku z
dokładnością do POZYCJI faktury, czyli "do dokumentu" = wszystko.
4 minuty i po problemie. Nieźle.
Dokładnie taki sam film, jak powyżej, ale plik tekstowy ma
PONAD 2 MILIONY WIERSZY
Film:
http://afin.net/webcasts/Demo_ImportTextViaOdbc2M.swf
Wydajność:
Sam filtrowany import do tabeli Accessa = 40 SEKUND
(50.000 wierszy / sek)
Całość - ze wszystkimi przeróbkami, kopiami, obliczeniami,
wyklejkami - razem 212 sekund
(Komputer: cieniutki - 1.5 GHz, 1 GB RAM)
To mniej więcej sprzedaż dużej firmy z całego roku z
dokładnością do POZYCJI faktury, czyli "do dokumentu" = wszystko.
4 minuty i po problemie. Nieźle.
piątek, 21 maja 2010
Import tekstu przez ODBC
Problem:
Import tekstu do Excela i do baz danych. Ogólnie.
Nie dlatego, że trudno to oprogramować - to umieją wszyscy.
Problem jest w tym, że twórcy aplikacji transakcyjnych, z których
takie eksporty zwykle pochodzą, wsadzają do tych tekstów ogromną
ilość niepotrzebnych linii, dziwnych znaków, itp.
Podstawowe wady to import całości tekstu, który czasami nie
mieści się w arkuszu oraz dalej zawiera owe 'śmieciowe' linie,
które w Excelu trzeba dopiero rozpoznać i ręcznie usunąć -
koszmar.
Jak się go rozwiązuje?
1) Przez BEZNADZIEJNĄ opcję Excela 'import tekstu'. Nie dość że
jest zła, to jest zła od 20 lat, a we wszystkich książkach jest
opisywana jako 'dostęp Excela do danych'. Kto co i jak zna, tak
opisuje.
A kto to próbował automatyzować przez VBA wie, jakie są z tym
problemy.
2) Przez odczyt linia-po-linii przez VBA
Efekt duuuuużo lepszy! Czytamy jak i co chcemy, wsadzamy do arkusza
również z pełną kontrolą. Ale są problemy - dane pozostają w
arkuszu i trudno zrobić z tego 'zbiorcza bazę danych'
3) Przez ODBC, np. kwerendą
Rozwiązania zdecydowanie poprawne, ale jest problem - trzeba
zdefiniować plik definicji takiego importu, czyli 'schema.ini' -
można z tego zrobić doktorat, czyli fajne, ale skomplikowane.
4) Można również wykorzystać SPECJALNE NARZĘDZIE do tego celu -
AFIN.NET.TextConverter. Ale, czasami, warto jednak pamiętać, że
ODBC jest po prostu bardzo szybkie...
5) A może tak? - przez ODBC, ale wielokrokowo, parametrycznie, ale
bezpośrednio do jakiejś sensownej BAZY DANYCH, tu: do pliku
Accessa.
Jedno, co trzeba umieć, to bardzo niewielkie podstawy SQL.
Film:
http://afin.net/webcasts/Demo_ImportTextViaOdbc1.swf
Wnioski:
Można. Dość łatwo, ale, przede wszystkim, BARDZO SZYBKO I
WYGODNIE!
I parametrycznie - gdy pojawia się nowy plik tekstowy - dogranie go
do bazy danych to moment.
Ale proszę jednak zwrócić uwagę na pewne novum w tej metodzie:
Import tekstu jest zwykle jednoetapowy - plik importuje się i już:
albo otwiera w Excelu, albo czyta linia po linii, albo przez ODBC,
definiując owo schema.ini. Novum polega na tym, że tu plik
tekstowy zaczytuje się jednym ruchem się do bazy zewnętrznej już
przefiltrowany, ale wszystkie dalsze ruchy: podział na kolumny i
wszystkie poprawki robi się na tabeli w bazie danych - a tu jest
naprawdę dużo możliwości.
Dopiero na sam koniec dane trafiają do tabeli wynikowej lub są
eksportowane do plików zewnętrznych.
Ja lepszej metody nie znam.
A AFIN.NET to ładnie automatyzuje - jeden klik.
Import tekstu do Excela i do baz danych. Ogólnie.
Nie dlatego, że trudno to oprogramować - to umieją wszyscy.
Problem jest w tym, że twórcy aplikacji transakcyjnych, z których
takie eksporty zwykle pochodzą, wsadzają do tych tekstów ogromną
ilość niepotrzebnych linii, dziwnych znaków, itp.
Podstawowe wady to import całości tekstu, który czasami nie
mieści się w arkuszu oraz dalej zawiera owe 'śmieciowe' linie,
które w Excelu trzeba dopiero rozpoznać i ręcznie usunąć -
koszmar.
Jak się go rozwiązuje?
1) Przez BEZNADZIEJNĄ opcję Excela 'import tekstu'. Nie dość że
jest zła, to jest zła od 20 lat, a we wszystkich książkach jest
opisywana jako 'dostęp Excela do danych'. Kto co i jak zna, tak
opisuje.
A kto to próbował automatyzować przez VBA wie, jakie są z tym
problemy.
2) Przez odczyt linia-po-linii przez VBA
Efekt duuuuużo lepszy! Czytamy jak i co chcemy, wsadzamy do arkusza
również z pełną kontrolą. Ale są problemy - dane pozostają w
arkuszu i trudno zrobić z tego 'zbiorcza bazę danych'
3) Przez ODBC, np. kwerendą
Rozwiązania zdecydowanie poprawne, ale jest problem - trzeba
zdefiniować plik definicji takiego importu, czyli 'schema.ini' -
można z tego zrobić doktorat, czyli fajne, ale skomplikowane.
4) Można również wykorzystać SPECJALNE NARZĘDZIE do tego celu -
AFIN.NET.TextConverter. Ale, czasami, warto jednak pamiętać, że
ODBC jest po prostu bardzo szybkie...
5) A może tak? - przez ODBC, ale wielokrokowo, parametrycznie, ale
bezpośrednio do jakiejś sensownej BAZY DANYCH, tu: do pliku
Accessa.
Jedno, co trzeba umieć, to bardzo niewielkie podstawy SQL.
Film:
http://afin.net/webcasts/Demo_ImportTextViaOdbc1.swf
Wnioski:
Można. Dość łatwo, ale, przede wszystkim, BARDZO SZYBKO I
WYGODNIE!
I parametrycznie - gdy pojawia się nowy plik tekstowy - dogranie go
do bazy danych to moment.
Ale proszę jednak zwrócić uwagę na pewne novum w tej metodzie:
Import tekstu jest zwykle jednoetapowy - plik importuje się i już:
albo otwiera w Excelu, albo czyta linia po linii, albo przez ODBC,
definiując owo schema.ini. Novum polega na tym, że tu plik
tekstowy zaczytuje się jednym ruchem się do bazy zewnętrznej już
przefiltrowany, ale wszystkie dalsze ruchy: podział na kolumny i
wszystkie poprawki robi się na tabeli w bazie danych - a tu jest
naprawdę dużo możliwości.
Dopiero na sam koniec dane trafiają do tabeli wynikowej lub są
eksportowane do plików zewnętrznych.
Ja lepszej metody nie znam.
A AFIN.NET to ładnie automatyzuje - jeden klik.
poniedziałek, 17 maja 2010
Publikacja raportów w Internecie 2 (+parametryzacja raportów, +automatyzacja raportowania)
Problem:
No dobrze, AFIN może publikować, tzn. zapisywać do plików
"odafinowanych" (pozbawionych funkcji AFINA, by można było je
otwierać 'czystym' Excelem lub nawet np. Open Office'em) - fajnie.
Potrafi także zapisywać raporty na Office Live Workspace, czyli na
internetowej platformie wymiany dokumentów - też fajnie.
Ale...
* Raporty są zwykle odgórnie parametryzowane, czyli to operator
nadaje (wybiera, wstawia, określa) odgórny PARAMETR dla wszystkich
raportów - najczęściej bieżący miesiąc albo kurs jakiejś
waluty, ale są przecież raporty specjalizowane dla poszczególnych
grup odbiorców, itp.
* tych raportów jest cała masa - nikt nie chce powtarzać
chociażby jednego kliknięcia 'Start' dla wszystkich raportów.
Czasami raportów do zrobienia jest N (=ilość typów raportów)
razy tyle, ile MPKów, a co miesiąc jest inny parametr miesiąca...
Film:
http://afin.net/webcasts/HowTo_ParametrizeAndAutomatizeInternetReports.swf
Wszystko na filmie pokazano maksymalnie wolno i "od zera"
(INSTRUKTAŻ) - stąd film jest dość długi (14 minut)
Wnioski:
1) Nie ma najmniejszego problemu w zdefiniowaniu bardzo nawet
skomplikowanego systemu raportowania w oparciu o AFIN.NET (gotowy
szablon!) oraz bezpłatny dostęp do platformy internetowej Office
Live Workspace (Użytkownika/ów definiuje się w minutę).
2) Systemy raportowe w Excelu, oparte o wysyłanie skoroszytów
Excela pocztą nie są - delikatnie mówiąc - najlepszym
rozwiązaniem. Faktem jest, że inne rozwiązania (np. zakup
specjalnego systemu np. budżetowania) są w gruncie rzeczy jeszcze
gorsze i dużo, dużo droższe.
3) Nie namawiam tu nikogo do korzystania z Office Live Workspace -
to "Internet" i "nie wiadomo, jak zabezpieczone" itd. W ramach firmy
zwykła sieć spełnia dokładnie takie samo zadanie, czyli tym co
maja sieć - na sieć, tym co nie mają - do Internetu!
Wszystko to w zasięgu ręki. Dostępne natychmiast.
No dobrze, AFIN może publikować, tzn. zapisywać do plików
"odafinowanych" (pozbawionych funkcji AFINA, by można było je
otwierać 'czystym' Excelem lub nawet np. Open Office'em) - fajnie.
Potrafi także zapisywać raporty na Office Live Workspace, czyli na
internetowej platformie wymiany dokumentów - też fajnie.
Ale...
* Raporty są zwykle odgórnie parametryzowane, czyli to operator
nadaje (wybiera, wstawia, określa) odgórny PARAMETR dla wszystkich
raportów - najczęściej bieżący miesiąc albo kurs jakiejś
waluty, ale są przecież raporty specjalizowane dla poszczególnych
grup odbiorców, itp.
* tych raportów jest cała masa - nikt nie chce powtarzać
chociażby jednego kliknięcia 'Start' dla wszystkich raportów.
Czasami raportów do zrobienia jest N (=ilość typów raportów)
razy tyle, ile MPKów, a co miesiąc jest inny parametr miesiąca...
Film:
http://afin.net/webcasts/HowTo_ParametrizeAndAutomatizeInternetReports.swf
Wszystko na filmie pokazano maksymalnie wolno i "od zera"
(INSTRUKTAŻ) - stąd film jest dość długi (14 minut)
Wnioski:
1) Nie ma najmniejszego problemu w zdefiniowaniu bardzo nawet
skomplikowanego systemu raportowania w oparciu o AFIN.NET (gotowy
szablon!) oraz bezpłatny dostęp do platformy internetowej Office
Live Workspace (Użytkownika/ów definiuje się w minutę).
2) Systemy raportowe w Excelu, oparte o wysyłanie skoroszytów
Excela pocztą nie są - delikatnie mówiąc - najlepszym
rozwiązaniem. Faktem jest, że inne rozwiązania (np. zakup
specjalnego systemu np. budżetowania) są w gruncie rzeczy jeszcze
gorsze i dużo, dużo droższe.
3) Nie namawiam tu nikogo do korzystania z Office Live Workspace -
to "Internet" i "nie wiadomo, jak zabezpieczone" itd. W ramach firmy
zwykła sieć spełnia dokładnie takie samo zadanie, czyli tym co
maja sieć - na sieć, tym co nie mają - do Internetu!
Wszystko to w zasięgu ręki. Dostępne natychmiast.
Subskrybuj:
Posty (Atom)