Ovako nešto?



Dodaš sum ako treba (ne znan kako ti je točno složena tabela) i group by sifra.

da,da....evo sada sam pokusao i uspelo je,ipak hvala na odgovoru...reci mi captigard,kada budes imao vremena da ti posaljem ovo sto sada radim,pa da vidis,valja li sta,,,,
U stvari,trebalo bi da mi oduzme u drugoj tabeli,da izmeni bas u tabeli,ne da na pravim kveri...

Nemam instaliran skype na novom pc-u, instaliram ga pa ti se javim, možda već sutra
Inače, ako radiš stanje zaliha, nema potrebe da taj podatak imaš zapisan već ga izvlačiš u trenutku kada ti treba.

OK,radim zalihe,i kada radim prodaju,to mi se zapisuje u privremenu bazu,gde za novu prodaju krece kao prazna,pa hoce da pre nego je izbrisem,odradim oduzimanje zaliha iz druge tabele....

Svojevremeno sam radio neke fakturice. Korišćen je XE2 i standardne dbGo komponente.

Mislim da ne radiš dobro ako brišeš prodaju a čuvaš samo količine.

Moze biti da nisam dobro zamislio,ali ako odmah pravim razliku,cim je prodajem,mozda neku stavku pogresim,pa ima mogicnost da je brisem,a ja sam je vec oduzeo iz zaliha,ako je brisem treba onda da je dodajem,sto mi je malo komplikovano,hteo sam da kada sam siguran da zelim da izdam racun,pre nego sto obrisem tu prodaju,da mi oduzme samo zalihe,jer pre nego je obrisem ti podaci iz trenutne prodaje mi idu u arhivu,tj.prebacuju se tamo,tako da mogu da pravim i neke izvestaje o prodaji....

Tebi mora baza biti složena npr. ovako:



Na taj način ništa ne moraš brisati i možeš u bilo kojem trenutku dobiti stanje nekog artikla iz onog querya gore. (Tu sam ti dao samo tablice za stavke, možeš napraviti jednu tablicu pa još dodati PK TipDokumenta ili možeš sa odvojenim tablicama, dodaš onda još tblUlaz i tblIzlaz gdje idu zaglavlja dokumenata).

OK,za to,postoji li neka mogucnost da ja to uradim,i da vrsim update glavne tabele,znaci oduzme od zaliha,i taj update upise za odgovarajuci artikal u glavnpj tabeli

Pa možeš kod knjiženja dokumenta pokrenuti onaj query i zapisati to u tabelu npr. Artikli ili gdje to već čuvaš, ali ponavljam, nema potrebe to raditi. U trenutku kada korisnik traži izvještaj možš dobiti te podatke. Ovako sa zapisivanjem uvijek postoji mogućnost pogreške.

Tebi treba nešto ovako? Nisam stigao sve da prevedem.

Slicno,samo sto je umesto faktura broj racuna,s tim sto hocu da mi oduzima zalihe,ali ne odmah kada ih ubacim,vec kada treba da mi izda racun...

Ovaj sto je napisao captigared je okej,samo ima tu jedan problem,a to je:imam dve tabele,jedna artikli,druga arhiva...i poslusao sam captigard i sve mi prebacuje u arhivu,i onda pravimtabelu koja oduzima artikal - arhiva zalihe,ali problem je sledeci,to radi samo ako u obe tabele ima ista sifra,pa onda napravi razliku,ali ako nema u arhivi(tj,nista se ne proda
) ne izlazi nista,kao da ne postoji taj artikal na zalihama...

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.

Lepo rečeno.

Sve ja to znam,a sve si ti to i lepo rekao,ali sve te baze i stari delphi je zbog okruzenja sa kojim firma radim,nisam ja to uveo,vec neko iznad mene,tako da bih i ja rado sve to promenio,ali sta cu posle,tj,kome to posle radio....Programi za nekog iskusnog zaista nisu problem,za mene u nekim delovioma jesu,jer po vokaciji nisam programer,radim drugi posao,a ovo je iz hobija i za sopstvene potrebe...

Naravno da ne mislim da popujes,posto si ocigledno u ovom poslu dosta dugo,a ja samo pocetnik,koji hoce nesto da nauci....Hvala ti svakako na dobronamernom savetu...

_{[Ovu poruku je menjao popmilan76 dana 30.04.2014. u 11:51 GMT+1]}

Napravio sam ovakav query zalihe,ali mi ne oduzima nesto dobro,pa mi recite gde gresim.....evo ga sql


select distinct artikli.sifra,artikli.artikal,artikli.jedinicamere,artikli.cena,sum(artikli.zalihe)- sum(arhiva.kolicina) as Zalihe from artikli,arhiva
where artikli.sifra = arhiva.sifra
group by artikli.sifra,artikli.artikal,artikli.jedinicamere,artikli.cena

Kako to misliš da ti ne oduzima nešto dobro?

Ne oduzima mi dobro ovo zalihe od kolicina..daje pogresan rezultat......imam dve tabele,artikli i arhiva,prva je ulaz (zalihe),druga je utrosak(kolicina).....i ta razlika mi nije dobra...ne znam zasto....

Meni bi trebao zapravo ovakav kod...i tu sam provalio sta radi duplira iznose u zalihama i u kolicinama.....



select distinct artikli.sifra,artikli.artikal,artikli.jedinicamere,artikli.cena,sum(artikli.zalihe) as ulaz,sum(arhiva.kolicina) as izlaz,sum(artikli.zalihe) - sum(arhiva.kolicina) as Zalihe from artikli,arhiva
where artikli.sifra = arhiva.sifra
group by artikli.sifra,artikli.artikal,artikli.jedinicamere,artikli.cena

Ljudi,pomagajte,kako da napravim jednu tabelu iz dve,jedna se zove artikli,druga arhiva,da pored osnovnih kolona sifre,artikla,postoji sum ulaza u tabelu artikli,sum izlaza iz tabele arhiva,i razlik ulaza i izlaza...

Čekaj, tabela artikli ti je ULAZ ili je to doslovno tabela ARTIKLI koja sadrži podatak o trenutnom stanju?

Artikli tabela je Ulaz,i sadrzi polja ,sifra,naziv artikla,...,i ulaz(zbir ulaza),a ova druga je izlaz,sadrzi ista polja kao ova,samo sto ima izlaz polje(zbir prodaje)....

probaj dodati



Nije to najoptimalniji upit, ali prvo da vidimo da li sada štima. Ako sam te dobro shvatio da zapisuješ trenutno stanje u obe tablice, niti ti ne treba sum().

Imam tabelu Artikli,koja ima polja Sifra,Artikal,Jednicamere,cena,zalihe(tu se ukucavaju ulazi za artikle,znaci doslo 10 kg necega),i za svaki ulaz postoji poseban zapis
Druga tabele,gde je prodaja necega,ima sve kao i ovo,samo umesto zaliha,imam polje kolicina(gde se ukucava,koliko je cega prodato0, i za svaku prodaju postoji odredjen zapis....
Meni treba query,koji ce u jednoj tabeli(dbgrid),prikazati Sifru,Artikal,Jednicu mere,cenu,zbir svih ulaza(zbir zaliha),zbir svih izlaza(zbir svih kolicina),i trenutno stanje,razlika ova dva poslednja polja...

Jesi probao dodati onaj gore uvjet?

Isto radi,kao i pre....
Razliku(trenutno stanje pravi dobro,lepo oduzima),ali su mi pogresni ovi zbirovi,zbir zaliha i zbir kolicina

Pa ako dobro računa razliku onda mora dobro računati i ulaz, izlaz. Inače ne bi ni razlika bila dobra. Inače si dosta loše imenovao tabele i polja pa samim time dolazi do problema u komunikaciji. Tabela Artikli govori da je to šifrarnik artikala a ne Ulaz npr. Trebao bi imati npr. ovakve tablice:


I ako želiš da imaš negdje zapisano trenutno stanje možeš npr. u tabelu Artikal dodati polje StanjeZaliha i unutra upisivati trenutno stanje.

p.s. pogledaj PM

On lepo oduzima,ono sto se pojavi u ulazu i izlazu,ali tio sto se pojavi je lose sabrano....

Kako cu ovo resiti,stavio sam onaj kod od gore,i dalje mi pogresno sabira,tj taj zbir mnozi sa brojem recorda iz druge tabele....zaista ne znam so mi to radi...