eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plGrupypl.comp.programming[OT] Duża kasa i kiepski wynik - dlaczego?
Ilość wypowiedzi w tym wątku: 287

  • 51. Data: 2015-07-29 10:19:14
    Temat: Re: [OT] Duża kasa i kiepski wynik - dlaczego?
    Od: "M.M." <m...@g...com>

    On Wednesday, July 29, 2015 at 9:54:06 AM UTC+2, Piotr Chamera wrote:
    > W dniu 2015-07-29 o 09:42, M.M. pisze:
    > > On Wednesday, July 29, 2015 at 7:37:32 AM UTC+2, Tomasz Kaczanowski wrote:
    > >> Jeśli źle zaprojektowano bazę, to właśnie nie wytrzymała obciążenia i
    > >> dodatkowo nie potrafiła sobie poradzić z sytuacją ekstremalną i dane
    > >> były niespójne.
    > > Ale po kiego tutaj jakoś szczególnie projektować? Nie było żadnej
    > > ekstremalnej sytuacji.
    >
    > Tak "pomyśleli", nie zaprojektowali i mieliśmy "ekstremalną sytuację"...
    Przez 1s można trochę danych i siecią przesłać, i na dysku zapisać, nie
    wspomniawszy o zapisach w buforach RAM. Zapytań było 2500. Czas ktoś
    oszacował na 1h. Średnio wychodzi jedno zapytanie na 1s. Gdzie widzisz
    ekstremalną sytuację?

    Zaczęli projektować i skopali, jakby po prostu zrobili
    1) połączenie
    2) transfer
    3) zapis
    4) rozłączenie
    To pewnie by wytrzymało, zwłaszcza na kilku komputerach.






  • 52. Data: 2015-07-29 10:30:57
    Temat: Re: [OT] Duża kasa i kiepski wynik - dlaczego?
    Od: "Stachu 'Dozzie' K." <d...@g...eat.some.screws.spammer.invalid>

    On 2015-07-29, szemrany <s...@o...off> wrote:
    >>> I skąd przekonanie o braku potrzeby szybkiego przelewu u Kowalskiego? Gdyby
    >>> to była prawda nie istniałyby BlueCashe, Przelewy24, DotPaye, PayPale,
    >>> Transferuje, Payu, zPay, PayByNet, ePrzelerwy, YetiPay i pewnie jeszcze
    >>> jakieś. Zgodzisz się?
    >>
    >> Ja się nie zgodzę. Pieniądze z tych usług "płatności ekspresowych" nadal
    >> idzie dwa-trzy dni. To nie o szybkość przelewu chodzi, tylko
    >> o automatyzację księgowania wpłaty i natychmiastowe potwierdzenie
    >> zlecenia przelewu.
    >
    > Możesz się nie zgadzać, ale:
    > a) pieniądz idzie natychmiast, bo każdy z tych pośredników ma rachunki we
    > wszystkich obsługiwanych bankach i klient robiąc przelew z np. ING na PKO
    > robi de facto do ichniego ING, a oni ze swojego PKO do odbiorcy docelowego
    > - online.

    Idzie? Widziałeś od strony osoby sprzedającej? Bo ja w którymś momencie
    widziałem warunki i stało, że idzie dwa-trzy dni.

    > b) kompletnie mnie czy Kowalskiego jako klienta nie obchodzi mechanizm
    > działania tylko efekt, robię przelew i po 15 sekundach jest u odbiorcy na
    > koncie. Koniec tematu. Wszyscy zadowoleni.

    Nie. Ciebie jako Kowalskiego nie interesuje kiedy u odbiorcy przelew
    dojdzie. Ciebie interesuje, że automat odbiorcy natychmiast wie, że
    zapłaciłeś (czyli nie ma czekania na reakcję człowieka następnego dnia
    roboczego). I dokładnie to jest realizowane: sprzedający od razu dostaje
    potwierdzenie i to potwierdzenie jest przetwarzalne maszynowo.

    --
    Secunia non olet.
    Stanislaw Klekot


  • 53. Data: 2015-07-29 10:50:30
    Temat: Re: [OT] Duża kasa i kiepski wynik - dlaczego?
    Od: Tomasz Kaczanowski <kaczus@dowyciecia_poczta.onet.pl>

    W dniu 2015-07-29 10:19, M.M. pisze:
    > On Wednesday, July 29, 2015 at 9:54:06 AM UTC+2, Piotr Chamera wrote:
    >> W dniu 2015-07-29 o 09:42, M.M. pisze:
    >>> On Wednesday, July 29, 2015 at 7:37:32 AM UTC+2, Tomasz Kaczanowski wrote:
    >>>> Jeśli źle zaprojektowano bazę, to właśnie nie wytrzymała obciążenia i
    >>>> dodatkowo nie potrafiła sobie poradzić z sytuacją ekstremalną i dane
    >>>> były niespójne.
    >>> Ale po kiego tutaj jakoś szczególnie projektować? Nie było żadnej
    >>> ekstremalnej sytuacji.
    >>
    >> Tak "pomyśleli", nie zaprojektowali i mieliśmy "ekstremalną sytuację"...
    > Przez 1s można trochę danych i siecią przesłać, i na dysku zapisać, nie
    > wspomniawszy o zapisach w buforach RAM. Zapytań było 2500. Czas ktoś
    > oszacował na 1h. Średnio wychodzi jedno zapytanie na 1s. Gdzie widzisz
    > ekstremalną sytuację?
    >
    > Zaczęli projektować i skopali, jakby po prostu zrobili
    > 1) połączenie
    > 2) transfer
    > 3) zapis
    > 4) rozłączenie
    > To pewnie by wytrzymało, zwłaszcza na kilku komputerach.

    obawiam się, że właśnie tak zaprojektowali. To, że coś w laboratorium
    trwa 1s, nie znaczy, że tyle będzie trwało w rzeczywistości, kwestia
    jakości łącza, dodatkowo - zapis powinien być w transakcji, żeby nie
    było wpadek, że dane się rozjeżdżają, bo wydarzyło się coś
    nieprzewidzianego. Ze względu na to by kontrolować poprawność, powinny
    się zapisać nie tylko dane, ale również kto je wysłał, o której godzinie
    i jakie dane te dane MUSZĄ być spójne i dobrze by były to 2 rożne
    dokumenty - tak jak jest to przyjęte w dobrych programach księgowych -
    że jeśli rozjadą się dane w jednym miejscu - można ich poprawność
    sprawdzić pobierając dane inaczej zapisane - do innych celów. Więc tu
    nie chodzi o wydajność maszyny na której chodzi serwer - ale wydajność
    łącza oraz projekt bazy. I tu posypały się obie rzeczy - najpierw nie
    wytrzymało łącze, a następnie okazało się, że dane nie zostały zapisany
    w sposób spójny, tak więc nikt nie wiedział, czy wszystko co zostało
    wysłane zostało prawidłowo zapisane.


    --
    Kaczus
    http://kaczus.ppa.pl


  • 54. Data: 2015-07-29 11:07:59
    Temat: Re: [OT] Duża kasa i kiepski wynik - dlaczego?
    Od: "M.M." <m...@g...com>

    On Wednesday, July 29, 2015 at 10:51:04 AM UTC+2, Tomasz Kaczanowski wrote:
    > W dniu 2015-07-29 10:19, M.M. pisze:
    > > On Wednesday, July 29, 2015 at 9:54:06 AM UTC+2, Piotr Chamera wrote:
    > >> W dniu 2015-07-29 o 09:42, M.M. pisze:
    > >>> On Wednesday, July 29, 2015 at 7:37:32 AM UTC+2, Tomasz Kaczanowski wrote:
    > >>>> Jeśli źle zaprojektowano bazę, to właśnie nie wytrzymała obciążenia i
    > >>>> dodatkowo nie potrafiła sobie poradzić z sytuacją ekstremalną i dane
    > >>>> były niespójne.
    > >>> Ale po kiego tutaj jakoś szczególnie projektować? Nie było żadnej
    > >>> ekstremalnej sytuacji.
    > >>
    > >> Tak "pomyśleli", nie zaprojektowali i mieliśmy "ekstremalną sytuację"...
    > > Przez 1s można trochę danych i siecią przesłać, i na dysku zapisać, nie
    > > wspomniawszy o zapisach w buforach RAM. Zapytań było 2500. Czas ktoś
    > > oszacował na 1h. Średnio wychodzi jedno zapytanie na 1s. Gdzie widzisz
    > > ekstremalną sytuację?
    > >
    > > Zaczęli projektować i skopali, jakby po prostu zrobili
    > > 1) połączenie
    > > 2) transfer
    > > 3) zapis
    > > 4) rozłączenie
    > > To pewnie by wytrzymało, zwłaszcza na kilku komputerach.
    >
    > obawiam się, że właśnie tak zaprojektowali.
    Jaki konkretnie widzisz problem w tym schemacie?


    > To, że coś w laboratorium
    > trwa 1s, nie znaczy, że tyle będzie trwało w rzeczywistości,
    Dlaczego w rzeczywistości nie można podpiąć kilku komputerów na
    zapas?

    > kwestia jakości łącza, dodatkowo -
    Kilka łączy trzeba użyć.

    > zapis powinien być w transakcji, żeby nie
    > było wpadek, że dane się rozjeżdżają, bo wydarzyło się coś
    > nieprzewidzianego.
    No pewnie, ale to może nawet przyspieszać operacje. Bez jawnych
    transakcji, każde zapytanie jest obejmowane transakcją.

    > Ze względu na to by kontrolować poprawność, powinny
    > się zapisać nie tylko dane, ale również kto je wysłał, o której godzinie
    > i jakie dane te dane MUSZĄ być spójne i dobrze by były to 2 rożne
    > dokumenty - tak jak jest to przyjęte w dobrych programach księgowych -
    > że jeśli rozjadą się dane w jednym miejscu - można ich poprawność
    > sprawdzić pobierając dane inaczej zapisane - do innych celów.
    To wszystko też da się podciągnąć pod tamten najprostszy schemat.

    > Więc tu
    > nie chodzi o wydajność maszyny na której chodzi serwer - ale wydajność
    > łącza oraz projekt bazy.
    Ale w takim prostym schemacie można ekstremalnie powielać maszyny z
    łączami.

    > I tu posypały się obie rzeczy - najpierw nie
    > wytrzymało łącze, a następnie okazało się, że dane nie zostały zapisany
    > w sposób spójny, tak więc nikt nie wiedział, czy wszystko co zostało
    > wysłane zostało prawidłowo zapisane.
    Nie wiem co tam się stało, ale to co opisujecie, nie wydaje się jakoś
    specjalnie trudne. Owszem, może być, gdy się dorzuca do tego schematu
    jakieś ciężkie przetwarzanie... Przy przetwarzaniu wszystko może
    pójść nie tak jak powinno.

    W podobnej sytuacji stosuję liniową
    tabelę. Dane są tylko zapisywane. Potem dane są traktowane jak
    kolejka do przetwarzania. Jeśli przy przetwarzaniu narobię błędów, to
    wynik skasuję, poprawię błędy i odpalam skrypt na nowo. Ostatnio
    skorygowałem w ten sposób błąd który zaburzał wyniki od kilku miesięcy.




  • 55. Data: 2015-07-29 11:13:45
    Temat: Re: [OT] Duża kasa i kiepski wynik - dlaczego?
    Od: "Stachu 'Dozzie' K." <d...@g...eat.some.screws.spammer.invalid>

    On 2015-07-29, M.M. <m...@g...com> wrote:
    >> To, że coś w laboratorium
    >> trwa 1s, nie znaczy, że tyle będzie trwało w rzeczywistości,
    > Dlaczego w rzeczywistości nie można podpiąć kilku komputerów na
    > zapas?

    Bo ani systemy rozproszone, ani nawet redundancja w ramach jednej sieci
    (jeden segment ethernetowy) nie działają w ten sposób. Nie da się po
    prostu rzucić dwa razy więcej maszyn i nagle przyjąć dwa razy większy
    ruch, jeśli system nie został do tego specjalnie zaprojektowany.

    >> zapis powinien być w transakcji, żeby nie
    >> było wpadek, że dane się rozjeżdżają, bo wydarzyło się coś
    >> nieprzewidzianego.
    > No pewnie, ale to może nawet przyspieszać operacje. Bez jawnych
    > transakcji, każde zapytanie jest obejmowane transakcją.

    Nie rozumiesz do czego służą transakcje, prawda? Zresztą niby skąd.
    Jakiś czas temu się przyznałeś, że nie jesteś programistą i właściwie to
    się na tym nie znasz na poziomie zawodowym.

    Transakcje służą do zapewnienia, że *dwa lub więcej* zapisów są albo
    wykonane w komplecie, albo nie wykonane wcale.

    --
    Secunia non olet.
    Stanislaw Klekot


  • 56. Data: 2015-07-29 11:36:11
    Temat: Re: [OT] Duża kasa i kiepski wynik - dlaczego?
    Od: "M.M." <m...@g...com>

    On Wednesday, July 29, 2015 at 11:13:46 AM UTC+2, Stachu 'Dozzie' K. wrote:
    > On 2015-07-29, M.M. wrote:
    > >> To, że coś w laboratorium
    > >> trwa 1s, nie znaczy, że tyle będzie trwało w rzeczywistości,
    > > Dlaczego w rzeczywistości nie można podpiąć kilku komputerów na
    > > zapas?
    >
    > Bo ani systemy rozproszone, ani nawet redundancja w ramach jednej sieci
    > (jeden segment ethernetowy) nie działają w ten sposób. Nie da się po
    > prostu rzucić dwa razy więcej maszyn i nagle przyjąć dwa razy większy
    > ruch, jeśli system nie został do tego specjalnie zaprojektowany.
    Nie zrozumiałeś o czym jest ta rozmowa, wróć i doczytaj.

    >
    > >> zapis powinien być w transakcji, żeby nie
    > >> było wpadek, że dane się rozjeżdżają, bo wydarzyło się coś
    > >> nieprzewidzianego.
    > > No pewnie, ale to może nawet przyspieszać operacje. Bez jawnych
    > > transakcji, każde zapytanie jest obejmowane transakcją.
    >
    > Nie rozumiesz do czego służą transakcje, prawda? Zresztą niby skąd.
    > Jakiś czas temu się przyznałeś, że nie jesteś programistą i właściwie to
    > się na tym nie znasz na poziomie zawodowym.
    >
    > Transakcje służą do zapewnienia, że *dwa lub więcej* zapisów są albo
    > wykonane w komplecie, albo nie wykonane wcale.
    Jak wyżej, czytaj ze zrozumieniem.


  • 57. Data: 2015-07-29 11:50:18
    Temat: Re: [OT] Duża kasa i kiepski wynik - dlaczego?
    Od: "Stachu 'Dozzie' K." <d...@g...eat.some.screws.spammer.invalid>

    On 2015-07-29, M.M. <m...@g...com> wrote:
    > On Wednesday, July 29, 2015 at 11:13:46 AM UTC+2, Stachu 'Dozzie' K. wrote:
    >> On 2015-07-29, M.M. wrote:
    >> >> To, że coś w laboratorium
    >> >> trwa 1s, nie znaczy, że tyle będzie trwało w rzeczywistości,
    >> > Dlaczego w rzeczywistości nie można podpiąć kilku komputerów na
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    ^^^^^^^^
    >> > zapas?
    >>
    >> Bo ani systemy rozproszone, ani nawet redundancja w ramach jednej sieci
    >> (jeden segment ethernetowy) nie działają w ten sposób. Nie da się po
    >> prostu rzucić dwa razy więcej maszyn i nagle przyjąć dwa razy większy
    >> ruch, jeśli system nie został do tego specjalnie zaprojektowany.
    > Nie zrozumiałeś o czym jest ta rozmowa, wróć i doczytaj.

    Nie zrozumiałeś co sam napisałeś. Wróć i doczytaj.

    >> >> zapis powinien być w transakcji, żeby nie
    >> >> było wpadek, że dane się rozjeżdżają, bo wydarzyło się coś
    >> >> nieprzewidzianego.
    >> > No pewnie, ale to może nawet przyspieszać operacje. Bez jawnych
    >> > transakcji, każde zapytanie jest obejmowane transakcją.
    >>
    >> Nie rozumiesz do czego służą transakcje, prawda? Zresztą niby skąd.
    >> Jakiś czas temu się przyznałeś, że nie jesteś programistą i właściwie to
    >> się na tym nie znasz na poziomie zawodowym.
    >>
    >> Transakcje służą do zapewnienia, że *dwa lub więcej* zapisów są albo
    >> wykonane w komplecie, albo nie wykonane wcale.
    > Jak wyżej, czytaj ze zrozumieniem.

    No to wyjaśnij, gdzie się rozminąłem z tematem rozmowy? (Bieżącym
    tematem!) Bo rzucać "nie rozómisz; czytaj ze zrozumieniem" bez żadnego
    uzasadnienia jest łatwo.

    --
    Secunia non olet.
    Stanislaw Klekot


  • 58. Data: 2015-07-29 12:00:18
    Temat: Re: [OT] Duża kasa i kiepski wynik - dlaczego?
    Od: "M.M." <m...@g...com>

    On Wednesday, July 29, 2015 at 11:50:19 AM UTC+2, Stachu 'Dozzie' K. wrote:
    > On 2015-07-29, M.M. wrote:
    > > On Wednesday, July 29, 2015 at 11:13:46 AM UTC+2, Stachu 'Dozzie' K. wrote:
    > >> On 2015-07-29, M.M. wrote:
    > >> >> To, że coś w laboratorium
    > >> >> trwa 1s, nie znaczy, że tyle będzie trwało w rzeczywistości,
    > >> > Dlaczego w rzeczywistości nie można podpiąć kilku komputerów na
    > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    ^^^^^^^^
    > >> > zapas?
    > >>
    > >> Bo ani systemy rozproszone, ani nawet redundancja w ramach jednej sieci
    > >> (jeden segment ethernetowy) nie działają w ten sposób. Nie da się po
    > >> prostu rzucić dwa razy więcej maszyn i nagle przyjąć dwa razy większy
    > >> ruch, jeśli system nie został do tego specjalnie zaprojektowany.
    > > Nie zrozumiałeś o czym jest ta rozmowa, wróć i doczytaj.
    >
    > Nie zrozumiałeś co sam napisałeś. Wróć i doczytaj.
    >
    > >> >> zapis powinien być w transakcji, żeby nie
    > >> >> było wpadek, że dane się rozjeżdżają, bo wydarzyło się coś
    > >> >> nieprzewidzianego.
    > >> > No pewnie, ale to może nawet przyspieszać operacje. Bez jawnych
    > >> > transakcji, każde zapytanie jest obejmowane transakcją.
    > >>
    > >> Nie rozumiesz do czego służą transakcje, prawda? Zresztą niby skąd.
    > >> Jakiś czas temu się przyznałeś, że nie jesteś programistą i właściwie to
    > >> się na tym nie znasz na poziomie zawodowym.
    > >>
    > >> Transakcje służą do zapewnienia, że *dwa lub więcej* zapisów są albo
    > >> wykonane w komplecie, albo nie wykonane wcale.
    > > Jak wyżej, czytaj ze zrozumieniem.
    >
    > No to wyjaśnij, gdzie się rozminąłem z tematem rozmowy? (Bieżącym
    > tematem!) Bo rzucać "nie rozómisz; czytaj ze zrozumieniem" bez żadnego
    > uzasadnienia jest łatwo.
    Rozminąłeś się w dwóch lub trzech momentach w jednym poście, za
    dużo pisania. Poza tym szkoda czas na tłumaczenie komuś, kto
    jeszcze nigdy poprawnie nie zrozumiał mojej wypowiedzi.

    >
    > --
    > Secunia non olet.
    > Stanislaw Klekot


  • 59. Data: 2015-07-29 12:10:51
    Temat: Re: [OT] Duża kasa i kiepski wynik - dlaczego?
    Od: Piotr Chamera <p...@p...onet.pl>

    W dniu 2015-07-29 o 10:19, M.M. pisze:
    > On Wednesday, July 29, 2015 at 9:54:06 AM UTC+2, Piotr Chamera
    > wrote:
    >> W dniu 2015-07-29 o 09:42, M.M. pisze:
    >>> On Wednesday, July 29, 2015 at 7:37:32 AM UTC+2, Tomasz
    >>> Kaczanowski wrote:
    >>>> Jeśli źle zaprojektowano bazę, to właśnie nie wytrzymała
    >>>> obciążenia i dodatkowo nie potrafiła sobie poradzić z sytuacją
    >>>> ekstremalną i dane były niespójne.
    >>> Ale po kiego tutaj jakoś szczególnie projektować? Nie było
    >>> żadnej ekstremalnej sytuacji.
    >>
    >> Tak "pomyśleli", nie zaprojektowali i mieliśmy "ekstremalną
    >> sytuację"...
    > Przez 1s można trochę danych i siecią przesłać, i na dysku zapisać,
    > nie wspomniawszy o zapisach w buforach RAM. Zapytań było 2500. Czas
    > ktoś oszacował na 1h. Średnio wychodzi jedno zapytanie na 1s. Gdzie
    > widzisz ekstremalną sytuację?

    moje ,,pomyśleli", to np. twoje ,,Przez 1s można trochę danych i siecią
    przesłać, i na dysku zapisać, nie wspomniawszy o zapisach w buforach
    RAM. Zapytań było 2500. Czas ktoś oszacował na 1h. Średnio wychodzi
    jedno zapytanie na 1s." więc robimy na pałę...

    a ,,ekstremalna sytuacja", to rzeczywisty efekt działania takiego
    nieprzemyślanego systemu, który obserwowaliśmy w praktyce podczas
    wyborów.

    > Zaczęli projektować i skopali, jakby po prostu zrobili

    to nie jest proste (albo może precyzyjniej byłoby powiedzieć, że to nie
    jest wielki system [czyli w pewnym sensie prosty], ale jednak kilka
    rzeczy wymaga przemyślenia i zaprojektowania).

    > 1) połączenie

    obsługujemy tylko jedno połączenie jednocześnie? czy więcej? jeśli
    więcej, to ile? wszystkie 2500 jednocześnie (bo tak też może się
    zdarzyć)? jeśli jedno, to co jeśli klient się połączył i nie przesyła
    danych, a inni czekają? jeśli pula połączeń jest ograniczona, to co
    robimy z nadmiarowymi? itd...

    na dalszych etapach masz podobne wybory, które wpływają na przyjęte
    rozwiązania i musisz wybrać tak, aby żadna sekwencja możliwych zdarzeń
    nie prowadziła do awarii...


  • 60. Data: 2015-07-29 12:35:33
    Temat: Re: [OT] Duża kasa i kiepski wynik - dlaczego?
    Od: "M.M." <m...@g...com>

    On Wednesday, July 29, 2015 at 12:10:56 PM UTC+2, Piotr Chamera wrote:
    > a "ekstremalna sytuacja", to rzeczywisty efekt działania takiego
    > nieprzemyślanego systemu, który obserwowaliśmy w praktyce podczas
    > wyborów.
    Rozmawiamy o jednym elemencie tego systemu: zbieranie danych.

    > > Zaczęli projektować i skopali, jakby po prostu zrobili
    >
    > to nie jest proste (albo może precyzyjniej byłoby powiedzieć, że to nie
    > jest wielki system [czyli w pewnym sensie prosty], ale jednak kilka
    > rzeczy wymaga przemyślenia i zaprojektowania).
    Jak pisałem kilka postów wcześniej: nie dziwię się że padło jako
    całość. Dziwię się, że stracili dane, że trzeba było wprowadzać od
    nowa, że czekali aż tak długo... i nie wiem jakie tam jeszcze były problemy.

    >
    > > 1) połączenie
    >
    > obsługujemy tylko jedno połączenie jednocześnie? czy więcej? jeśli
    > więcej, to ile? wszystkie 2500 jednocześnie (bo tak też może się
    > zdarzyć)? jeśli jedno, to co jeśli klient się połączył i nie przesyła
    > danych, a inni czekają? jeśli pula połączeń jest ograniczona, to co
    > robimy z nadmiarowymi? itd...
    Co masz na myśli, pisząc 'itd'? Nie znam specyfikacji tegoż systemu.
    Uczepiłem się tych 2500 paczek danych na 3600 sekund, co nie wydaje się
    zbytnio trudne. Jaki średni rozmiar miała paczka? Jeśli mamy ograniczoną
    pulę połączeń, to co jest złego w odrzuceniu?


    > na dalszych etapach masz podobne wybory, które wpływają na przyjęte
    > rozwiązania i musisz wybrać tak, aby żadna sekwencja możliwych zdarzeń
    > nie prowadziła do awarii...
    Zgodzę się, że zgranie każdego, w pobieżnej ocenie 'łatwego', systemu w
    jedną niezawodną całość, może okazać się bardzo trudne. Ale żeby padło na
    etapie zbierania danych i straciło spójność, jakoś wydaje mi się dziwne.

    Ja miałem tego typu problemy, gdy łączyłem zbieranie danych z ich opracowaniem.
    Gdy te etapy rozdzielam, to ilość problemów na etapie pobierania danych
    spadła prawie do zera. Z dalszym opracowaniem danych też mam nie mało
    problemów, ale cóż, każdemu zdarzają się błędy w kodzie.

    Pozdrawiam




strony : 1 ... 5 . [ 6 ] . 7 ... 20 ... 29


Szukaj w grupach

Szukaj w grupach

Eksperci egospodarka.pl

1 1 1

Wpisz nazwę miasta, dla którego chcesz znaleźć jednostkę ZUS.

Wzory dokumentów

Bezpłatne wzory dokumentów i formularzy.
Wyszukaj i pobierz za darmo: