Re: [lms] lms-cashimport-bzwbk
Ten skrypt działa korzystam z niego codziennie od kilku lat, podobnie kilka firm. A że można przez e-mail? Pewnie że można, ważne że wybór jest :-).
Dariusz Kowalczyk
Ten skrypt dzialal przez ostatnie kilka lat z mniejszymi czy wiekszymi wpadkami. Natomiast po ostatnim weekendzie przestal dzialac, zmienila sie jak to bank nazywa aplikacja rapkm. Znaczy portal, do ktorego skrypt sie loguje w celu pobrania plikow z wplatami. Z mojego krotkiego rekonesansu zmienilo sie szyfrowanie i struktura samego portalu. Wczesniej w zakladce raporty byly widoczne wszystkie pliki, jakie bylo mozna pobrac. W tej chwili jest formularz, w ktorym nalezy wpisac date i widoczny bedzie jeden plik o ile nie minelo wiecej niz 30 dni od jego publikacji.
Jesli chodzi o dorzucenie sie do nowego skryptu, to ja sie na to pisze.
W dniu 2012-10-16 11:22, LJ pisze:
Ten skrypt działa korzystam z niego codziennie od kilku lat, podobnie kilka firm. A że można przez e-mail? Pewnie że można, ważne że wybór jest :-).
Dariusz Kowalczyk
Ten skrypt dzialal przez ostatnie kilka lat z mniejszymi czy wiekszymi wpadkami. Natomiast po ostatnim weekendzie przestal dzialac, zmienila sie jak to bank nazywa aplikacja rapkm. Znaczy portal, do ktorego skrypt sie loguje w celu pobrania plikow z wplatami. Z mojego krotkiego rekonesansu zmienilo sie szyfrowanie i struktura samego portalu. Wczesniej w zakladce raporty byly widoczne wszystkie pliki, jakie bylo mozna pobrac. W tej chwili jest formularz, w ktorym nalezy wpisac date i widoczny bedzie jeden plik o ile nie minelo wiecej niz 30 dni od jego publikacji.
Jesli chodzi o dorzucenie sie do nowego skryptu, to ja sie na to pisze.
Za namową Tomka przechodzę na raporty otrzymywane mailem i taki skrypt będzie pisany. Nie chcę aby za chwilę znów trzeba było pisać nowy skrypt bo coś się zmieniło na stronie.
W dniu 2012-10-16 11:35, Daniel Kulesza pisze:
W dniu 2012-10-16 11:22, LJ pisze:
Ten skrypt działa korzystam z niego codziennie od kilku lat, podobnie kilka firm. A że można przez e-mail? Pewnie że można, ważne że wybór jest :-).
Dariusz Kowalczyk
Ten skrypt dzialal przez ostatnie kilka lat z mniejszymi czy wiekszymi wpadkami. Natomiast po ostatnim weekendzie przestal dzialac, zmienila sie jak to bank nazywa aplikacja rapkm. Znaczy portal, do ktorego skrypt sie loguje w celu pobrania plikow z wplatami. Z mojego krotkiego rekonesansu zmienilo sie szyfrowanie i struktura samego portalu. Wczesniej w zakladce raporty byly widoczne wszystkie pliki, jakie bylo mozna pobrac. W tej chwili jest formularz, w ktorym nalezy wpisac date i widoczny bedzie jeden plik o ile nie minelo wiecej niz 30 dni od jego publikacji.
Jesli chodzi o dorzucenie sie do nowego skryptu, to ja sie na to pisze.
Za namową Tomka przechodzę na raporty otrzymywane mailem i taki skrypt będzie pisany. Nie chcę aby za chwilę znów trzeba było pisać nowy skrypt bo coś się zmieniło na stronie.
lms mailing list lms@lists.lms.org.pl http://lists.lms.org.pl/mailman/listinfo/lms
Taki skrypt jest już dawno napisany, mnóstwo ludzi korzysta z takiego rozwiązania, dodam też że bank millenium ma podobny do bzwbk format plików csv i też wysyła na maila i też taki skrypt jest.
W dniu 16.10.2012 12:13, Admin - Dar.Net napisał(a):
W dniu 2012-10-16 11:35, Daniel Kulesza pisze:
W dniu 2012-10-16 11:22, LJ pisze:
Ten skrypt działa korzystam z niego codziennie od kilku lat, podobnie kilka firm. A że można przez e-mail? Pewnie że można, ważne że wybór jest :-).
Dariusz Kowalczyk
Ten skrypt dzialal przez ostatnie kilka lat z mniejszymi czy wiekszymi wpadkami. Natomiast po ostatnim weekendzie przestal dzialac, zmienila sie jak to bank nazywa aplikacja rapkm. Znaczy portal, do ktorego skrypt sie loguje w celu pobrania plikow z wplatami. Z mojego krotkiego rekonesansu zmienilo sie szyfrowanie i struktura samego portalu. Wczesniej w zakladce raporty byly widoczne wszystkie pliki, jakie bylo mozna pobrac. W tej chwili jest formularz, w ktorym nalezy wpisac date i widoczny bedzie jeden plik o ile nie minelo wiecej niz 30 dni od jego publikacji.
Jesli chodzi o dorzucenie sie do nowego skryptu, to ja sie na to pisze.
Za namową Tomka przechodzę na raporty otrzymywane mailem i taki skrypt będzie pisany. Nie chcę aby za chwilę znów trzeba było pisać nowy skrypt bo coś się zmieniło na stronie.
Taki skrypt jest już dawno napisany, mnóstwo ludzi korzysta z takiego rozwiązania, dodam też że bank millenium ma podobny do bzwbk format plików csv i też wysyła na maila i też taki skrypt jest.
Skąd zatem można pobrać taki skrypt i czy był on pisany przez mysql fetyszystów, którzy na sztywno w kodzie zaszywają odwołania do API tego świetnego silnika bazodanowego? ;-)
Taki skrypt jest już dawno napisany, mnóstwo ludzi korzysta z takiego rozwiązania, dodam też że bank millenium ma podobny do bzwbk format plików csv i też wysyła na maila i też taki skrypt jest.
Skąd zatem można pobrać taki skrypt i czy był on pisany przez mysql fetyszystów, którzy na sztywno w kodzie zaszywają odwołania do API tego świetnego silnika bazodanowego? ;-)
Tomek jak czytam Twoje posty w których jest użyte słowo "mysql" to jestem pewnie że ciśnienie ci się wtedy musiało mocno podnieść, mnie też się podnosi w czasie pytanie takich postów ale z rozbawienia. Lubie je czytać :-).
p.s. Użyłem słowa "mysql" w celach poglądowych anie żeby podnieść Tomkowi ciśnienie. Mysql jest znakiem towarowym firmy Oracle :-)
W dniu 16.10.2012 12:31, Dariusz Kowalczyk napisał(a):
Taki skrypt jest już dawno napisany, mnóstwo ludzi korzysta z takiego rozwiązania, dodam też że bank millenium ma podobny do bzwbk format plików csv i też wysyła na maila i też taki skrypt jest.
Skąd zatem można pobrać taki skrypt i czy był on pisany przez mysql fetyszystów, którzy na sztywno w kodzie zaszywają odwołania do API tego świetnego silnika bazodanowego? ;-)
Tomek jak czytam Twoje posty w których jest użyte słowo "mysql" to jestem pewnie że ciśnienie ci się wtedy musiało mocno podnieść, mnie też się podnosi w czasie pytanie takich postów ale z rozbawienia. Lubie je czytać :-).
p.s. Użyłem słowa "mysql" w celach poglądowych anie żeby podnieść Tomkowi ciśnienie. Mysql jest znakiem towarowym firmy Oracle :-)
A ja lubię tak pisać o MySQL, bo zawsze widzę przed oczami rzeszę ludzi męczącą się z MySQL i mi ich trochę żal ;-)
W dniu 16 października 2012 12:40 użytkownik Tomasz Chiliński < tomasz.chilinski@chilan.com> napisał:
A ja lubię tak pisać o MySQL, bo zawsze widzę przed oczami rzeszę ludzi męczącą się z MySQL i mi ich trochę żal ;-)
a ja Tomku zastanawiałem się nad przejściem na postgress właśnie m.in. po Twoich postach. porównuje wyniki wydajności mysq vs. postgres i przyznam, że prawie, podkreślam "prawie", nic nie przemawia za postgres. Dodatkowo replikacja jest też sporo utrudniona. żeby nie być gołosłownym pierwszy link porównujący bazy. http://www.progresowi.pl/2011/11/10/porownujemy-wydajnosc-mysql-vs-postgresq... oczywiście w starszych wersjach mysql to postgres wygrywał znacząco. teraz te różnice się zatarły.
Twoim zdaniem, co konkretnie przemawia za postresem?
W dniu 16.10.2012 12:52, Marcin napisał(a):
W dniu 16 października 2012 12:40 użytkownik Tomasz Chiliński tomasz.chilinski@chilan.com napisał:
A ja lubię tak pisać o MySQL, bo zawsze widzę przed oczami rzeszę ludzi męczącą się z MySQL i mi ich trochę żal ;-)
a ja Tomku zastanawiałem się nad przejściem na postgress właśnie m.in [1]. po Twoich postach. porównuje wyniki wydajności mysq vs. postgres i przyznam, że prawie, podkreślam "prawie", nic nie przemawia za postgres. Dodatkowo replikacja jest też sporo utrudniona. żeby nie być gołosłownym pierwszy link porównujący bazy.
http://www.progresowi.pl/2011/11/10/porownujemy-wydajnosc-mysql-vs-postgresq... [2] oczywiście w starszych wersjach mysql to postgres wygrywał znacząco. teraz te różnice się zatarły.
Pod koniec jest to co najbardziej istotne: "Jak widać z rezultatów – MySQL jest bazą idealną do przechowywania mniejszych ilości danych, nie nadaje się z kolei do dużych i skomplikowanych tabel." W przypadku LMS w wielu zapytaniach nie może być mowy o tym, że są to odwołania po prostu tabel SQL. Do tego diagnostyka. MySQL do dziś np. nie dorobił się logowania błędnych zapytań... Nie wspominając o tym, że MySQL coraz bardziej zamykany przez Oracle-a, a PostgreSQL jest niezależny od żadnego producenta. Do tego regularność wydań PostgreSQL, gdzie często nowe wersje powodują wzrost wydajności. W ramach PostgreSQL przyjęto ewolucyjny, stały model rozwoju. W przypadku MySQL brak pomysłu na rozwój...
Twoim zdaniem, co konkretnie przemawia za postresem?
-- Pozdrawiam Marcin / nicraM
W dniu 16.10.2012 12:52, Marcin napisał(a):
W dniu 16 października 2012 12:40 użytkownik Tomasz Chiliński tomasz.chilinski@chilan.com napisał:
A ja lubię tak pisać o MySQL, bo zawsze widzę przed oczami rzeszę ludzi męczącą się z MySQL i mi ich trochę żal ;-)
a ja Tomku zastanawiałem się nad przejściem na postgress właśnie m.in [1]. po Twoich postach. porównuje wyniki wydajności mysq vs. postgres i przyznam, że prawie, podkreślam "prawie", nic nie przemawia za postgres. Dodatkowo replikacja jest też sporo utrudniona. żeby nie być gołosłownym pierwszy link porównujący bazy.
http://www.progresowi.pl/2011/11/10/porownujemy-wydajnosc-mysql-vs-postgresq... [2] oczywiście w starszych wersjach mysql to postgres wygrywał znacząco. teraz te różnice się zatarły.
Twoim zdaniem, co konkretnie przemawia za postresem?
A i z tego co sobie przypominam przy tego typu testach MySQL zawsze był bardziej wydajny niż PostgreSQL i nic dziwnego, bo jak powstawał to miał być czymś podobnym do obecnie popularnego SQLite... Do dziś MySQL ma tryb embedded!
-- Pozdrawiam Marcin / nicraM
W dniu 16 października 2012 13:02 użytkownik Tomasz Chiliński < tomasz.chilinski@chilan.com> napisał:
A i z tego co sobie przypominam przy tego typu testach MySQL zawsze był bardziej wydajny niż PostgreSQL i nic dziwnego, bo jak powstawał to miał być czymś podobnym do obecnie popularnego SQLite... Do dziś MySQL ma tryb embedded!
nie śmiem twierdzić, że nie masz racji. aczkolwiek gdyby replikacja master-master była tak łatwo osiągalna jak w mysql to dłużej bym się napewno nie zastanawiał
Dnia 2012-10-16, wto o godzinie 13:02 +0200, Tomasz Chiliński pisze:
W dniu 16.10.2012 12:52, Marcin napisał(a):
W dniu 16 października 2012 12:40 użytkownik Tomasz Chiliński tomasz.chilinski@chilan.com napisał:
A ja lubię tak pisać o MySQL, bo zawsze widzę przed oczami rzeszę ludzi męczącą się z MySQL i mi ich trochę żal ;-)
a ja Tomku zastanawiałem się nad przejściem na postgress właśnie m.in [1]. po Twoich postach. porównuje wyniki wydajności mysq vs. postgres i przyznam, że prawie, podkreślam "prawie", nic nie przemawia za postgres. Dodatkowo replikacja jest też sporo utrudniona. żeby nie być gołosłownym pierwszy link porównujący bazy.
http://www.progresowi.pl/2011/11/10/porownujemy-wydajnosc-mysql-vs-postgresq... [2] oczywiście w starszych wersjach mysql to postgres wygrywał znacząco. teraz te różnice się zatarły.
Twoim zdaniem, co konkretnie przemawia za postresem?
A i z tego co sobie przypominam przy tego typu testach MySQL zawsze był bardziej wydajny niż PostgreSQL i nic dziwnego, bo jak powstawał to miał być czymś podobnym do obecnie popularnego SQLite... Do dziś MySQL ma tryb embedded!
-- Pozdrawiam Marcin / nicraM
to i ja dołożę swoje 3 grosze.
Wydajność bazy można oceniać jak mamy np. z 1 mln rekordów, przy 3-4k to tak naprawdę decyduje jak jest napisane zapytanie SQL.
W LMS jest obsługa MySQL i PgSQL więc zapytania musza być "uniwersalne", a jak wiadomo co jest uniwersalne to jest do d...y, i w takim przypadku nie uzyskami 100% wydajności dla każdej z baz.
Kiedyś robiłem przeróbkę funkcji getcustomerlist pod kątem wydajności dla MySQL, przy 5k klientach, każdy z nich miał po 36 faktur czas generowania 1 strony był na poziomie 2.2 - 2.6(max) sek, (przy oryginalnym kodzie trwało to ponad 180 sekund, test na starej maszynce) ale ta sama przeróbka w postgresie nie miała racji bytu, PG wysypywał się przy zapytaniu, dla niego była błędna składnia zapytania.
Jedyne co można w tej chwili zrobić dla MySQL to poprawić trochę strukturę bazy danych, typy pól, indexy' itp. czy w niektórych tabelach przejść spowrotem na MyISSAM, na podstawie własnych eksperymentów mogę powiedzieć że można to jeszcze bardziej zoptymalizować i efekty są widoczne.
Co przemawia (jak dla mnie) żeby używać PgSQL, lepsza wydajność przy bardzo złożonych zapytaniach, i to jest jedyna rzecz która mogła by mnie skłonić do używania tej bazy "trwale", pozostałe niuanse jakimi rządzi się PG , zwłaszcza przy dodawaniu/edycji rekordów , dość mocno zniechęcają do używania tej bazy, delikatnie mówiąc PgSQL w zapytaniach nie jest tak "debiloodporny" jak MySQL. (plus dla MySQL)
Na co dzień nie używam PG (tylko jak muszę) , więc nie wiem jak jest w tej chwili, ale swojego czasu (info z różnych for) PG lubił się wysypać, mi MySQL nie padł jeszcze.
Najlepszym rozwiązaniem by było : albo wybranie "jedynej słusznej bazy" i pod nią pisać zapytania , wtedy będzie można wycisnąć soki z bazy, albo pisać osobne zapytania dla MySQL i PgSQL, ale jak życie pokazuje w/w rozwiązania mijają się realiami jakie mamy na co dzień.
MySQL jest naprawdę wydajną bazą, ale muszą być spełnione warunki : struktura i zapytania muszą być zrobione pod tą bazę.
To tyle jeżeli chodzi o spojrzenie na bazy zwykłego śmiertelnika :D
W dniu 2012-10-16 13:45, Sylwester Kondracki pisze:
Dnia 2012-10-16, wto o godzinie 13:02 +0200, Tomasz Chiliński pisze:
W dniu 16.10.2012 12:52, Marcin napisał(a):
W dniu 16 października 2012 12:40 użytkownik Tomasz Chiliński <tomasz.chilinski@chilan.com mailto:tomasz.chilinski@chilan.com> napisał:
A ja lubię tak pisać o MySQL, bo zawsze widzę przed oczami rzeszę ludzi męczącą się z MySQL i mi ich trochę żal ;-)
a ja Tomku zastanawiałem się nad przejściem na postgress właśnie m.in [1]. po Twoich postach. porównuje wyniki wydajności mysq vs. postgres i przyznam, że prawie, podkreślam "prawie", nic nie przemawia za postgres. Dodatkowo replikacja jest też sporo utrudniona. żeby nie być gołosłownym pierwszy link porównujący bazy.
http://www.progresowi.pl/2011/11/10/porownujemy-wydajnosc-mysql-vs-postgresq... [2] oczywiście w starszych wersjach mysql to postgres wygrywał znacząco. teraz te różnice się zatarły.
Twoim zdaniem, co konkretnie przemawia za postresem?
A i z tego co sobie przypominam przy tego typu testach MySQL zawsze był bardziej wydajny niż PostgreSQL i nic dziwnego, bo jak powstawał to miał być czymś podobnym do obecnie popularnego SQLite... Do dziś MySQL ma tryb embedded!
-- Pozdrawiam Marcin / nicraM
to i ja dołożę swoje 3 grosze.
Wydajność bazy można oceniać jak mamy np. z 1 mln rekordów, przy 3-4k to tak naprawdę decyduje jak jest napisane zapytanie SQL.
W LMS jest obsługa MySQL i PgSQL więc zapytania musza być "uniwersalne", a jak wiadomo co jest uniwersalne to jest do d...y, i w takim przypadku nie uzyskami 100% wydajności dla każdej z baz.
Kiedyś robiłem przeróbkę funkcji getcustomerlist pod kątem wydajności dla MySQL, przy 5k klientach, każdy z nich miał po 36 faktur czas generowania 1 strony był na poziomie 2.2 - 2.6(max) sek, (przy oryginalnym kodzie trwało to ponad 180 sekund, test na starej maszynce) ale ta sama przeróbka w postgresie nie miała racji bytu, PG wysypywał się przy zapytaniu, dla niego była błędna składnia zapytania.
Jedyne co można w tej chwili zrobić dla MySQL to poprawić trochę strukturę bazy danych, typy pól, indexy' itp. czy w niektórych tabelach przejść spowrotem na MyISSAM, na podstawie własnych eksperymentów mogę powiedzieć że można to jeszcze bardziej zoptymalizować i efekty są widoczne.
Co przemawia (jak dla mnie) żeby używać PgSQL, lepsza wydajność przy bardzo złożonych zapytaniach, i to jest jedyna rzecz która mogła by mnie skłonić do używania tej bazy "trwale", pozostałe niuanse jakimi rządzi się PG , zwłaszcza przy dodawaniu/edycji rekordów , dość mocno zniechęcają do używania tej bazy, delikatnie mówiąc PgSQL w zapytaniach nie jest tak "debiloodporny" jak MySQL. (plus dla MySQL)
Na co dzień nie używam PG (tylko jak muszę) , więc nie wiem jak jest w tej chwili, ale swojego czasu (info z różnych for) PG lubił się wysypać, mi MySQL nie padł jeszcze.
Najlepszym rozwiązaniem by było : albo wybranie "jedynej słusznej bazy" i pod nią pisać zapytania , wtedy będzie można wycisnąć soki z bazy, albo pisać osobne zapytania dla MySQL i PgSQL, ale jak życie pokazuje w/w rozwiązania mijają się realiami jakie mamy na co dzień.
MySQL jest naprawdę wydajną bazą, ale muszą być spełnione warunki : struktura i zapytania muszą być zrobione pod tą bazę.
To tyle jeżeli chodzi o spojrzenie na bazy zwykłego śmiertelnika :D
lms mailing list lms@lists.lms.org.pl http://lists.lms.org.pl/mailman/listinfo/lms
Również uważam iż powinna zostać wybrana jedna z tych baz. Zrobić ankietę (za i przeciw) i działać tylko na jednym.
W dniu 16.10.2012 13:45, Sylwester Kondracki napisał(a):
Dnia 2012-10-16, wto o godzinie 13:02 +0200, Tomasz Chiliński pisze:
W dniu 16.10.2012 12:52, Marcin napisał(a):
W dniu 16 października 2012 12:40 użytkownik Tomasz Chiliński tomasz.chilinski@chilan.com napisał:
A ja lubię tak pisać o MySQL, bo zawsze widzę przed oczami rzeszę ludzi męczącą się z MySQL i mi ich trochę żal ;-)
a ja Tomku zastanawiałem się nad przejściem na postgress właśnie m.in [1]. po Twoich postach. porównuje wyniki wydajności mysq vs. postgres i przyznam, że prawie, podkreślam "prawie", nic nie przemawia za postgres. Dodatkowo replikacja jest też sporo utrudniona. żeby nie być gołosłownym pierwszy link porównujący bazy.
http://www.progresowi.pl/2011/11/10/porownujemy-wydajnosc-mysql-vs-postgresq... [1] [2] oczywiście w starszych wersjach mysql to postgres wygrywał znacząco. teraz te różnice się zatarły.
Twoim zdaniem, co konkretnie przemawia za postresem?
A i z tego co sobie przypominam przy tego typu testach MySQL zawsze był bardziej wydajny niż PostgreSQL i nic dziwnego, bo jak powstawał to miał być czymś podobnym do obecnie popularnego SQLite... Do dziś MySQL ma tryb embedded!
-- Pozdrawiam Marcin / nicraM
to i ja dołożę swoje 3 grosze.
Wydajność bazy można oceniać jak mamy np. z 1 mln rekordów, przy 3-4k to tak naprawdę decyduje jak jest napisane zapytanie SQL.
W LMS jest obsługa MySQL i PgSQL więc zapytania musza być "uniwersalne", a jak wiadomo co jest uniwersalne to jest do d...y, i w takim przypadku nie uzyskami 100% wydajności dla każdej z baz.
Kiedyś robiłem przeróbkę funkcji getcustomerlist pod kątem wydajności dla MySQL, przy 5k klientach, każdy z nich miał po 36 faktur czas generowania 1 strony był na poziomie 2.2 - 2.6(max) sek, (przy oryginalnym kodzie trwało to ponad 180 sekund, test na starej maszynce) ale ta sama przeróbka w postgresie nie miała racji bytu, PG wysypywał się przy zapytaniu, dla niego była błędna składnia zapytania.
Jedyne co można w tej chwili zrobić dla MySQL to poprawić trochę strukturę bazy danych, typy pól, indexy' itp. czy w niektórych tabelach przejść spowrotem na MyISSAM, na podstawie własnych eksperymentów mogę powiedzieć że można to jeszcze bardziej zoptymalizować i efekty są widoczne.
Co przemawia (jak dla mnie) żeby używać PgSQL, lepsza wydajność przy bardzo złożonych zapytaniach, i to jest jedyna rzecz która mogła by mnie skłonić do używania tej bazy "trwale", pozostałe niuanse jakimi rządzi się PG , zwłaszcza przy dodawaniu/edycji rekordów , dość mocno zniechęcają do używania tej bazy, delikatnie mówiąc PgSQL w zapytaniach nie jest tak "debiloodporny" jak MySQL. (plus dla MySQL)
Na co dzień nie używam PG (tylko jak muszę) , więc nie wiem jak jest w tej chwili, ale swojego czasu (info z różnych for) PG lubił się wysypać, mi MySQL nie padł jeszcze.
To bardzo interesujące - u mnie MySQL, gdy nastąpi zanik zasilania ma problemy sam ze sobą, czego ani razu nie doświadczyłem w PgSQL.
Najlepszym rozwiązaniem by było : albo wybranie "jedynej słusznej bazy" i pod nią pisać zapytania , wtedy będzie można wycisnąć soki z bazy, albo pisać osobne zapytania dla MySQL i PgSQL, ale jak życie pokazuje w/w rozwiązania mijają się realiami jakie mamy na co dzień.
MySQL jest naprawdę wydajną bazą, ale muszą być spełnione warunki : struktura i zapytania muszą być zrobione pod tą bazę.
To tyle jeżeli chodzi o spojrzenie na bazy zwykłego śmiertelnika :D
W dniu 16.10.2012 13:02, Tomasz Chiliński pisze:
A i z tego co sobie przypominam przy tego typu testach MySQL zawsze był bardziej wydajny niż PostgreSQL i nic dziwnego, bo jak powstawał to miał być czymś podobnym do obecnie popularnego SQLite... Do dziś MySQL ma tryb embedded!
a czemu nie firebird? ma lepsze frontedny (szukałem do postgresa ale znalazałem jakieś raczkujące via www postgress admin czy coś podobnego)
paweł
On Tue, 16 Oct 2012 12:13:44 +0200, "Admin - Dar.Net" admin@darnet.pl wrote:
W dniu 2012-10-16 11:35, Daniel Kulesza pisze:
W dniu 2012-10-16 11:22, LJ pisze:
Ten skrypt działa korzystam z niego codziennie od kilku lat, podobnie kilka firm. A że można przez e-mail? Pewnie że można, ważne że wybór jest :-).
Dariusz Kowalczyk
Ten skrypt dzialal przez ostatnie kilka lat z mniejszymi czy wiekszymi wpadkami. Natomiast po ostatnim weekendzie przestal dzialac, zmienila sie jak to bank nazywa aplikacja rapkm. Znaczy portal, do ktorego skrypt
sie
loguje w celu pobrania plikow z wplatami. Z mojego krotkiego
rekonesansu
zmienilo sie szyfrowanie i struktura samego portalu. Wczesniej w zakladce raporty byly widoczne wszystkie pliki, jakie bylo mozna pobrac. W tej chwili jest formularz, w ktorym nalezy wpisac date i widoczny bedzie jeden plik o ile nie minelo wiecej niz 30 dni od jego publikacji.
Jesli chodzi o dorzucenie sie do nowego skryptu, to ja sie na to
pisze.
Za namową Tomka przechodzę na raporty otrzymywane mailem i taki skrypt będzie pisany. Nie chcę aby za chwilę znów trzeba było pisać nowy skrypt bo coś się zmieniło na stronie.
lms mailing list lms@lists.lms.org.pl http://lists.lms.org.pl/mailman/listinfo/lms
Taki skrypt jest już dawno napisany, mnóstwo ludzi korzysta z takiego rozwiązania, dodam też że bank millenium ma podobny do bzwbk format plików csv i też wysyła na maila i też taki skrypt jest.
To podeślij :-) ja działający do "wczoraj dla bzwbk" dołączyłem do repo lms juz parę lat temu :-)
Swoją drogą w tym BZWBK to trochę ludzie bez wyobraźni pracują (żeby nie używać innych słów) nawet e-maila nie wysłali z powiadomieniem że coś zmieniają ... amatorka.
W dniu 16.10.2012 12:27, Dariusz Kowalczyk napisał(a):
On Tue, 16 Oct 2012 12:13:44 +0200, "Admin - Dar.Net" admin@darnet.pl wrote:
W dniu 2012-10-16 11:35, Daniel Kulesza pisze:
W dniu 2012-10-16 11:22, LJ pisze:
Ten skrypt działa korzystam z niego codziennie od kilku lat, podobnie kilka firm. A że można przez e-mail? Pewnie że można, ważne że wybór jest :-).
Dariusz Kowalczyk
Ten skrypt dzialal przez ostatnie kilka lat z mniejszymi czy wiekszymi wpadkami. Natomiast po ostatnim weekendzie przestal dzialac, zmienila sie jak to bank nazywa aplikacja rapkm. Znaczy portal, do ktorego skrypt
sie
loguje w celu pobrania plikow z wplatami. Z mojego krotkiego
rekonesansu
zmienilo sie szyfrowanie i struktura samego portalu. Wczesniej w zakladce raporty byly widoczne wszystkie pliki, jakie bylo mozna pobrac. W tej chwili jest formularz, w ktorym nalezy wpisac date i widoczny bedzie jeden plik o ile nie minelo wiecej niz 30 dni od jego publikacji.
Jesli chodzi o dorzucenie sie do nowego skryptu, to ja sie na to
pisze.
Za namową Tomka przechodzę na raporty otrzymywane mailem i taki skrypt będzie pisany. Nie chcę aby za chwilę znów trzeba było pisać nowy skrypt bo coś się zmieniło na stronie.
Taki skrypt jest już dawno napisany, mnóstwo ludzi korzysta z takiego rozwiązania, dodam też że bank millenium ma podobny do bzwbk format plików csv i też wysyła na maila i też taki skrypt jest.
To podeślij :-) ja działający do "wczoraj dla bzwbk" dołączyłem do repo lms juz parę lat temu :-)
Swoją drogą w tym BZWBK to trochę ludzie bez wyobraźni pracują (żeby nie używać innych słów) nawet e-maila nie wysłali z powiadomieniem że coś zmieniają ... amatorka.
Do tego obecne uwierzytelnianie działa w oparciu o javascript i powoduje niemożność zapamiętania oryginalnego loginu i hasła w oparciu o mechanizmy dostępne w przeglądarce. Fuszerka na maksa...
tego obecne uwierzytelnianie działa w oparciu o javascript i
powoduje niemożność zapamiętania oryginalnego loginu i hasła w oparciu o mechanizmy dostępne w przeglądarce. Fuszerka na maksa...
e to jeszcze nic ... parę lat temu ręcznie dopisywali (po awarii u siebie) wpłaty do archiwalnych plików raportów zamiast stworzyć nowe :-). Tylko przypadkiem to wtedy zauważyłem i zaprotestowałem ... od tego czasu juz tak nie robili i generowali w takich przypadkach nowe pliki :-) Więc amatorstwo ma u nich długa tradycję. p.s. Ale tani są więc co z tego, ze np pko sa miało to od poczatku do konca przemyslane i zrobione ja nalezy jak byli drodzy
W dniu 16.10.2012 12:35, Dariusz Kowalczyk napisał(a):
tego obecne uwierzytelnianie działa w oparciu o javascript i
powoduje niemożność zapamiętania oryginalnego loginu i hasła w oparciu o mechanizmy dostępne w przeglądarce. Fuszerka na maksa...
e to jeszcze nic ... parę lat temu ręcznie dopisywali (po awarii u siebie) wpłaty do archiwalnych plików raportów zamiast stworzyć nowe :-). Tylko przypadkiem to wtedy zauważyłem i zaprotestowałem ... od tego czasu juz tak nie robili i generowali w takich przypadkach nowe pliki :-) Więc amatorstwo ma u nich długa tradycję. p.s. Ale tani są więc co z tego, ze np pko sa miało to od poczatku do konca przemyslane i zrobione ja nalezy jak byli drodzy
A BGŻ? Widzę, że to póki co działa sensownie od paru lat, a drodzy chyba nie są, choć pewnie "drodzy" czy "tani" to pojęcie względne.
Za namową Tomka przechodzę na raporty otrzymywane mailem i taki skrypt będzie pisany. Nie chcę aby za chwilę znów trzeba było pisać nowy skrypt
bo coś się zmieniło na stronie.
lms mailing list lms@lists.lms.org.pl http://lists.lms.org.pl/mailman/listinfo/lms
Jak ktoś mimo wszystko potrzebuje się poratować na dziś. To poniżej jest ten skrypt przerobiony i przyjmuje jako parametr nazwę pliku sciągnietego raportu (login i hasło nie są potrzebne bo pliki trzeba ściągnąć samemu) Powinno wystarczyć na parę dni żeby przetrwać trudne chwile :-)
uczestnicy (9)
-
Admin - Dar.Net -
AREK. K. -
Daniel Kulesza -
Dariusz Kowalczyk -
LJ -
Marcin -
Paweł Rohde -
Sylwester Kondracki -
Tomasz Chiliński