Pratim tvoje posteve od kad si na forumu počeo pisati o onom svom programu blagajne. Očigledno je da napreduješ, no gubiš dosta vremena metodama pokušaja i pogreške. Lijepo je sam doći do nekog zaključka i nešto napraviti, no što je projekt kompleksniji ti ti je ta metoda uzaludnija i sporija. Trenutno gubiš vrijeme na nešto što ljudi rade tamo negdje još od prije 90'tih godina. Davnih dana je za vođenje stanja zaliha i praćenje prometa razvijeno nekoliko mehanizama. Zbilja nema smisla izmišljati ih jer je puno mudrih umova tražilo riješenje i na kraju su se iskristalizirale 3 ili 4 moguće metode, ovisne o očekivanoj količini stavaka, metodi vođenja skladišta i sl. Preporučujem ti da uzmeš neki gotovi i ispitani program ili više njih i pogledaš kako su složene baze. Ne ih kopirati, nego samo pogledaj kako su ustrojene i što se kamo veže, čisto da dobiješ viziju i osjećaj.
Vidjećeš da ova tvoja postojeća metoda s prepisivanjem i brisanjem pada u vodu kad se posvetiš prosječnoj prodajnoj, prosječnoj nabavno cijeni i kad kreneš u fifo, lifo, ponderiranu vrijednost i sl. Za brz izračun zaliha i sl. uglavnom se koristi neka tablica sa stanjima koja se znatno komplicira kod konkurentnog pristupa više korisnika, za sve prometne transakcije moraš imati prometne tablice iz kojih se vidi od kamo je što i kako nastao, a iste ti kod manje količine stavaka zamjenjuju ove tablice sa stanjima jer sve računaš dinamički - u letu. Ako ne želiš raditi batch obrade (ažuriranje stanja) ili ih raditi na kraju svake transakcije (što je dosta naporno) tada ta ažuriranja složiš da ih odrađuje sama baza uglavnom uporabom triggera na bazi, no BDE i Paradox (ako se sjećam ni access) to nemaju. Ima i u tome zamki (triggerima) i treba ih pažljivo i mudro koristiti. Ako želiš različit utjecaj na stanje skladišta i prometa tada promet složiš sa različitim statusima dokumenta. Npr. rezervacije, izdano no tek treba fakturirati, kod proizvođača (pc servisi, kafići, restorani, cvjećari) imaš i vođenje rpoizvodnje i razduživanje. Primjerice, cvjećari unaprijed naprave 10 vjenaca, razdužuju robu sa skladišta i pretvaraju je u proizvod, istovremeno tog cvijeća, vrpce, trave i žice nemaš na skladištu i ne možeš ih nekome prodati no pojavljuje se proizvod, a proizvod nije prodan sve dok ga netko ne kupi. Tu ti osim vrsta dokumenata ulogu igraju i statusi dokumenata i njihova proknjižavanja.
Sve ovo te vodi prema izboru neke inteligentnije baze i baze koja bolje čuva referentni integritet nego što to čini Paradox.
Vidim da pišete o BDE i DbGo (ADO). Na žalost oboje je odavno pregazilo vrijeme i imaju velikih manjkavosti. BDE je bio zakon svih zakona no više zbilja nema smisla, Paradox kao baza također. dbGO je strašno ovisan o M$-u. i iznimno mušićav. Ne pišem ovo bezveze. Koristio sam godinama BDE (napustio ga je i sam Borland, a poslije i CodeGear i Embarcadero i drže ga samo zbog naslijedstva) i bio je dobar kad nije bilo boljega. dbGo je bio kao nešto univerzalno s čime možeš sve od svud, ovo, ono... no ispalo je poprilično problematično i sporo, ovisno o ODBC-u. verziji drivera, providera bla, bla... U Delphiju se davnih dana pojavio DBX na kojem se temelji puno više od običnih desktop ili RDBMS baza, no istina djelomično je ograničen driverima ovisno o verziji baze. DBX je najintegriraniji u Delphi i tebalo bi ga razmotriti i poigrati se njime čisto da dobiješ bolji uvid i znanje o ozbiljnom radu sa bazama (client dataset, vidjeti što je to dataset delta, kada se podaci osvježavaju, kada i zašto povlače, commitanje i ograničavanje na samo nužan skup podataka i sl.). I Paradox i BDE će tužno umrijeti već na idućoj generaciji OS-a. koji promjeni politiku file lockinga ili raw pristupa fajlovima preko SMB-a. Da ne spominjem da se već godinama programi koji rade s bazama preko mreže ne koriste ničim grugim osim TCP/IP-a. što ima višestruke razloge i opravdanja. Jedini je u tome u produkciji ostao valjda još Clarion, a čak i oni okreču ploču (a koliko vidim i odlaze u povijest).
Radio sam 2 godine u firmi koja je koristila dbGO za rad s MSSQL-om. Super baza, sve M$-ovo, rekao bi čovjek - prirodno i razumnjivo. Kad su skvatili ograničenja i mane dbGO-a. tj. ADO-a. bilo je kasno. Odlučili smo se na novi razvoj i pokušali migrirati ADO u MSDAC no bezuspješno jer je moj prethodnik izveo takve zavrzlame svojstvene za ADO da je migracija ispala nemoguća. I sad svakog dana plaćaju ceh korištenja ADO-a.
Preporučujem ti Firebird koji je izvrsna baza (besplatna), SQLite također može dosta toga, a koji će ti dobro doći poželiš li raditi nešto za mobilne uređaje ili nešto slično. Za pristup imaš native kontrole. IBX je još uvijek donekle kompatibilan s FB, imaš IBX, a uz novi Delphi ti dolaze FireDAC kontrole koje su očigledno delphijeva budućnost i vjerojatno će uz DBX istisnuti sve ostale vrste pristupa bazama iz Delphija, i to vjerojatno već za godinu-dvije. Želiš li nešto besplatno, univerzalno i portabilno imaš ZEOS DBO / ZEOS Lib. ZeosLib ti može biti interesantan zbog toga što radi s lazarusom i lakše ćeš portati postojeći kod na lazarus pošeliš li multiplatformsko i besplatno programiranje. Slično ću ti savjetovati za reporter - bježi od QR-a. FastReports dolaze u nekoj prilagođenoj verziji uz Delphi već par godina i sam Borland (tj. Embarcadero) se okrenuo njemu. U samom je vrhu, znatno bolji od QR-a. i također radi na lazarusu (doduše mislim sourcevi dolaze uz neku jaču komercijalnu verziju) i smatra se nekom budućnosti.
Šteta je ograničavati se tehnologijama starim 15 godina, pa čak u svrhu učenja jer ćeš na njima naučiti malo, i velika je vjerojatnost naučiti dosta toga pogrešnog (klasične zamke autoinkrementa, rada bez pravih transakcija, rada s kompletnim tablicama, filtriranja na clientu, row-level updateovi i preračuni po clientu, itd, itd...). Ta ograničenja su smislena za firme koje su nešto razvile i producirale pa se sad od toga na žalost više ne mogu maknuti.
Nadam se da ti nisam dosadan i ne popujem, pišem ti zbilja dobronamjerno. Ako učiš, nauči više i nauči nešto od čega imaš više koristi i što ima neku budućnost.
God is real unless is declared as integer.