Delphi/Baza danych - przeniesienie z Excel

Ogólnie ten Excel działa dobrze, no ale to jest Excel, jeżeli używa tego kilka komórek, to każdą poprawkę w kodzie musze nanieść na każdą kopie osobiście, no i oczywiście sama stabilność Excela się kłania, często się krzaczy.

A próbowałeś wrzucić po prostu arkusz do chmury? Bo to w sumie powinno rozwiązać ten problem o ile nie wykorzystujesz w arkuszu jakichś funkcji, których nie ma w Excelu 365.

BorekJs napisał(a):

Czy ktoś z Was mógłby mnie naprowadzić na rozwiązanie w Delphi (komponent?) w którym mógłbym zrobić coś podobnego?

Komponentu jako takiego nie dasz rady znaleźć który robi dokładnie to samo co Twój Excel. Jednak możesz użyć np, TStringGrid'a do prezentacji danych i mieć podobną graficznie formę. Natomiast same obliczenia już zaszyć w programie.

BorekJs napisał(a):

Jaką baze danych wybrać? Najlepiej taka która nie jest zależna od maszyny(nie trzeba instalować - w pracy nie mamy uprawnień admina na instalacje czego kolwiek - nawet tapety nie można zmienić :) )

Ze swojej strony polecę https://www.firebirdsql.org/ Ma on wersję Embedded którą to wrzucasz po prostu jako kilka plików *.dll i łączysz się do bazy i już. Nie potrzeba niczego instalować, konfigurować. A jeśli byś chciał kiedyś zmienić bazę na działającą w sieci by kilka komputerów mogło korzystać na raz z jednej bazy, to też nie będzie z tym problemu. Po prostu wskażesz bazę danych na serwerze i działa bez zmiany programu.

BorekJs napisał(a):

A co sądzicie żeby napisać ten program nie w Komercyjnym Delphi ale w darmowym Lazarus czy też CodeTyphon? dało by rade czy szkoda czasu na przesiadkę?

Myślę, że nie ma co tylko spróbuj napisać coś takiego. Excel sam w sobie jest fajnym narzędziem, ale czasami analiza i szukanie błędów w takich arkuszach jest problematyczne, więc napisanie programu w jakimkolwiek sensownym języku programowania będzie o wiele lepsze. Dodatkowo stabilność powinna być większa, skalowalność tak samo. Utrzymanie tego programiku też dla mnie by było o wiele prostsze niż klepanie regułek w Excelu. Dodatkowo przekazanie tego komuś innemu czy dołączenie się do rozwoju będzie łatwiejsze.

Moim zdaniem da się napisać taki program nawet w darmowym Lazarusie.

To więcej pracy niż się wydaje a efekt będzie jeszcze gorszy niż excel. Jak działa to bym został przy excelu.
Jak wyżej ktoś zaproponował - wrzuć do chmury plus dodatkowo jeśli chcesz formuły aktualizować tylko w jednym miejscu to teoretycznie możliwe jest zrobić template z formułami a potem w nowych dokumentach linkować komórki do innego skoroszytu, wtedy aktualizujesz formułę w szablonie i wszystkie zależne dokumenty też się zaktualizują.

BorekJs napisał(a):

Przychodzę do Was z problemem (dla mnie dużym), chciałbym wrócić do programowania w Delphi (przestałem programować z 15 lat temu)

Jeśli już koniecznie chcesz zrobić z tego aplikację to polecam przejść za projektantem Delphi na jego nowszy twór czyli C# - będziesz mógł użyć lepszego, darmowego IDE, mieć dostęp do większej ilości współczesnych komponentów i wsparcia; dużo idei które pamiętasz może jeszcze z delphi będziesz mógł odnaleźć w c#. Delphi w zasadzie umarło właśnie jakieś 15 lat temu.

No dobra to ja spróbuję nieco bardziej merytorycznie bo kilka takich projektów już robiłem (excel na aplikację webową, excel na bazę i klienta w delpi, excel na aplikację mobilną - to był hardcore).

Wspomniałeś o tym, że to jest excel w firmie i masz wiele "komórek" - jak rozumiem komórek organizacyjnych - w takim wypadku musisz rozważyć porządnie architekturę rozwiązania

1. Tworzysz aplikację (klienta) w delphi i ten klient posiada również swoją bazę. W takim wypadku baza typu firebird, sqlite lub portable postgresql. Niestety to rozwiązanie w dłuższej perspektywie utrzymaniowej ma te same wady do excel. Różnica jest tylko taka, że każda aplikacja ma swoją instancję bazy więc nie ma problemu z blokowaniem czegokolwiek. Natomiast utrzymanie, rozwój, rozbudowa czy to bazy czy aplikacji jest uciążliwa bo trzeba to robić na każdym kompie gdzie ta aplikacja z bazą stoi. Oczywiście możesz do tego napisać autoupdater zarówno aplikacji jak i bazy ale dalej będziesz miał problem z np replikacją danych między klientami/komórkami. W dodatku autoupdater zadziała tylko wtedy gdy z każdego komputera w firmie będzie dostęp do jakiegoś udziału sieciowego (czy to wewnątrz LAN czy to na zewnątrz) z którego pobierze się paczka aktualizacyjna.
2. Tworzysz aplikacje (klientów) w delphi ale na jednym centralnym serwerze w firmie stoi jedna wspólna baza danych. Do tego celu najlepiej nada się postgresql. To rozwiązanie ma w zasadzie tylko zalety pod względem utrzymaniowym i rozwojowym bo w 1 bazie masz wszystkie informacje. Możesz spokojnie wyciągać dowolne informacje w dowolnym dziale z dowolnego działu, łączyć je we wspólne raporty itd. Ktoś doda pracownika w dziale X, automatycznie pojawi się u wszystkich. Niestety to podejście wymaga nieco pracy administracyjnej bo trzeba taką bazę postawić i do każdego kompa w firmie dać dostęp sieciowy. Ponadto sama instalacja i konfiguracja postgresa wymaga nieco doświadczenia. Serwer bazodanowy też wymaga konserwacji, backupowania itd. Natomiast sam postgres posiada szerego dodatkowych funkcji jak np PostgREST więc w delphi masz możliwość połączenia bezpośredniego lub strzelania/czytania po restach. Sam REST umożliwi Ci też ewentualne przyszłościowe rozbudowanie systemu o nowe funkcjonalności typu microserwisy/web/mobilki
3. Oba powyższe rozwiązania opierają się o ten sam system operacyjny (np Windows) gdzie tworzysz sobie klienta w delphi. Natomiast w firmie jak to w firmie przyjdzie nowy dyrektor i zażyczy sobie mcbooka i jesteś w szarej ... Możesz kupić delphi z kompilatorem crossplatformowym i dziergać w FMX lub skorzystać z czegoś darmowego typu Lazarus natomiast zaraz ktoś przyjdzie z pomyslem, że chce na telefonie się połączyć albo na linuxie i znowu ból głowy murowany. Ja osobiście byłem w takiej sytuacji i postawiłem na bazę danych z pkt 2 + gui webowe. Niestety to podejście mimo, iż najbardziej uniwersalne dla użytkownika końcowego, przynajmniej dla mnie było najbardziej uciążliwe zarówno od strony administracyjnej jak i programistycznej. Po pierwsze baza danych. W zależności od tego co wybierzesz (ja wybrałem wordpress'a) to tutaj np zmuszony byłem skorzystać z mariadb. Raczej proponuję użyć gotowego frameworka do WWW niż tworzyć od 0 bo to jest gigantyczna ilość pracy, a taki wordpress np udostępnia Ci cały CMS do zarządzania i w zasadzie z klocków budujesz sobie stronę. Panel administracyjny, zarządzanie stroną, użytkownikami, treścią wszystko jest. Niestety to czego nie ma, a to co byś potrzebował trzeba wydziergać samemu. Tu zostaje Ci HTML,CSS, JS w przypadku wordpress dodatkowo PHP w innych narzędziach różnie. Także o delphi możesz zapomnieć. W dodatku serwer WWW podobnie jak serwer bazodanowy wymaga opieki. Tu z plusów jest na pewno to, że u wszystkich działa. Tam gdzie jest przeglądarka z dostępem do danego serwera masz pewność, że się uruchomi. Może się gdzieś coś źle przeskalować ale np w takim wordpress silnik sam o to dba jak zrobisz to dobrze.
4. Niby 4 ale tak naprawdę chyba 3.a. Są narzędzia typu apex.oracle.com, które udostępniają po pierwsze bazę, po drugie gotowy CMS do tworzenia WWW w opraciu o tą bazę. Na tym serwerze masz już wszystko skonfigurowane, uruchomione i działające. Są jednak 2 minusy. Baza danych jest wspólna więc o prywatności danych możesz zapomnieć. Drugim jest niestety odrobina wiedzy na temat oracle i apex aby zacząć. Natomiast możesz oracle xe postawić u siebie i doinstalować do tego apexa. Wtedy strony tworzysz jak chcesz, a cały kod upychasz w pl/sql.

Co do samej kwestii wizualnej. To co w tym excelu masz to w czystym delphi tak łatwo nie zrobisz. W przypadku komponentów typu DB to są to raczej proste narzędzia natomiast istnieją też narzędzia płatne. Z tego screena wynika, że najlepiej sprawdziłby Ci się cxGrid. W przypadku WWW funkcjonalność cxGrida próbowałem zrobić przy użyciu JQuery i DataGrida ale tam też sporo dziergania i też nie wszystkie funkcjonalności tegoż excela uzyskasz. Są też inne technologie jak node js lub react i tam sporo gotowych narzędzi ale ja z nimi nie miałem doświadczenia niestety.

Zastanów się tak naprawdę czego potrzebujesz policz co jest dla Ciebie najlepsze pod względem czasu wytworzenia i późniejszego utrzymania. Sorki za długi post ale liczę, że dość obrazowo przedstawiłem Ci problemy, z którymi będziesz musiał się zmierzyć.

Dzięki wszystkim za odpowiedzi.
Na razie zostanę przy Excelu, poprawie tylko wydajność itp.
Jeżeli chodzi o komórki to chodziło mi o komórki organizacyjne, w jednej takiej komórce jest powiedzmy 100 pracowników, a w drugiej 150. Ten arkusz który jest na załączonym obrazku to jest tylko jeden z wielu, ten jest tak jakby główny w którym znajdują się informacje na temat przepracowanych dni, urlopów itp... (w postaci np.: 1, 1P, 1U i tak dalej, excel później zlicza)
Jako że jako tako kasy z tego nie mam, zrobiłem to z czystej przyjemności i chęci pomocy dla osoby która zajmuje się tym zliczaniem, nie widzę sensu w kupowaniu jakiegokolwiek komponentu czy też IDE, więc mając na uwadze Wasze odpowiedzi spróbuje może w C# i WPF (jest za free a jeżeli uda mi się to zrobić, to nikt nie przyczepi się że napisałem program w jakimś lewym IDE czy coś) - ale to i tak tylko z czystej mojej fantazji żeby zająć czymś głowę
Jeszcze raz dzięki za odpowiedzi.
Pozdrawiam
Wesołych Świąt
Boro