Temat: Szukam rozwiązania!

Wojciech Gardziński:

Dariusz Kolasa:
A poza tym nie czytałeś uważnie mojego posta. U mnie jedynym bezpośrednim użytkownikiem bazy jest admin aplikacji :)

Ja doczytałem, ja doczytałem. Chcę plusa ;)

Praktycy, łączcie się!

kółkom wzajemnej adoracji mówimy NIE!

Temat: Szukam rozwiązania!

Dariusz Kolasa:
Przemku, jeżeli byłby to system typowo produkcyjny to zgoda - zbieranie danych inaczej niż on line jest bez sensu. Ale tu przy budżetowaniu każdy user odpowiada za ściśle określony zestaw swoich rekordów.

a osoba na końcu odpowiada za całość. w tym momencie nie ma gwarancji że zrobi scalenie na czas z przyczyn od niego niezależnych np. wadliwe pliki bo ktoś miał fantazję i wklejał dane jak chciał

Ja dlatego uzyskuję integralność danych już na kliencie. Nie będę Was tu wprowadzał w tajniki tej technologii (chociaż to nic nadzwyczajnego) bo muszę z czegoś żyć :) ale wierzcie mi, jest najlepsza do budżetowania jak i do kontroli wykonania budżetu.

Najlepsze z Twojego punktu widzenia, bo ponosisz najmniejsze koszty na wdrożenie takiego rozwiązania. Z punktu widzenia klienta jest szereg rozwiązań z czego znaczna większość jest lepsza

Sprawdzałem i bazę on line zarówno serwerową jak i accessową i wykopsane procedury walidacji po wypełnieniu Excela i IS, AS i RS SQL Servera. Wszystko to w porównaniu jest mniej elastyczne, droższe na każdym etapie, bardziej obciążające sieć, bardziej awaryjne, bardziej czasochłonne w produkcji i modyfikacji i mniej przyjazne dla użytkownika (bo nowe, a tu zawsze jest silny opór).

weź mi wytłumacz jak rozumiesz stwierdzenie że udział sieciowy mniej obciąża sieć niż zapytanie SQL lecące do serwera za pomocą protokołu TCP/IP - to nonsens do kwadratu

kwestia ceny też jest z czapki bo MSSQL 2005/ 2008 / 2008 R2 Express jest darmowy dla biznesu i ma o wiele większe możliwości np. posiada triggery czego nie ma w Access-e

z punktu widzenia user-a klientem nadal może być Excel, tylko inaczej oprogramowany! więc ten argument jest z księżyca

z punktu widzenia administratora klientem nadal może być Access - więc co ma się mu zmienić?

Awaryjność - weż doprecyzuj bo mi to SF zalatuje

Ma za to niestety kilka potężnych wad - jest nudne, bo znowu w Excelu, jest za tanie - wiecie o co chodzi, i nikt na początku nie chce wierzyć, że w ogóle możliwe :)

maluchem można jechać na Syberie - ale nie wiem czy warto

Temat: Szukam rozwiązania!

Widzę, że wybuchła dyskusja: robić ręcznie vs robić automatycznie, z nieśmiertelnymi argumentami: "bo ludzie się przyzwyczaili", "ja to robię od lat".

Temat: Szukam rozwiązania!

Przemysław R.:

Dariusz Kolasa:
Przemku, jeżeli byłby to system typowo produkcyjny to zgoda - zbieranie danych inaczej niż on line jest bez sensu. Ale tu przy budżetowaniu każdy user odpowiada za ściśle określony zestaw swoich rekordów.

a osoba na końcu odpowiada za całość. w tym momencie nie ma gwarancji że zrobi scalenie na czas z przyczyn od niego niezależnych np. wadliwe pliki bo ktoś miał fantazję i wklejał dane jak chciał

u mnie nie da się nic wkleić :) a przeszkolenie nowego admina zajmuje 15 min

Ja dlatego uzyskuję integralność danych już na kliencie. Nie będę Was tu wprowadzał w tajniki tej technologii (chociaż to nic nadzwyczajnego) bo muszę z czegoś żyć :) ale wierzcie mi, jest najlepsza do budżetowania jak i do kontroli wykonania budżetu.

Najlepsze z Twojego punktu widzenia, bo ponosisz najmniejsze koszty na wdrożenie takiego rozwiązania. Z punktu widzenia klienta jest szereg rozwiązań z czego znaczna większość jest lepsza

jakiś przykład?

Sprawdzałem i bazę on line zarówno serwerową jak i accessową i wykopsane procedury walidacji po wypełnieniu Excela i IS, AS i RS SQL Servera. Wszystko to w porównaniu jest mniej elastyczne, droższe na każdym etapie, bardziej obciążające sieć, bardziej awaryjne, bardziej czasochłonne w produkcji i modyfikacji i mniej przyjazne dla użytkownika (bo nowe, a tu zawsze jest silny opór).

weź mi wytłumacz jak rozumiesz stwierdzenie że udział sieciowy mniej obciąża sieć niż zapytanie SQL lecące do serwera za pomocą protokołu TCP/IP - to nonsens do kwadratu

bo jest wykonywane 1 raz na dobę?

kwestia ceny też jest z czapki bo MSSQL 2005/ 2008 / 2008 R2 Express jest darmowy dla biznesu i ma o wiele większe możliwości np. posiada triggery czego nie ma w Access-e

triggery są tu zupełnie do niczego niepotrzebne. Za to jakakolwiek zmiana czy awaria wymaga zatrudnienia kogoś kto ma pojęcie o serwerze, sieci, zabezpieczeniach. To są duże koszty

z punktu widzenia user-a klientem nadal może być Excel, tylko inaczej oprogramowany! więc ten argument jest z księżyca

już się pogubiłem, to w końcu jak to ma działać wg Ciebie?

z punktu widzenia administratora klientem nadal może być Access - więc co ma się mu zmienić?

mój admin używa wyłącznie Excela

Awaryjność - weż doprecyzuj bo mi to SF zalatuje

Twój system wymaga (oprócz VBA)
- bezawaryjnej sieci
- instalacji dodatkowego oprogramowania
- wykwalifikowanego programisty T-SQL
- wykwalifikowanego personelu IT do utrzymania systemu w zakresie bezpieczeństwa i administrowania SQL Serverem

Mój system wymaga (oprócz VBA)
- zasobów sieciowych dostępnych kilka minut dziennie

Ma za to niestety kilka potężnych wad - jest nudne, bo znowu w Excelu, jest za tanie - wiecie o co chodzi, i nikt na początku nie chce wierzyć, że w ogóle możliwe :)

maluchem można jechać na Syberie - ale nie wiem czy warto

ja bym maluchem bał się wyjechać nawet na najbliższy asfalt...

Temat: Szukam rozwiązania!

Dariusz Kolasa:

Przemysław R.:

Dariusz Kolasa:
Przemku, jeżeli byłby to system typowo produkcyjny to zgoda - zbieranie danych inaczej niż on line jest bez sensu. Ale tu przy budżetowaniu każdy user odpowiada za ściśle określony zestaw swoich rekordów.

a osoba na końcu odpowiada za całość. w tym momencie nie ma gwarancji że zrobi scalenie na czas z przyczyn od niego niezależnych np. wadliwe pliki bo ktoś miał fantazję i wklejał dane jak chciał

u mnie nie da się nic wkleić :) a przeszkolenie nowego admina zajmuje 15 min

to nie jest żadne zabezpieczenie, a co się stanie jak sobie zrobi kopjuj - wklej do nowego pliki i wklei z radosną twórczością zamiast pliku orginalnego?

Ja dlatego uzyskuję integralność danych już na kliencie. Nie będę Was tu wprowadzał w tajniki tej technologii (chociaż to nic nadzwyczajnego) bo muszę z czegoś żyć :) ale wierzcie mi, jest najlepsza do budżetowania jak i do kontroli wykonania budżetu.

Najlepsze z Twojego punktu widzenia, bo ponosisz najmniejsze koszty na wdrożenie takiego rozwiązania. Z punktu widzenia klienta jest szereg rozwiązań z czego znaczna większość jest lepsza

jakiś przykład?

aplikacja webowa - pełna kontrola z punktu widzenia administratora i zarządzającego, mała wygoda z punktu widzenia usera, ale to zalezy jak sie programista webowy postara

aplikacja desktopowa w architekturze klient serwer - user ma swobodę działania, admin może sobie zarządzać, większa wygoda userów, mniejsza kontrola admina

aplikacja taką jak Ty napisałeś - klient otrzymuje szereg plików excel-a które musi sobie przerzeźbić jakimś makrem. O ile pliki nie stracą spójności poprzez działanie user-a to ma szansę na scalenie, a jak się pliki popsują to już dramat

w obu wcześniejszych przypadkach user nie ma ma wpływu na to co wysyła i nie nie może tego popsuć , w przypadku ostatnim ma do tego pełne możliwości, więc tracisz coś takiego jak spójność informacji

Sprawdzałem i bazę on line zarówno serwerową jak i accessową i wykopsane procedury walidacji po wypełnieniu Excela i IS, AS i RS SQL Servera. Wszystko to w porównaniu jest mniej elastyczne, droższe na każdym etapie, bardziej obciążające sieć, bardziej awaryjne, bardziej czasochłonne w produkcji i modyfikacji i mniej przyjazne dla użytkownika (bo nowe, a tu zawsze jest silny opór).

weź mi wytłumacz jak rozumiesz stwierdzenie że udział sieciowy mniej obciąża sieć niż zapytanie SQL lecące do serwera za pomocą protokołu TCP/IP - to nonsens do kwadratu

bo jest wykonywane 1 raz na dobę?

hmm a cy połączenie do bazy musi wisieć cały czas? przecież możesz tym dowolnie sterować z pozycji user-a

a co się dzieje jak user modyfikuje pliki w trakcie skanowania? będzie rozjazd

zauważ że to user powinien decydować o tym czy dana informacja jest gotowa czy też nie, w przypadku gdy robimy to z pozycji admina to jest proszenie się o kłopoty w spójności informacji a to już grubszy kaliber problemu

kwestia ceny też jest z czapki bo MSSQL 2005/ 2008 / 2008 R2 Express jest darmowy dla biznesu i ma o wiele większe możliwości np. posiada triggery czego nie ma w Access-e

triggery są tu zupełnie do niczego niepotrzebne. Za to jakakolwiek zmiana czy awaria wymaga zatrudnienia kogoś kto ma pojęcie o serwerze, sieci, zabezpieczeniach. To są duże koszty

z punktu widzenia user-a klientem nadal może być Excel, tylko inaczej oprogramowany! więc ten argument jest z księżyca

już się pogubiłem, to w końcu jak to ma działać wg Ciebie?

Excel jest klientem bazy danych, to czy działamy 100% czasu online czy łączymy się na żądanie to kwestia drugorzędna.

wykonujemy dokładnie taką samą czynność jak robi to twój Excel tyle że zamiast zapisu na dysk robimy to wprost do bazy, subtelna lecz różnica

z punktu widzenia administratora klientem nadal może być Access - więc co ma się mu zmienić?

mój admin używa wyłącznie Excela

może go używać nadal, co za różnica co mu przerabia dane

Awaryjność - weż doprecyzuj bo mi to SF zalatuje

Twój system wymaga (oprócz VBA)
- bezawaryjnej sieci

twój też

- instalacji dodatkowego oprogramowania

to chyba nie jest problem jak jest darmowe, a używanie nieodpowiedniego oprogramowania do danego zadania jest zdecydowanie błędem projektowym

argument z czapki i to głębokiej

- wykwalifikowanego programisty T-SQL

po co? menagment studio działa dokładnie tak jak Access - są kreatory i wsystko można zrobić myszką

Twoje rozwiązanie wymaga zaawansowanego programisty VBA co na to samo wychodzi

argument z czapki i to głębokiej

- wykwalifikowanego personelu IT do utrzymania systemu w zakresie bezpieczeństwa i administrowania SQL Serverem

po co? wystarczy jeden program - backupy robią się same

a jak mamy bełnąwersję MSSQL-a np. przy okazji innego projektu to ustawia się autopilota na maintance planie i się kręci - backupy,

Twoje rozwiązanie wymaga backupowania wszystkich plików, a w szczególnych przypadkach wersjonowania plików

argument z czapki i to głębokiej

Mój system wymaga (oprócz VBA)
- zasobów sieciowych dostępnych kilka minut dziennie

mój tak samo jak nie aktualizujesz danych w trybie online

co gorsza udziały sieciowe mają makabryczną wadę jak pracujesz na GPRS/EDGE/3G - zrzerają transmisję

wysłanie kilku inserów to jak splunąć przy tym

Ma za to niestety kilka potężnych wad - jest nudne, bo znowu w Excelu, jest za tanie - wiecie o co chodzi, i nikt na początku nie chce wierzyć, że w ogóle możliwe :)

maluchem można jechać na Syberie - ale nie wiem czy warto

ja bym maluchem bał się wyjechać nawet na najbliższy asfalt...

ps.

przerabiałem oba scenariusze i doskonale znam zalety i wady obydwu rozwiązań
a Ty?

Temat: Szukam rozwiązania!

Przemysław R.:

Dariusz Kolasa:

Przemysław R.:

Dariusz Kolasa:
Przemku, jeżeli byłby to system typowo produkcyjny to zgoda - zbieranie danych inaczej niż on line jest bez sensu. Ale tu przy budżetowaniu każdy user odpowiada za ściśle określony zestaw swoich rekordów.

a osoba na końcu odpowiada za całość. w tym momencie nie ma gwarancji że zrobi scalenie na czas z przyczyn od niego niezależnych np. wadliwe pliki bo ktoś miał fantazję i wklejał dane jak chciał

u mnie nie da się nic wkleić :) a przeszkolenie nowego admina zajmuje 15 min

to nie jest żadne zabezpieczenie, a co się stanie jak sobie zrobi kopjuj - wklej do nowego pliki i wklei z radosną twórczością zamiast pliku orginalnego?

u mnie się nie da zrobić kopiuj...
oryginał jest nie do podrobienia dla normalnego użytkownika

Ja dlatego uzyskuję integralność danych już na kliencie. Nie będę Was tu wprowadzał w tajniki tej technologii (chociaż to nic nadzwyczajnego) bo muszę z czegoś żyć :) ale wierzcie mi, jest najlepsza do budżetowania jak i do kontroli wykonania budżetu.

Najlepsze z Twojego punktu widzenia, bo ponosisz najmniejsze koszty na wdrożenie takiego rozwiązania. Z punktu widzenia klienta jest szereg rozwiązań z czego znaczna większość jest lepsza

jakiś przykład?

aplikacja webowa - pełna kontrola z punktu widzenia administratora i zarządzającego, mała wygoda z punktu widzenia usera, ale to zalezy jak sie programista webowy postara

to jest przeważnie dramat jeżeli chodzi o czas wykonania i modyfikacje

aplikacja desktopowa w architekturze klient serwer - user ma swobodę działania, admin może sobie zarządzać, większa wygoda userów, mniejsza kontrola admina

po co ten serwer?

aplikacja taką jak Ty napisałeś - klient otrzymuje szereg plików excel-a

dokładnie dwa, jeden z danymi drugi z aplikacją

które musi sobie przerzeźbić jakimś makrem. O

ile pliki nie stracą spójności poprzez działanie user-a to ma szansę na scalenie, a jak się pliki popsują to już dramat

nie ma takiej możliwości

w obu wcześniejszych przypadkach user nie ma ma wpływu na to co wysyła i nie nie może tego popsuć , w przypadku ostatnim ma do tego pełne możliwości, więc tracisz coś takiego jak spójność informacji

nie ma takiej możliwości, jeżeli twierdzisz, że nie można w pełni kontrolować użytkownika w Excelu to nie znasz Excela albo udajesz, że nie znasz

Sprawdzałem i bazę on line zarówno serwerową jak i accessową i wykopsane procedury walidacji po wypełnieniu Excela i IS, AS i RS SQL Servera. Wszystko to w porównaniu jest mniej elastyczne, droższe na każdym etapie, bardziej obciążające sieć, bardziej awaryjne, bardziej czasochłonne w produkcji i modyfikacji i mniej przyjazne dla użytkownika (bo nowe, a tu zawsze jest silny opór).

weź mi wytłumacz jak rozumiesz stwierdzenie że udział sieciowy mniej obciąża sieć niż zapytanie SQL lecące do serwera za pomocą protokołu TCP/IP - to nonsens do kwadratu

bo jest wykonywane 1 raz na dobę?

hmm a cy połączenie do bazy musi wisieć cały czas? przecież możesz tym dowolnie sterować z pozycji user-a

tylko po co mu w ogóle to połączenie?

a co się dzieje jak user modyfikuje pliki w trakcie skanowania? będzie rozjazd

jest coś takiego jak obsługa błędów, wydawało mi się, że wiesz

zauważ że to user powinien decydować o tym czy dana informacja jest gotowa czy też nie, w przypadku gdy robimy to z pozycji admina to jest proszenie się o kłopoty w spójności informacji a to już grubszy kaliber problemu

termin zakończenia prac nad budżetem jest ściśle określony i wiadomo kiedy można konsolidować

kwestia ceny też jest z czapki bo MSSQL 2005/ 2008 / 2008 R2 Express jest darmowy dla biznesu i ma o wiele większe możliwości np. posiada triggery czego nie ma w Access-e

triggery są tu zupełnie do niczego niepotrzebne. Za to jakakolwiek zmiana czy awaria wymaga zatrudnienia kogoś kto ma pojęcie o serwerze, sieci, zabezpieczeniach. To są duże koszty

z punktu widzenia user-a klientem nadal może być Excel, tylko inaczej oprogramowany! więc ten argument jest z księżyca

już się pogubiłem, to w końcu jak to ma działać wg Ciebie?

Excel jest klientem bazy danych, to czy działamy 100% czasu online czy łączymy się na żądanie to kwestia drugorzędna.

no właśnie, a ja twierdzę, że wcale nie trzeba

wykonujemy dokładnie taką samą czynność jak robi to twój Excel tyle że zamiast zapisu na dysk robimy to wprost do bazy, subtelna lecz różnica

tworząca bezsensowny ruch w sieci i zużycie zasobów, które bardziej są potrzebne dla aplikacji produkcyjnych

z punktu widzenia administratora klientem nadal może być Access - więc co ma się mu zmienić?

mój admin używa wyłącznie Excela

może go używać nadal, co za różnica co mu przerabia dane

no właśnie, więc czemu się czepiasz?

Awaryjność - weż doprecyzuj bo mi to SF zalatuje

Twój system wymaga (oprócz VBA)
- bezawaryjnej sieci

twój też

- instalacji dodatkowego oprogramowania

to chyba nie jest problem jak jest darmowe, a używanie nieodpowiedniego oprogramowania do danego zadania jest zdecydowanie błędem projektowym

to zawsze jest problem, chyba nie próbowałeś czegoś zainstalować w jakiejkolwiek korporacji

argument z czapki i to głębokiej

- wykwalifikowanego programisty T-SQL

po co? menagment studio działa dokładnie tak jak Access - są kreatory i wsystko można zrobić myszką

to ciekawe po co firmy zatrudniają adminów SQL Servera?

Twoje rozwiązanie wymaga zaawansowanego programisty VBA co na to samo wychodzi

nie na to samo, u Ciebie jest dodatkowo potrzebny programista i admin SQL Servera, nie wiem ile razy jeszcze mam to napisać

argument z czapki i to głębokiej

- wykwalifikowanego personelu IT do utrzymania systemu w zakresie bezpieczeństwa i administrowania SQL Serverem

po co? wystarczy jeden program - backupy robią się same

pozwól, że powtórzę:
to ciekawe po co firmy zatrudniają adminów SQL Servera?

a jak mamy bełnąwersję MSSQL-a np. przy okazji innego projektu to ustawia się autopilota na maintance planie i się kręci - backupy,

Twoje rozwiązanie wymaga backupowania wszystkich plików, a w szczególnych przypadkach wersjonowania plików

zasoby sieciowe użytkowników w korporacjach są backupowane standardowo

argument z czapki i to głębokiej

Mój system wymaga (oprócz VBA)
- zasobów sieciowych dostępnych kilka minut dziennie

mój tak samo jak nie aktualizujesz danych w trybie online

hm, to może jednak ten serwer nie jest potrzebny?

co gorsza udziały sieciowe mają makabryczną wadę jak pracujesz na GPRS/EDGE/3G - zrzerają transmisję

o czym Ty opowiadasz?! To są desktopy kierowników

wysłanie kilku inserów to jak splunąć przy tym

Ma za to niestety kilka potężnych wad - jest nudne, bo znowu w Excelu, jest za tanie - wiecie o co chodzi, i nikt na początku nie chce wierzyć, że w ogóle możliwe :)

maluchem można jechać na Syberie - ale nie wiem czy warto

ja bym maluchem bał się wyjechać nawet na najbliższy asfalt...

ps.

przerabiałem oba scenariusze i doskonale znam zalety i wady obydwu rozwiązań
a Ty?

Jak chcesz to Ci wyślę CV z listą aplikacji i klientów. Jak to czytam to sam się dziwię, dlaczego mam taki skromny domek i nędznego Jaguara X-Type, zamiast kilku posiadłości w Europie i nowego Q7 z systemem audio Bang & Olufsen na pokładzie. Chyba trochę mnie poniosło. Pa

Temat: Szukam rozwiązania!

Dariusz Kolasa:

Przemysław R.:

Dariusz Kolasa:

Przemysław R.:

Dariusz Kolasa:
Przemku, jeżeli byłby to system typowo produkcyjny to zgoda - zbieranie danych inaczej niż on line jest bez sensu. Ale tu przy budżetowaniu każdy user odpowiada za ściśle określony zestaw swoich rekordów.

a osoba na końcu odpowiada za całość. w tym momencie nie ma gwarancji że zrobi scalenie na czas z przyczyn od niego niezależnych np. wadliwe pliki bo ktoś miał fantazję i wklejał dane jak chciał

u mnie nie da się nic wkleić :) a przeszkolenie nowego admina zajmuje 15 min

to nie jest żadne zabezpieczenie, a co się stanie jak sobie zrobi kopjuj - wklej do nowego pliki i wklei z radosną twórczością zamiast pliku orginalnego?

u mnie się nie da zrobić kopiuj...
oryginał jest nie do podrobienia dla normalnego użytkownika

a jak się trafi nienormalny

Ja dlatego uzyskuję integralność danych już na kliencie. Nie będę Was tu wprowadzał w tajniki tej technologii (chociaż to nic nadzwyczajnego) bo muszę z czegoś żyć :) ale wierzcie mi, jest najlepsza do budżetowania jak i do kontroli wykonania budżetu.

Najlepsze z Twojego punktu widzenia, bo ponosisz najmniejsze koszty na wdrożenie takiego rozwiązania. Z punktu widzenia klienta jest szereg rozwiązań z czego znaczna większość jest lepsza

jakiś przykład?

aplikacja webowa - pełna kontrola z punktu widzenia administratora i zarządzającego, mała wygoda z punktu widzenia usera, ale to zalezy jak sie programista webowy postara

to jest przeważnie dramat jeżeli chodzi o czas wykonania i modyfikacje

bzdura
jak aplikacja jest dobrze zrobiona to się operuje konfiguracjami i gotowymi modułami. W przypadku szczególnym coś się pisze z palucha

aplikacja desktopowa w architekturze klient serwer - user ma swobodę działania, admin może sobie zarządzać, większa wygoda userów, mniejsza kontrola admina

po co ten serwer?

żeby zachować spójność informacji, pliki luzem tego nie gwarantują, zwłaszcza jak dajemy prawo do odczytu/zapisu masie osób

aplikacja taką jak Ty napisałeś - klient otrzymuje szereg plików excel-a

dokładnie dwa, jeden z danymi drugi z aplikacją

które musi sobie przerzeźbić jakimś makrem. O

ile pliki nie stracą spójności poprzez działanie user-a to ma szansę na scalenie, a jak się pliki popsują to już dramat

nie ma takiej możliwości

a niby dlaczego? doskonale wiem że to jest wykonalne więc nie ściemniaj że nie ma takiej możliwości

w obu wcześniejszych przypadkach user nie ma ma wpływu na to co wysyła i nie nie może tego popsuć , w przypadku ostatnim ma do tego pełne możliwości, więc tracisz coś takiego jak spójność informacji

nie ma takiej możliwości, jeżeli twierdzisz, że nie można w pełni kontrolować użytkownika w Excelu to nie znasz Excela albo udajesz, że nie znasz

hmm pomysłowość ludzka nie zna granic a programy do łamania hasłe są ogólnie dostępne, hasło idzie ~2s to tak na marginesie

a wracając do tematu niby zabezpieczysz plik na określone akcje, wyślesz do usera a wraca plik poorany więc z doświadczenia wiem że takie zabezpieczenia są kijowe

Sprawdzałem i bazę on line zarówno serwerową jak i accessową i wykopsane procedury walidacji po wypełnieniu Excela i IS, AS i RS SQL Servera. Wszystko to w porównaniu jest mniej elastyczne, droższe na każdym etapie, bardziej obciążające sieć, bardziej awaryjne, bardziej czasochłonne w produkcji i modyfikacji i mniej przyjazne dla użytkownika (bo nowe, a tu zawsze jest silny opór).

weź mi wytłumacz jak rozumiesz stwierdzenie że udział sieciowy mniej obciąża sieć niż zapytanie SQL lecące do serwera za pomocą protokołu TCP/IP - to nonsens do kwadratu

bo jest wykonywane 1 raz na dobę?

hmm a cy połączenie do bazy musi wisieć cały czas? przecież możesz tym dowolnie sterować z pozycji user-a

tylko po co mu w ogóle to połączenie?

wrzuć dane, zamiast czekaj aż ktoś pobierze

a co się dzieje jak user modyfikuje pliki w trakcie skanowania? będzie rozjazd

jest coś takiego jak obsługa błędów, wydawało mi się, że wiesz

i czekamy aż skończy ze skanowaniem? czy pomijamy? co na to spójność informacji końcowej jak pominiesz dane

wynik końcowy to jedno wynik w pliku to zupełnie co innego - lipa trochę

zauważ że to user powinien decydować o tym czy dana informacja jest gotowa czy też nie, w przypadku gdy robimy to z pozycji admina to jest proszenie się o kłopoty w spójności informacji a to już grubszy kaliber problemu

termin zakończenia prac nad budżetem jest ściśle określony i wiadomo kiedy można konsolidować

poprawki, literówki etc - bzdury ale się trafiają - co w takim wypadku?

kwestia ceny też jest z czapki bo MSSQL 2005/ 2008 / 2008 R2 Express jest darmowy dla biznesu i ma o wiele większe możliwości np. posiada triggery czego nie ma w Access-e

triggery są tu zupełnie do niczego niepotrzebne. Za to jakakolwiek zmiana czy awaria wymaga zatrudnienia kogoś kto ma pojęcie o serwerze, sieci, zabezpieczeniach. To są duże koszty

z punktu widzenia user-a klientem nadal może być Excel, tylko inaczej oprogramowany! więc ten argument jest z księżyca

już się pogubiłem, to w końcu jak to ma działać wg Ciebie?

Excel jest klientem bazy danych, to czy działamy 100% czasu online czy łączymy się na żądanie to kwestia drugorzędna.

no właśnie, a ja twierdzę, że wcale nie trzeba

jasne
kosztem pójścia na taką łatwiznę bo nazwijmy rzecz po imieniu, jest prawdopodobieństwo utraty spójności danych, przy odrobinie finezji i tych samych formularzach czegoś takiego by nie było

Zresztą pokaż mi jakikolwiek system poza robionymi w garażu który wykorzystywał by tego typu projekt

wykonujemy dokładnie taką samą czynność jak robi to twój Excel tyle że zamiast zapisu na dysk robimy to wprost do bazy, subtelna lecz różnica

tworząca bezsensowny ruch w sieci i zużycie zasobów, które bardziej są potrzebne dla aplikacji produkcyjnych

tutaj bredzisz
wysłanie powiedzmy 2Kb w ruchu sieciowym na inserty jest porównywalne do 20Mb albo i więcej w porównaniu do transmisji protokołem SMB -> udział sieciowy w dokładnie tym samym okienku czasowym, bo jak pisałem wcześniej nie ma potrzeby łączenia się z aplikacją cały czas

z punktu widzenia administratora klientem nadal może być Access - więc co ma się mu zmienić?

mój admin używa wyłącznie Excela

może go używać nadal, co za różnica co mu przerabia dane

no właśnie, więc czemu się czepiasz?

bo to co jest w środku jest potworkiem, klasycznym druciarstwem, które ciężko będzie rozbudować

klient jest ręką w nocniku i nawet tego pewnie nie wie

Awaryjność - weż doprecyzuj bo mi to SF zalatuje

Twój system wymaga (oprócz VBA)
- bezawaryjnej sieci

twój też

- instalacji dodatkowego oprogramowania

to chyba nie jest problem jak jest darmowe, a używanie nieodpowiedniego oprogramowania do danego zadania jest zdecydowanie błędem projektowym

to zawsze jest problem, chyba nie próbowałeś czegoś zainstalować w jakiejkolwiek korporacji

działy ICT realizują takie fanaberie po wypełnieniu wniosku
albo załatwiasz sobie uprawnienia lokalnego administratora na stacji roboczej i robisz co chcesz
albo zgłaszasz wniosek o przyznanie miejsca na istniejącym serwerze SQL, dostajesz login i hasło, reszta absolutnie cie nie interesuje

jak widzisz doskonale znam korpo i ich specyfikę, kilka zaliczyłem

argument z czapki i to głębokiej

- wykwalifikowanego programisty T-SQL

po co? menagment studio działa dokładnie tak jak Access - są kreatory i wsystko można zrobić myszką

to ciekawe po co firmy zatrudniają adminów SQL Servera?

do zarządzania hurtowniami danych - inny kaliber problemów, do dłubania w takim zakresie wystarczy muszka

Twoje rozwiązanie wymaga zaawansowanego programisty VBA co na to samo wychodzi

nie na to samo, u Ciebie jest dodatkowo potrzebny programista i admin SQL Servera, nie wiem ile razy jeszcze mam to napisać

bajki opowiadasz
do czego jest potrzeby admin w takim rozwiązaniu - do absolutnie niczego, wystarczy zrobić raz mechanizm konserwacji, niech przykłądem takiej sytuacji będzie Płatnik, tam jest silnik MSSQL i jakoś nie trzeba tego magicznego admina zatrudniać

a co do programisty to czemu nie piszesz że potrzebujesz oddzielnego programisty JET SQL-a do pracy z plikiem Access - podpowiem że poziom komplikacji SQL-i w obu przypadkach jest praktycznie ten sam

argument z czapki i to głębokiej

- wykwalifikowanego personelu IT do utrzymania systemu w zakresie bezpieczeństwa i administrowania SQL Serverem

po co? wystarczy jeden program - backupy robią się same

pozwól, że powtórzę:
to ciekawe po co firmy zatrudniają adminów SQL Servera?

do zarządzania hurtowniami danych a nie bzdurami które mają maks 200Mb i robią się w pamięci

do tej konkrenire bazy danych jaką jest MSSQL w wersji express admin jest zbędny, wystarczy kilka komend w SQL-u które swobodnie można zaszyć w samej aplikacji

a jak mamy bełnąwersję MSSQL-a np. przy okazji innego projektu to ustawia się autopilota na maintance planie i się kręci - backupy,

Twoje rozwiązanie wymaga backupowania wszystkich plików, a w szczególnych przypadkach wersjonowania plików

zasoby sieciowe użytkowników w korporacjach są backupowane standardowo

bazy danych jeżeli mówi o korpo jak dostajesz taką są zarządzane przez automaty napisane przez wcześniej wspomnianych adninów baz danych, więc nie ma zasadniczej różnicy czy to udział sieciowy czy baza danych bo i jedno i drugie jest trzymane w serwerowi

to tak na marginesie bo taki scenariusz też już przerabiałem

argument z czapki i to głębokiej

Mój system wymaga (oprócz VBA)
- zasobów sieciowych dostępnych kilka minut dziennie

mój tak samo jak nie aktualizujesz danych w trybie online

hm, to może jednak ten serwer nie jest potrzebny?

jest
zauważ że większość aplikacji w korpo jest pisana w architekturze klient-serwer

a takie prowizorki jak proponujesz są ubijane cyklicznie jako potencjalnie niebezpieczne dla firmy

to też przerabiałem

co gorsza udziały sieciowe mają makabryczną wadę jak pracujesz na GPRS/EDGE/3G - zrzerają transmisję

o czym Ty opowiadasz?! To są desktopy kierowników

to po co piszesz o jakiś zasobach? skoro są nieograniczone - tak dla fanu?

wysłanie kilku inserów to jak splunąć przy tym

Ma za to niestety kilka potężnych wad - jest nudne, bo znowu w Excelu, jest za tanie - wiecie o co chodzi, i nikt na początku nie chce wierzyć, że w ogóle możliwe :)

maluchem można jechać na Syberie - ale nie wiem czy warto

ja bym maluchem bał się wyjechać nawet na najbliższy asfalt...

ps.

przerabiałem oba scenariusze i doskonale znam zalety i wady obydwu rozwiązań
a Ty?

Jak chcesz to Ci wyślę CV z listą aplikacji i klientów. Jak to czytam to sam się dziwię, dlaczego mam taki skromny domek i nędznego Jaguara X-Type, zamiast kilku posiadłości w Europie i nowego Q7 z systemem audio Bang & Olufsen na pokładzie. Chyba trochę mnie poniosło. Pa

widzę jednak że nie bardzo
spoko

Temat: Szukam rozwiązania!

Dariusz Kolasa:

Przemysław R.:

Dariusz Kolasa:

Przemysław R.:

Dariusz Kolasa:
Przemku, jeżeli byłby to system typowo produkcyjny to zgoda - zbieranie danych inaczej niż on line jest bez sensu. Ale tu przy budżetowaniu każdy user odpowiada za ściśle określony zestaw swoich rekordów.

a osoba na końcu odpowiada za całość. w tym momencie nie ma gwarancji że zrobi scalenie na czas z przyczyn od niego niezależnych np. wadliwe pliki bo ktoś miał fantazję i wklejał dane jak chciał

u mnie nie da się nic wkleić :) a przeszkolenie nowego admina zajmuje 15 min

to nie jest żadne zabezpieczenie, a co się stanie jak sobie zrobi kopjuj - wklej do nowego pliki i wklei z radosną twórczością zamiast pliku orginalnego?

u mnie się nie da zrobić kopiuj...
oryginał jest nie do podrobienia dla normalnego użytkownika

a jak się trafi nienormalny

Ja dlatego uzyskuję integralność danych już na kliencie. Nie będę Was tu wprowadzał w tajniki tej technologii (chociaż to nic nadzwyczajnego) bo muszę z czegoś żyć :) ale wierzcie mi, jest najlepsza do budżetowania jak i do kontroli wykonania budżetu.

Najlepsze z Twojego punktu widzenia, bo ponosisz najmniejsze koszty na wdrożenie takiego rozwiązania. Z punktu widzenia klienta jest szereg rozwiązań z czego znaczna większość jest lepsza

jakiś przykład?

aplikacja webowa - pełna kontrola z punktu widzenia administratora i zarządzającego, mała wygoda z punktu widzenia usera, ale to zalezy jak sie programista webowy postara

to jest przeważnie dramat jeżeli chodzi o czas wykonania i modyfikacje

bzdura
jak aplikacja jest dobrze zrobiona to się operuje konfiguracjami i gotowymi modułami. W przypadku szczególnym coś się pisze z palucha

aplikacja desktopowa w architekturze klient serwer - user ma swobodę działania, admin może sobie zarządzać, większa wygoda userów, mniejsza kontrola admina

po co ten serwer?

żeby zachować spójność informacji, pliki luzem tego nie gwarantują, zwłaszcza jak dajemy prawo do odczytu/zapisu masie osób

aplikacja taką jak Ty napisałeś - klient otrzymuje szereg plików excel-a

dokładnie dwa, jeden z danymi drugi z aplikacją

które musi sobie przerzeźbić jakimś makrem. O

ile pliki nie stracą spójności poprzez działanie user-a to ma szansę na scalenie, a jak się pliki popsują to już dramat

nie ma takiej możliwości

a niby dlaczego? doskonale wiem że to jest wykonalne więc nie ściemniaj że nie ma takiej możliwości

w obu wcześniejszych przypadkach user nie ma ma wpływu na to co wysyła i nie nie może tego popsuć , w przypadku ostatnim ma do tego pełne możliwości, więc tracisz coś takiego jak spójność informacji

nie ma takiej możliwości, jeżeli twierdzisz, że nie można w pełni kontrolować użytkownika w Excelu to nie znasz Excela albo udajesz, że nie znasz

hmm pomysłowość ludzka nie zna granic a programy do łamania hasłe są ogólnie dostępne, hasło idzie ~2s to tak na marginesie

a wracając do tematu niby zabezpieczysz plik na określone akcje, wyślesz do usera a wraca plik poorany więc z doświadczenia wiem że takie zabezpieczenia są kijowe

Sprawdzałem i bazę on line zarówno serwerową jak i accessową i wykopsane procedury walidacji po wypełnieniu Excela i IS, AS i RS SQL Servera. Wszystko to w porównaniu jest mniej elastyczne, droższe na każdym etapie, bardziej obciążające sieć, bardziej awaryjne, bardziej czasochłonne w produkcji i modyfikacji i mniej przyjazne dla użytkownika (bo nowe, a tu zawsze jest silny opór).

weź mi wytłumacz jak rozumiesz stwierdzenie że udział sieciowy mniej obciąża sieć niż zapytanie SQL lecące do serwera za pomocą protokołu TCP/IP - to nonsens do kwadratu

bo jest wykonywane 1 raz na dobę?

hmm a cy połączenie do bazy musi wisieć cały czas? przecież możesz tym dowolnie sterować z pozycji user-a

tylko po co mu w ogóle to połączenie?

wrzuć dane, zamiast czekaj aż ktoś pobierze

a co się dzieje jak user modyfikuje pliki w trakcie skanowania? będzie rozjazd

jest coś takiego jak obsługa błędów, wydawało mi się, że wiesz

i czekamy aż skończy ze skanowaniem? czy pomijamy? co na to spójność informacji końcowej jak pominiesz dane

wynik końcowy to jedno wynik w pliku to zupełnie co innego - lipa trochę

zauważ że to user powinien decydować o tym czy dana informacja jest gotowa czy też nie, w przypadku gdy robimy to z pozycji admina to jest proszenie się o kłopoty w spójności informacji a to już grubszy kaliber problemu

termin zakończenia prac nad budżetem jest ściśle określony i wiadomo kiedy można konsolidować

poprawki, literówki etc - bzdury ale się trafiają - co w takim wypadku?

kwestia ceny też jest z czapki bo MSSQL 2005/ 2008 / 2008 R2 Express jest darmowy dla biznesu i ma o wiele większe możliwości np. posiada triggery czego nie ma w Access-e

triggery są tu zupełnie do niczego niepotrzebne. Za to jakakolwiek zmiana czy awaria wymaga zatrudnienia kogoś kto ma pojęcie o serwerze, sieci, zabezpieczeniach. To są duże koszty

z punktu widzenia user-a klientem nadal może być Excel, tylko inaczej oprogramowany! więc ten argument jest z księżyca

już się pogubiłem, to w końcu jak to ma działać wg Ciebie?

Excel jest klientem bazy danych, to czy działamy 100% czasu online czy łączymy się na żądanie to kwestia drugorzędna.

no właśnie, a ja twierdzę, że wcale nie trzeba

jasne
kosztem pójścia na taką łatwiznę bo nazwijmy rzecz po imieniu, jest prawdopodobieństwo utraty spójności danych, przy odrobinie finezji i tych samych formularzach czegoś takiego by nie było

Zresztą pokaż mi jakikolwiek system poza robionymi w garażu który wykorzystywał by tego typu projekt

wykonujemy dokładnie taką samą czynność jak robi to twój Excel tyle że zamiast zapisu na dysk robimy to wprost do bazy, subtelna lecz różnica

tworząca bezsensowny ruch w sieci i zużycie zasobów, które bardziej są potrzebne dla aplikacji produkcyjnych

tutaj bredzisz
wysłanie powiedzmy 2Kb w ruchu sieciowym na inserty jest porównywalne do 20Mb albo i więcej w porównaniu do transmisji protokołem SMB -> udział sieciowy w dokładnie tym samym okienku czasowym, bo jak pisałem wcześniej nie ma potrzeby łączenia się z aplikacją cały czas

z punktu widzenia administratora klientem nadal może być Access - więc co ma się mu zmienić?

mój admin używa wyłącznie Excela

może go używać nadal, co za różnica co mu przerabia dane

no właśnie, więc czemu się czepiasz?

bo to co jest w środku jest potworkiem, klasycznym druciarstwem, które ciężko będzie rozbudować

klient jest ręką w nocniku i nawet tego pewnie nie wie

Awaryjność - weż doprecyzuj bo mi to SF zalatuje

Twój system wymaga (oprócz VBA)
- bezawaryjnej sieci

twój też

- instalacji dodatkowego oprogramowania

to chyba nie jest problem jak jest darmowe, a używanie nieodpowiedniego oprogramowania do danego zadania jest zdecydowanie błędem projektowym

to zawsze jest problem, chyba nie próbowałeś czegoś zainstalować w jakiejkolwiek korporacji

działy ICT realizują takie fanaberie po wypełnieniu wniosku
albo załatwiasz sobie uprawnienia lokalnego administratora na stacji roboczej i robisz co chcesz
albo zgłaszasz wniosek o przyznanie miejsca na istniejącym serwerze SQL, dostajesz login i hasło, reszta absolutnie cie nie interesuje

jak widzisz doskonale znam korpo i ich specyfikę, kilka zaliczyłem

argument z czapki i to głębokiej

- wykwalifikowanego programisty T-SQL

po co? menagment studio działa dokładnie tak jak Access - są kreatory i wsystko można zrobić myszką

to ciekawe po co firmy zatrudniają adminów SQL Servera?

do zarządzania hurtowniami danych - inny kaliber problemów, do dłubania w takim zakresie wystarczy muszka

Twoje rozwiązanie wymaga zaawansowanego programisty VBA co na to samo wychodzi

nie na to samo, u Ciebie jest dodatkowo potrzebny programista i admin SQL Servera, nie wiem ile razy jeszcze mam to napisać

bajki opowiadasz
do czego jest potrzeby admin w takim rozwiązaniu - do absolutnie niczego, wystarczy zrobić raz mechanizm konserwacji, niech przykłądem takiej sytuacji będzie Płatnik, tam jest silnik MSSQL i jakoś nie trzeba tego magicznego admina zatrudniać

a co do programisty to czemu nie piszesz że potrzebujesz oddzielnego programisty JET SQL-a do pracy z plikiem Access - podpowiem że poziom komplikacji SQL-i w obu przypadkach jest praktycznie ten sam

argument z czapki i to głębokiej

- wykwalifikowanego personelu IT do utrzymania systemu w zakresie bezpieczeństwa i administrowania SQL Serverem

po co? wystarczy jeden program - backupy robią się same

pozwól, że powtórzę:
to ciekawe po co firmy zatrudniają adminów SQL Servera?

do zarządzania hurtowniami danych a nie bzdurami które mają maks 200Mb i robią się w pamięci

do tej konkrenire bazy danych jaką jest MSSQL w wersji express admin jest zbędny, wystarczy kilka komend w SQL-u które swobodnie można zaszyć w samej aplikacji

a jak mamy bełnąwersję MSSQL-a np. przy okazji innego projektu to ustawia się autopilota na maintance planie i się kręci - backupy,

Twoje rozwiązanie wymaga backupowania wszystkich plików, a w szczególnych przypadkach wersjonowania plików

zasoby sieciowe użytkowników w korporacjach są backupowane standardowo

bazy danych jeżeli mówi o korpo jak dostajesz taką są zarządzane przez automaty napisane przez wcześniej wspomnianych adninów baz danych, więc nie ma zasadniczej różnicy czy to udział sieciowy czy baza danych bo i jedno i drugie jest trzymane w serwerowi

to tak na marginesie bo taki scenariusz też już przerabiałem

argument z czapki i to głębokiej

Mój system wymaga (oprócz VBA)
- zasobów sieciowych dostępnych kilka minut dziennie

mój tak samo jak nie aktualizujesz danych w trybie online

hm, to może jednak ten serwer nie jest potrzebny?

jest
zauważ że większość aplikacji w korpo jest pisana w architekturze klient-serwer

a takie prowizorki jak proponujesz są ubijane cyklicznie jako potencjalnie niebezpieczne dla firmy

to też przerabiałem

co gorsza udziały sieciowe mają makabryczną wadę jak pracujesz na GPRS/EDGE/3G - zrzerają transmisję

o czym Ty opowiadasz?! To są desktopy kierowników

to po co piszesz o jakiś zasobach? skoro są nieograniczone - tak dla fanu?

wysłanie kilku inserów to jak splunąć przy tym

Ma za to niestety kilka potężnych wad - jest nudne, bo znowu w Excelu, jest za tanie - wiecie o co chodzi, i nikt na początku nie chce wierzyć, że w ogóle możliwe :)

maluchem można jechać na Syberie - ale nie wiem czy warto

ja bym maluchem bał się wyjechać nawet na najbliższy asfalt...

ps.

przerabiałem oba scenariusze i doskonale znam zalety i wady obydwu rozwiązań
a Ty?

Jak chcesz to Ci wyślę CV z listą aplikacji i klientów. Jak to czytam to sam się dziwię, dlaczego mam taki skromny domek i nędznego Jaguara X-Type, zamiast kilku posiadłości w Europie i nowego Q7 z systemem audio Bang & Olufsen na pokładzie. Chyba trochę mnie poniosło. Pa

widzę jednak że nie bardzo
spoko

Temat: Szukam rozwiązania!

Wyciąłem większość poprzedniej konwersacji, która i tak Cię nie przekona, bo chcesz po prostu za wszelką cenę udowodnić, że architektura klient - serwer jest jedyną słuszną a tu po prostu nie masz racji. Natomiast ciągnę tą dyskusję, bo to dobrze przygotowuje do rozmów z wrogo nastawionymi do Office'owych aplikacji działami IT

u mnie się nie da zrobić kopiuj...
oryginał jest nie do podrobienia dla normalnego użytkownika

a jak się trafi nienormalny

czyli zakładasz, że kierownik zatrudni hakera do łamania haseł w swojej własnej firmie. Do SQL Servera z wewnątrz firmy też stosunkowo łatwo się włamać

bzdura
jak aplikacja jest dobrze zrobiona to się operuje konfiguracjami i gotowymi modułami. W przypadku szczególnym coś się pisze z palucha

to są dopiero herezje. Dobrze napisana aplikacja webowa np typu CMS powstaje latami i pracuje nad nią wielu ludzi. A tu musisz napisać coś dedykowanego - nietypowego. To zajmie bardzo dużo czasu. Jeżeli umiesz w 17 dni napisać webową aplikację do budżetowania dla koncernu, to czemu Ty nie masz Q7? (tak zakładam, jak masz to mnie skoryguj)

po co ten serwer?

żeby zachować spójność informacji, pliki luzem tego nie gwarantują, zwłaszcza jak dajemy prawo do odczytu/zapisu masie osób

gwarantują, wygląda na to, że jednak nie znasz dogłębnie technologii i architektury Excel/VBA, jak zresztą większość informatyków (ale zaraz dostanę ;)

ile pliki nie stracą spójności poprzez działanie user-a to ma szansę na scalenie, a jak się pliki popsują to już dramat

nie ma takiej możliwości

a niby dlaczego? doskonale wiem że to jest wykonalne więc nie ściemniaj że nie ma takiej możliwości

powtórzę, wygląda na to, że jednak nie znasz dogłębnie technologii i architektury Excel/VBA, nie będę tu pisał jak to się robi ale każdy kto dobrze zna Excela i VBA może spokojnie całkowicie zabezpieczyć dane Excelowe przed utratą spójności. Mało tego jak ma wieloletnie doświadczenie i wyciąga wnioski, to może sobie napisać system, który będzie pilnował integralności danych nawet wtedy, gdy słowniki zmienią się strukturalnie. To się nazywa elastyczna i dobrze sparametryzowana aplikacja

hmm pomysłowość ludzka nie zna granic a programy do łamania hasłe są ogólnie dostępne, hasło idzie ~2s to tak na marginesie

a wracając do tematu niby zabezpieczysz plik na określone akcje, wyślesz do usera a wraca plik poorany więc z doświadczenia wiem że takie zabezpieczenia są kijowe

to już pisałem ale powtórzę:
czyli zakładasz, że kierownik zatrudni hakera do łamania haseł w swojej własnej firmie. Do SQL Servera z wewnątrz firmy też stosunkowo łatwo się włamać, nie mówiąc już o aplikacja webowych, których kod od wewnątrz można obejrzeć bez problemu

tylko po co mu w ogóle to połączenie?

wrzuć dane, zamiast czekaj aż ktoś pobierze

aplikacja klient - serwer jedynie słuszną architekturą wg Ciebie jest. Powód? Bo tak wszyscy robią. Brawo

a co się dzieje jak user modyfikuje pliki w trakcie skanowania? będzie rozjazd

jest coś takiego jak obsługa błędów, wydawało mi się, że wiesz

i czekamy aż skończy ze skanowaniem? czy pomijamy? co na to spójność informacji końcowej jak pominiesz dane

wynik końcowy to jedno wynik w pliku to zupełnie co innego - lipa trochę

konsolidację można wykonać o dowolnej porze, kiedy użytkownicy słodko śpią. W przypadku koncernów światowych, gdzie nie ma nocy admin mojej aplikacji musi wykonać straszliwą pracę - obejrzeć raport o nieskonsolidowanych plikach (otwartych lub w ogóle nie wypełnionych) i ponownie skonsolidować tylko te, których wcześniej się nie udało (flagi ustawiają się oczywiście automatycznie), no dramat po prostu

termin zakończenia prac nad budżetem jest ściśle określony i wiadomo kiedy można konsolidować

poprawki, literówki etc - bzdury ale się trafiają - co w takim wypadku?

a słyszałeś o słownikach? o polach kombi? listach wyboru? Literówki i inne eksperymenty to sobie możesz robić w tych Twoich niedorobionych webowych gówienkach

jasne
kosztem pójścia na taką łatwiznę bo nazwijmy rzecz po imieniu, jest prawdopodobieństwo utraty spójności danych, przy odrobinie finezji i tych samych formularzach czegoś takiego by nie było

Zresztą pokaż mi jakikolwiek system poza robionymi w garażu który wykorzystywał by tego typu projekt

a Ty znowu to samo, strasznie lubisz się powtarzać. Przy okazji wracamy do klasyki argumentacji wrogiej VBA: przecież jak to jest takie tanie i można zrobić w garażu to nie może być dobre! Brawo, doskonały argument...

wykonujemy dokładnie taką samą czynność jak robi to twój Excel tyle że zamiast zapisu na dysk robimy to wprost do bazy, subtelna lecz różnica

tworząca bezsensowny ruch w sieci i zużycie zasobów, które bardziej są potrzebne dla aplikacji produkcyjnych

tutaj bredzisz
wysłanie powiedzmy 2Kb w ruchu sieciowym na inserty jest porównywalne do 20Mb albo i więcej w porównaniu do transmisji protokołem SMB -> udział sieciowy w dokładnie tym samym okienku czasowym, bo jak pisałem wcześniej nie ma potrzeby łączenia się z aplikacją cały czas

u Ciebie: używanie serwera i sieci przez 700 użytkowników non stop
u mnie: jednorazowe krótkie użycie w porze najmniejszego obciążenia

i wg Ciebie Twoja aplikacja używa mniej zasobów. No kurde nie przekonałeś mnie

no właśnie, więc czemu się czepiasz?

bo to co jest w środku jest potworkiem, klasycznym druciarstwem, które ciężko będzie rozbudować

klient jest ręką w nocniku i nawet tego pewnie nie wie

Brawo, same konkretne argumenty!

to zawsze jest problem, chyba nie próbowałeś czegoś zainstalować w jakiejkolwiek korporacji

działy ICT realizują takie fanaberie po wypełnieniu wniosku
albo załatwiasz sobie uprawnienia lokalnego administratora na stacji roboczej i robisz co chcesz
albo zgłaszasz wniosek o przyznanie miejsca na istniejącym serwerze SQL, dostajesz login i hasło, reszta absolutnie cie nie interesuje

jak widzisz doskonale znam korpo i ich specyfikę, kilka zaliczyłem

czyli czekaj, załatwienie admina, zgody na instalacje serwera, jakieś tam drobne instalacje na każdej z 700 stacji roboczych, procedury, zatwierdzanie na wszystkich szczeblach... Ty w 17 dni to byś nawet nie dostał zgody na rozpoczęcie prac!!!

bajki opowiadasz
do czego jest potrzeby admin w takim rozwiązaniu - do absolutnie niczego, wystarczy zrobić raz mechanizm konserwacji, niech przykłądem takiej sytuacji będzie Płatnik, tam jest silnik MSSQL i jakoś nie trzeba tego magicznego admina zatrudniać

no proszę trzymajcie mnie, chyba mało list dyskusyjnych czytasz jeżeli twierdzisz, że płatnik jest bezobsługowy, to jest dopiero argument :)

a co do programisty to czemu nie piszesz że potrzebujesz oddzielnego programisty JET SQL-a do pracy z plikiem Access - podpowiem że poziom komplikacji SQL-i w obu przypadkach jest praktycznie ten sam

nieprawda, T-SQL jest trudniejszy niż zwykły SQL i o wiele mniej ludzi go zna, znowu opowiadasz bajki

zasoby sieciowe użytkowników w korporacjach są backupowane standardowo

bazy danych jeżeli mówi o korpo jak dostajesz taką są zarządzane przez automaty napisane przez wcześniej wspomnianych adninów baz danych, więc nie ma zasadniczej różnicy czy to udział sieciowy czy baza danych bo i jedno i drugie jest trzymane w serwerowi

to tak na marginesie bo taki scenariusz też już przerabiałem

no to się cieszę że chociaż w jednym punkcie przyznajesz mi rację

hm, to może jednak ten serwer nie jest potrzebny?

jest
zauważ że większość aplikacji w korpo jest pisana w architekturze klient-serwer

a takie prowizorki jak proponujesz są ubijane cyklicznie jako potencjalnie niebezpieczne dla firmy

to też przerabiałem

Znowu bardzo konkretny argument, taki merytoryczny, świetnie trzymasz się głównego nurtu, mógłbyś być rzecznikiem HP albo chociaż Asseco

co gorsza udziały sieciowe mają makabryczną wadę jak pracujesz na GPRS/EDGE/3G - zrzerają transmisję

o czym Ty opowiadasz?! To są desktopy kierowników

to po co piszesz o jakiś zasobach? skoro są nieograniczone - tak dla fanu?

sorki ale o czym Ty piszesz? Może spróbuj odpowiadać na temat

przerabiałem oba scenariusze i doskonale znam zalety i wady obydwu rozwiązań
a Ty?

Ty przerabiałeś scenariusze a ja oddałem klientom kilkadziesiąt sprawnie działających aplikacji dających im milionowe oszczędności

pozdrawiam

Temat: Szukam rozwiązania!

Przemysław R.:
(duży ciach)
aplikacja webowa - pełna kontrola z punktu widzenia administratora i zarządzającego, mała wygoda z punktu widzenia usera, ale to zalezy jak sie programista webowy postara

Formularze można zrobić na kilka sposobów: DOC, XLS, PDF, WWW.
Wiadomo, że najbardziej spójne będzie rozwiązanie WWW.
Ale nie każdy czas i ochotę siedzieć w internecie, zdarzają się przecież aplikacje typu Pit czy Janosik. Rozwiązanie przy użyciu Excel też jest akceptowalne. Kwestia tylko tego co komu bardziej pasuje.

Jeśli formularz Excel jest dobrze napisany, z walidacjami i automatyką, to może być nawet lepszy dla osób z ograniczonym dostępem do WWW.
Taki arkusz można sobie nawet wypełniać przez kilka dni.

Przy założeniach:
- arkusze dostępne w sieci w centralnym punkcie
- arkusze z pełną walidacją i ochroną komórek
- gdzieś w sieci serwer odbierający pliki lub eksporty z nich (CSV, XML), weryfikujący strukturę i wciągający je do bazy

To takie rozwiązanie jest akceptowalne, chociaż coraz mniej uzasadnione.
Czy to jest łatwiejsze lub tańsze w administracji od formularzy WWW? Raczej nie. Ktoś tu nawet wspomniał że potrzebna jest funkcja "analityka"...

Tańsze może być w implementacji - skrobnąć odpowiedni arkusz to nic trudnego.
Ale to może być koszmar dla administracji - zwłaszcza przy 700 użytkownikach.
Kreatywność ludzi nie zna granic. A proces od wypełnienia formularza do jego pełnego importu w odróżnieniu od rozwiązania WWW jest tu rozpięty na kilka kroków.

BTW, nie należę do kółka wzajemnej adoracji.

Temat: Szukam rozwiązania!

Przepraszam ale tego już sie nie da czytać.

Cytat cytatu z cytatu. To chyba nie tędy droga.

Każde rozwiązanie jest sumą potrzeb, kosztów, wiedzy i umiejętności.

Jeżeli coś ma usprawnić pracę to musi być proste dla użytkownika i łatwo administrowalne. Czy to będzie aplikacja www, excel, access, SQL czy coś innego to naprawdę nie ma znaczenia. Urzytkownika nie interesuje w czym to jest zrobione. Ma być proste łatwe i przyjemne dla urzytkownika.

A co do narzędzi to jest to dywagacja nad wyższościa świąt Wielkiej Nocy nad świętami Bożego Narodzenia. Śliczna i doskonale zrobiona aplikacja SQL-owa będzie o kant d... potłuc jak jej twórca pójdzie na chorobowe a zastępca nie będzie znał równie dobrze SQL-a. Pozatym przepraszam ale przy takiej liczbie rekordów i danych to chyba raczej baza SQL-owa nie do końca jest potrzebna. Bardzej porządna analiza i dostępnych narzędzi (w sensie umiejętności również) i potrzeb urzytkownika a nadewszystko dobra walidacja danych przy wprowadzaniu. Inaczej nawet złote narzędzie nie pomoże.

Temat: Szukam rozwiązania!

Wojciech Gardziński:

- gdzieś w sieci serwer odbierający pliki lub eksporty z nich (CSV, XML), weryfikujący strukturę i wciągający je do bazy

Prawie dobrze. Tylko po co XML i CSV? Co, ADO/ODBC nie umie brać danych z XLSków?

Cieszę się, że w końcu wyszło to, o czym myślałem i po części pisałem na samym początku. To ile powinienem zarabiać z takim podejściem do sprawy? Muszę pogadać z przełożonymi chyba...

Aplikacja webowa automatycznie przetwarzająca wprowadzane dane jak rozumiem wygrywa. Rozumiem tym samym, że kłótnia dotyczyła tego, czy formularz w HTML ma zawierać inputy specyficzne dla problemu, czy "file" do zaciągania danych całościowo z pliku. Ufff... a już myślałem, że to wojna ludzie kontra maszyny.

A teraz panowie na piwo, bo rżniecie się na noże, jakbyście obaj nie byli wysokiej klasy specjalistami.

Temat: Szukam rozwiązania!

Wojciech Gardziński:
Nie, proszę Pana, nie ma Pan racji. Aplikacja webowa nie jest do tego celu ani niezbędna, ani nawet potrzebna.

Heh, oczywiście nie jest niezbędna, ale "gdzieś w sieci serwer odbierający pliki lub eksporty z nich (CSV, XML), weryfikujący strukturę i wciągający je do bazy" to właśnie aplikacja webowa, a przynajmniej klient-serwer (jeśli odżegnujemy się od pojęcia sieci, ale chyba nie każe Pan tym biednym ludziom jechać po telnecie?).

Nie mam zamiaru udowadniać, że nie jestem wielbłądem, bo z praktyki wiem, że nie wszystkich się da przekonać. O! I praktykiem się okazałem! Miłej wojny.

EOT.

Temat: Szukam rozwiązania!

Witam,
ja podsumowałbym to tak :
Dla "wyznawców" Excel'a nie są potrzebne ERP'y, MRP'y, HR'y .. idt, wszystko da się "dobrze" i "niezawodnie", a przede wszystkim "tanio" zrobić w Excel'u.

Ps.
Excel, jest znakomity arkuszem kalkulacyjnym,jak zresztą sama nazwa na to wskazuje :)

Temat: Szukam rozwiązania!

Ile licencji na MS Excel i dodatki trzeba zakupić?

Temat: Szukam rozwiązania!

Marcin Miga:
Ile licencji na MS Excel i dodatki trzeba zakupić?

ciii bo się wyda, że darmowe wcale nie jest darmowe i słono kosztuje zarówno jeżeli chodzi o licencje jak i roboczogodziny przy obsłudze (takie rozwiązania nadzoruje przeważnie autor za cieżką kasę)