Da bi unosila podatke u tabelu preko forme nije ti potrebna nikakva procedura pisana u VBA, dovoljno je da formi za Record Source u Property-ju postavis odgovarajucu tabelu ili mozes za pocetak jednostavnije da pozoves carobnjaka (Form Wizard) za kreiranje forme u kome biras koja ce tabela biti Record Source i koja ce se polja nalaziti na formi a koja se nalaze vec u tabeli.

U prilogu ti je tvoj primer iz prethodnog posta sa formom za unos podataka.
Ako se ne snadjes okaci tvoju bazu pa da resimo problem.

Umem da uradim sa wizardom, nije to poenta, želim da popravim proceduru (ako se tako kaže). Zanima me zašto ne radi ako je OsovinaID autonumber, i kako da napravim da radi (Zašto autonumber polje ne mogu da editujem a number mogu). Bazu kad napravim pomoću wizarda, ne sviđa mi se kako izgleda, ne mogu da radim sitne prepravke i ne znam kako sam je napravila. Ovako učim i VB i Access, uživam u tome a moja forma sve lepše izgleda i sve je funkcionalnija. Ne želim da je napravim pomoću wizarda za 2 minuta, ne želim da je neko drugi napravi... volela bih da naučim da sama napravim neke prostije stvari, a ovo mi deluje veoma prosto.

Pa AutoNumber ne mozes da editujes iz razloga sto takav tip podatka Access sam kreira time postize da svaki zapis ima razlicitu vrednost pa se zato i preporucuje da se taj tip podatka koristi za Primarni kljuc.
Formu i ako napravis preko Wizarda mozes je prepravljati kako tebi odgovara samo sto je potrebno da formu otvoris u Design modu (desni klik na formu i odaberes Design).
Na ovaj nacin kako ti hoces da uneses podatke u tabelu samo sebi komplikuse izradu baze, za ove tvoje potrebe ti nije neophodno ovako unositi podatke. Ako zelis da naucis Access mogu ti poslati neke tutorijale koji su u PDF-u a koje sam i ja koristio.

Nekako se ne razumemo. Nije baš da ništa ne znam, vreme prolazi a ja učim, čitam forum, gledam primere na youtube. U davna vremena (80 i neke) sam učika basic na zx spectrumu, kasnije se malo igrala sa MS-Dos C-om. Sada želim da malo naučim da radim u Access-u.

Trenutno sam napravila formu bez wizarda ručno po uzoru na:




Sve funkcioniše sem Edit-a. Da li je moguće uraditi "Edit" ovako ako je ID polje autonumber?

Kao sto sam ti vec i rekao, nije moguce jer Access sam generise vrednosti za AutoNumber. Ako vec zelis da na taj nacin editujes ili dodajes podatak za to polje moraces da ostavis tip polja da bude Number. Nem svrhe stavljati polje tipa AutoNumber ako vec sama zelis da unosis taj podatak.

marija.ana ima pravo.
daleko je bolje napraviti nevezanu formu te prko sql-a vrsiti manipulaciju podacima iz baze.
Zasto je to Bolje?.
Ukoliko imate napr u ovoj tabeli 200 000 redova i ako zelite dopisati samo jos jedan red vi pri podizanju forme podizete svih 200 000 redova koji vam netrebaju i ako se radi u mreznom rezimu onda to bude veoma sporo pa se to pokusava rijesiti MSSQl bazom.
Naravno to ce raditi sporo i Na MSSQL bazi.

U njenom slucaju pri unosu podataka nemate nikakve veze sa tabelom. Tek kada zavrsimo sa pisanjem i kliknemo na komandni taster na kome se nalazi ovaj kod prosleđujemo podatke bazi pomocu pisnog SQL stringa.

Hvala izonic to je to.

Sledeci problem koji sam primetila je da kada su sva polja prazna a ja klinkem na dugme Add dobijem gresku "Run-time error '3134': Syntax error in INSERT INTO statement." kako da isključim ovaj error msg ili da stavim neki u kom ja mogu da napišem poruku?

Mozda ovo posluzi, dodao sam par linija koda na onaj prethodni

Dok pise add vjerovatno sluzi za dodavanje novog rekorda a posto nisi popunila pšredhodni sto si dodala onda prijavi gresku.

Hvala svima.

Sada sam poželela da na dvoklik na zapis u subformi pozovem Edit dugme sa mainforme (tj njegov public sub).






Probala da u subformi stavim na index on dbl click:


i:



i ništa se ne dešava... sad razmišljam da li fali neki link criteria ili sam skroz zalutala.

Nije bas da nije izvodivo alinije uobicajeno niti preporucivo da se tako pravi.

Teorija kaze ako je procedura publikovana (Public) da je njen doseg na nivou nase aplikacije sto znaci da je mozemo pozvati sa bilo kojeg mjesta.
U praksi to bas i nije tako.
Ako malo sagledamo nasa forma je objekat za sebe i na njoj imamo modul za pisanje koda.
Taj kod se sav odnosi samo na tu formu sto znaci da je private.

Bolje je napraviti ovako:
Napravi neki Modul i u njemu napravi proceduru te u nju prebaci tvoj kod koji se nalazi na cmdEdit_Click.

E sad ima nesto i u tvom kodu:
If Not (Me.OsovineSubF.Form.Recordset.EOF And Me.OsovineSubF.Form.Recordset.BOF) Then
'Ja bi ovo preveo ovako:
Ako dodje nije kraju i ako je na pocetku rekordseta.
Pretpostavljam da si htjela postaviti uslov da ako nema u recordsetu niti jednog reda.
Ako sam u pravu onda bi to izgledalo ovako:

Hvala svima, posebno Izonic-u

Ubi me SQL sintaksa, gde bih mogla da naučim malo oko toga (osnove). Celu noć sam pokušavala da napišem jedan red :(




Krenula da pravim formu za unos podataka u child tabelu (primary je kombinovani osovinaID i Datum) i ubi me ono posle "WHERE" (ne umem pravilno da napišem). Ako bi neko bio voljan da mi popravi ovo i da me uputi gde bih mogla da naučim malo o ovim apostrofima, zarezima, navodnicima i ostalim kukama i kvakama koje mi ne daju da spavam.

Pretpostavljam da sam deo: pravilno napisala i da je greška u kukama i kvakama posle WHERE.

Mislim da ti datum pravi problem, trebalo bi da koristis Americki zapis datuma. I meni je to pravilo problem ali kada sam koristio ovaj zapis radilo je OK.
A da bi naucila SQL sintaksu mozes da koristis Access-ove upite (Query), oni su ustvari SQL kod samo sto u Access-u upite mozes da kreiras u Design modu a mozes i kao SQL kod. Kada kreiras upit u Design modu snimi ga i otvori u SQL modu videces SQL kod pa mozes malo da ga analiziras i iz toga naucis sintaksu, pa ako treba mozes taj kod kopiratu u VBA editor i tamo ga koristiti.

Hvala FOX!

Uradila kako Ste mi preporučili . Kada napravim update query i prebacim na SQL View dobijam:



ali i dalje nigde navodnika a ni format nije kao u onoj proceduri iznad. (a ja i dalje ne znam kako da prebacim ovo u VBA...)

Kada pokrenes taj upit (Query) koji si napravila da li odradi sve kako treba?

Ako odradi sve kako treba mozes preko VBA pokrenuti taj Query i da izvrsi azuriranje podataka



Na ovaj nacin uprostis pisanje procedura u VBA i procedure ce ti biti razumljivije.

Ako bas hoces bez pozivanja Query-ja onda bi kod izgledao ovako:



Ndam se da sam dobro napisao kod s obzirom da nisam imao konkretnu bazu, ako bude bilo problema okaci bazu pa cu ispraviti kod kako treba.
I mislim da bi trebalo da koristis .Value a ne .Tag
Trebalo bi da i tvoj kod radi samo pokusaj da prvo datum konvertujes u format kao sto sam ja to uradio u mom kodu.

Tag koristim da skladištim OsovinaID i Datum (primary key) u slučaju menjanja zapisa. Moj kod ne radi (syntax error) izgrešila sa navodnicima. Evo moje bazice u pokušaju. Ne radi mi Add / Update i Delete u DnevnikF formi.


p.s. auuu muke sa uploadom, jedva nađoh kako, pa zatim i ograničenje. Ne može upload, evo linka

_{[Ovu poruku je menjao marija.ana dana 21.07.2014. u 14:25 GMT+1]}

U proceduri si pozivala neku sub formu DnevnikSubF2 koja uopste ne postoji, u proceduri Add imas nazive nikh polja koja uopste ne postoje na formi. Da bi sve ovo izbegla potrebno je da u VBA editoru odes na Debug=>Compile i ako postoji neka nelogicnost Access ce ti to sam pokazati.
Koliko sam mogao da vidim ti si za jedno dugme htela da ti radi dve funkcije, da dodaje novu stavku i da je azurira nakon editovanja, ako hoces da odradis na taj nacin onda moras u VBA da prvo ispitas koji stoji naziv za taj taster (Add ili Update) i u zavisnosti od toga da zna sta da radi.
U tabeli Dnevnik za Datum tip podataka si stavila Text i ogranicila na 9 karaketra pa ti je datum bio 17.03.201 nedostaje jos jedan karakter, za ovo polje sam ti promenio tip podatka na Date\Time.

Nisam uspeo da odradim onako kako si zapocela vec sam kreirao akcione upite koji se pozivaju iz VBA, kod mene sve radi kako treba. Ndam se da ti odgovara ovako.

Sto se tice velicine baze mozes je smanjiti koriscenjem opcije Compact. Pogledaj sledeci link

http://www.fmsinc.com/microsoftaccess/compact/compact-on-close.html

Pozz

Dvojka je missclick. Treba samo DnevnikSubF.






To sam copy paste tvoje resenje post iznad a ti si tu permutovao neka polja.




Hvala ovo mi je bas trebalo.




Nemoguće da ne može da se odradi pomoću VBA. Ovo što je Izonic dao u postu ispred, radi savršeno:





To mi je u formi osovine ali je tu samo jedno polje primary key i upisuje se WHERE OsovinaID=" & Me.txtID.Tag U formi Dnevnik je procedura drugacija posto je primary kombinovani datum i osovinaID, e sad koliko sam videla radi mi i u formi dnevnik sve sem update zbog onog posle WHERE

U formi Osovine je WHERE OsovinaID=" & Me.txtID.Tag

A u formi Dnevnik je kombinovani primary pa mora da se snima po broju osovine i po datumu. Ja probala WHERE OsovinaID=" & Me.txtID.Tag And Datum=" & Me.txtDatum.Tag al šipak, ne radi a baš sam se zainatila.

Isto tako ni Delete ne umem da napišem u Dnevnik formi zbog Kombinovanog kljuca

Evo lepa igracka koja pomaze u prevodjenju SQL izraza u VB. Napises kveri, a onda ga ovo prevede u VB izraz.


http://www.dpriver.com/products/sqlpp/index.php

Ne razumem samo zasto bi sama sebi komplikovala i pisala glomazne SQL naredbe u VBA ako vec mozes kreirati jednostavnije i brze akcioni upit i kasnije ga samo preko VBA pozvati da izvrsi svoj zadatak, kao u primeru koji sam ti okacio. Za ovu prostiju bazu i mozes tako da radis ali kada ova jednostavna baza postane ozbiljnija i kompleksnija trebace ti gomila kodova da izvrsis neki proces koji bi mogla izvrsiti mnogo brze zahvaljujuci alatkama koje nam nudi sam Access.

Evo na primer koliko ti je bilo potrebno da napises sve ove kodove za Update, Add i Delete dok je sve to moglo da se resi sa akcionim upitima za 5 min.

MArija.Ana, Fox028 je u pravu, skoro 100%. Access je napravljen da bi radio na nacin suprotan od onoga sto pokusavas da napravis. Ti pokusavas da nateras Access da se ponasa kao VB. medjutim, Access nije napravlejn da se ponasa kao VB. U stvari, dobar VB program koji radi sa bazama podataka, treba da se ponasa kao Access, ali takvih programa je jako malo. Sta pokusavam da kazem? Access je baza podataka, kojojje dodata jedna varijanta VB jezika, da omoguci programiranje, kad je to potrebno. Sto se tice manipulacije podacima, programiranje absolutno nije potrebno. Zasto bi neko pisao kod za brisanje tacno jednog rekorda kad se to moze uraditi jednim klikom, bez programiranja? Vidis i sam kako se zakomplikovalo sve. Nije cilj da logiku programiranja u C i VB primenis u Accessu.

Logika Accessa: Access je baza podataka = skup tabela, koje se sto je moguce vise pokoravaju zakonima relacione teorije. To izmedju ostalog znaci: 1) rekordi su jedinstveni u svakoj tabeli (Primary Key), 2) rekordi iz jedne tabele mogu da zavise od rekorda u nekoj drugoj tabeli (Foreign Key). Zavisnost preko FK se moze prikazati preko ER dijagrama - Entity-Relationship, 1:vise, vise:vise itd. To si lepo napravila. Kako se iz toga izvodi plan aplikacije (plan u smislu arhitektonskih planova za izgradnju kuce)? Za tabele koje su na strani 1 kreira se po jedna forma, u Form View. Za tabele na strani vise kreiraju se datasheet forme. Onda se datashit forme postave na glavnu formu, kao vezane subforme. U tvom slucaju, treba ti datasheet za Dnevnik i forma za Osovine i jedna za Stanja. Otvori verziju koju ti saljem i pogledaj form koje su imenovane sa Z_ . nem bas mnogo koda, a sve moze da se uradi. Za nesto vise, treba kod, ali ne onako, rekordseti i slicno. Ne ni parameter kveriji kao sto predlaze Fox028, postoji kod u tri linije koji postize isto i bez cuvanja kverija.

I naravno, kad projektujes bazu, polja treba da su odgovarajuceg tipa. Na primer, datumi ne treba da budu text nego DateTime. U tom slucaju dobijes onaj lepi kalendar automatski i ne mozes da uneses recimo 31 Februar (u tekst polje naravno da mozes )

Znaci, ne gubi vreme prevodeci C ili VB kod u Access, nego pokusaj da projektujes bazu pravilno, kao i da aplikaciju razvijas onako kako se to u Accesu radi - sa sto manje koda (makroi su zabranjeni ABSOLUTNO). Bice vremena za kod, ali to ce biti pravoi kod, koji zaista nesto radi. ne vredi trositi snagu u vreme na elementarne stvari (insert/edit/delete/search) - sve to Access ima vec ugradjeno, samo se treba setiti i primeniti.

Zakacena aplikacija je kostur, prvi prototip, kasko treba da se razmislja kad radis u Accessu. Prototip jeste, ali prototip koji radi.

U pocetku nisam ja predlagao da se koriste akcionu upiti niti da se preko VBA upravlja bazom vec kasnije jer je bilo jednostavnije od nacina na koji je krenula da radi mada ni to nije jednostavnije slazem se. I ja sam takdje predlagao da krene da radi slicnom metodom kao sto predlaze i Zidar.

Samo sam se drzao one nase izreke: Vezi konja gde ti gazda kaze. :)

Ali u principu podrzavam Zidarevu teoriju u potpunosti.

Ja podržavam svakog (pogotovo onog ko zna više od mene), a pretpostavljam da svi ostali korisnici ovog foruma znaju više od mene. Ono što mene zanima je kako da pomoću VBA da napravim dugme za brisanje ili update/edit. U mojoj Add/Update proceduri je sve u redu sem onog posle WHERE (add radi ali update ne radi)


Da zanemarimo moju bazu i sve ostalo, može li mi neko odgovoriti kako da pravilno postavim uslov posle WHERE.

U formi OsovineF (želim da zapis bude tamo gde je OsovinaID jednaka vrednosti polja txtID) to sam postigao sa:

Ovaj code iznad je ispravan


E sad u formi DnevnikF ((želim da zapis bude tamo gde je OsovinaID jednaka vrednosti polja txtID) i (želim da zapis bude tamo gde je Datum jednak vrednosti polja txtDatum)) znači otprilike ovako:

E ovaj code nije ispravan, može li neko da me uputi kako da ovo pravilno napisem?

Prvo sto moramo znati a to je kojeg su tipa polja u tabeli:
Broj
String
Datum

Broj:
OsovinaID ti je brojcana vrijednost pa cemo to upisati u memorijsku iz taga ovako:
Dim OsovinaID as integer

OsovinaID=Val(Me.txtId.tag)

Strin:
Svaki strin u Vb moramo pisati pod znacima navoda a SQL kod prosledjujemo isto tako kao strin sto znaci da prakticno cio
SQL moramo pisati oivicen kao strin odnoano znacima navoda.
i SQL ima svoja pravila pa i u njemu tekstualni podatak moramo pisati kao string odnosno oviciti ga znacima navoda.
Sad ispada da imamo string u stringu sto bi vb protumacio kao dva stringa.
Doduse u SQL pored ovog (") znaka navoda strin mozemo oiviciti i sa ovim znakom (')
Znaci ako prosledjujemo sql string koji sadrzi podatak kao strin onda to mozemo uciniti ovako:

"WHERE imepolja=' nekiPodatakstr ' "
Ovo je i dosta lako ali sta ako imamo podatak u vb memorijkoj:
Dim Str as string

Str=Me.NekoPolje

Sada bi to izgledalo ovako:
"WHERE ImePolja='" & str & "'"
& Znak za sabiranje stringova a moze ga zamijeniti i znak +

Datum:
SQL baza podrzava forma datuma mjesec dan godina oivicen tarabama (#)

To se moze rijesiti ovako:
Dim MojDatum as string
MojDatum= "#" & fromat(Me.txtDatum.Tag,"mm-dd-yyyy") & "#"

Znaci tvoj Uslov bi izgledeao ovako:

Dim MojDatum as string
Dim OsovinaID as integer

OsovinaID=Val(Me.txtId.tag)
MojDatum= "#" & fromat(Me.txtDatum.Tag,"mm-dd-yyyy") & "#"
"WHERE OsovinaID=" & OsovinaID & " AND Datum=" & MojDatum

Hvala Izonic, Kralju! Objašnjeno i (ja se nadam) shvaćeno.


Taman mi ostaje "delete" da uradim da vidimo jesam li naucila nesto.



P.S. nije htelo da radi zbog 2x OsovinaID,

OsovID = Val(Me.txtID.Tag)
MojDatum = "#" & Format(Me.txtDatum.Tag, "mm-dd-yyyy") & "#"
"WHERE OsovinaID=" & OsovID & " AND Datum=" & MojDatum

Upomoc izonic,

Sve je funkcionisalo savrseno, i delete sam uspela srediti. Međutim, ukazala mi se potreba da promenim OsovinaID iz Autonumber u Text, pokušala sam ovako:




Ne radi i ne javlja nikakvu grešku. Jel može pomoć ne shvatam gde grešim?

Fali ti negde (ili ima visak) neki znak ' ili " ili &

Pokusao sam malo da sredim i formatiram tvoj kod. Sada bi trebalo da radi (nisam testirao, u obicnom editoru sam prepradio kod)

Imas primere kako se radi za datume i stringove.


Pitanje: zasto koristis Tag property? [code]OsovID = Me.txtID.Tag, Me.txtDatum.Tag[code]

:-)

Kada kliknem na neki zapis u subformi a zatim kliknem na Edit textbox-evi main forme se napune podacima iz selektovanog zapisa, tako mi je lepše a i sigurnije (nema direktnog unosa u bazu i tesko je slucajno pogresiti). Tag koristim da se zapamti primarykey u child tabeli (osovinaID i Datum) za slučaj da se greškom promeni datum ili id txtDatum txtStanje i ostali txtXxxx su unbound text i combo box preko kojih unosim podatke u tabelu.







U međuvremenu da prekratim sebi muke moram da pitam u vezi primary key-a.

Imam polja Broj i Godina (isti broj se može ponavljati u različitim godinama ali ne i u istoj), nezgodno mi je da bude kombinovani primary (stvara mi probleme sa relacijama kasnije), da li je bolje da koristim autonumber za ID polje ili je moguće da napravim da se ID dobija kombinovanjem broja i godine broj/godina? Ovo drugo bi mi bilo zgodnije ako je izvodljivo.



_{[Ovu poruku je menjao marija.ana dana 25.07.2014. u 23:36 GMT+1]}

Nije to tako komplikovano oko PK. Tvoja tabela Dnevnik u realnom sistemu ima nadređenu roditeljsku tabelu ali ti model verovatno nije dovoljno široko postavljen pa je ne vidiš. Ta roditeljska tabela je tabela RadneGodine sa zapisima (.....2011, 2012, 2013, 2014). Svaki zapis u tabeli Dnevnik je jednoznačno određen godinom i brojem u okviru nje od 1 do n. Prema tome kombinovani PK je preporučeno rešenje uz uvođenje pomenute tabele RadneGodine. Dobro postavljen PK smanjuje kasnije programiranje i olakšava održavanje aplikacije.
Bolje je da sad ispraviš model nego kasnije, kada ti većina formi i izveštaja bude napravljena.

Auuu, ovo je baš nizak udarac.

Moja tabela "Dnevnik" ima parent tabelu "Osovine" a model mi je postavljen taman onoliko široko koliko sam ja to htela. Tabela "RadneGodine" ne postoji niti će... Svaki zapis u tabeli Dnevnik određen je identifikacionim brojem osovine i datumom kada se promena desila (bar sam tako podesila ključ).

Moje pitanje (izgleda veoma nemušto postavljeno pošto niko nemože da ga razume) je glasilo:

Da li je izvodljivo da napravim formu za unos osovina gde će mi forma pri unosu broja i godine automatski sastavljati ID field u formatu broj/godina.




Da, pronađoh ovo al ne umem da zamenim "Registrator" sa "Osovina" i da izbacim "SifreRadnika", uvek na kraju neka greška.

Žao mi je ako sam te povredio. To mi nije bila namera.
Modeli se ne postavljaju “taman toliko koliko ja hoću“, već adekvatno realnom sistemu, a o njemu smo veoma malo saznali iz ove teme.
Iz tvog pitanja od pre 5 dana nije bilo jasno o kojoj tabeli se radi, pa sam zbog VBA koda u toj poruci zaključio da je to neka tabela dnevnik. Nebi bilo loše da kad postaviš pitanje uputiš link ka bazi, baš kao što si to uradila u tvom prethodnom postu.

Inače što se tiče odgovora na pitanje (broj + godina) i pravljenja govorećeg ključa, probaj da koristiš CStr funkciju za pretvaranje u tekst obe vrednosti ukoliko su brojčane, potom ampersend (&) za spajanje vrednosti, a možda i + ako nema navodnika i sve to recimo ponudiš na On Enter događaj tvom ključu u DefaultValue osbini.

Ovako nekako jer pišem napamet pa verovatno sintaksa nije dobra:


Me![TvojKljuc].DefaultValue = CStr(Me![Godina]) & CStr(Me!([Broj])


_{[Ovu poruku je menjao Getsbi dana 01.08.2014. u 06:15 GMT+1]}

Mozete li opisati problematiku, pa da se model postavi ispravno. Ostalo nece biti preveliki problem.

Iz postavljenog modela zakljucuje se da zelite pratiti promjene na nekim OSOVINAMA. O kakvim osovinama se radi? Sta je atribut BROJ u tabeli Osovine, da li je to serijski broj osovine? Da li je ovaj broj jedinstven za svaku osovinu? Sta je atribut GODINA? Da li je to godina proizvodnje osovine? Postoje li ogranicenja po pitanju ovog atributa, koja je minimalna a koja maksimalna godina koja se moze unijeti? Koliko TIP-ova osovina se moze pojaviti? Da li je to unaprijed odredjeno? Sta se upisuje u atribut NAPOMENA tabele OSOVINE? Pretpostavljam da u tabeli DNEVNIK pratite promjene koje su se desile na toj OSOVINI. Da li se u jednom danu mogu izvrsiti 2 i vise tih izmjena na nekoj Osovini? Opisite sta predstavljaju ostali atributi tabele Dnevnik( Stanje,Lokacija,Precnik i Izmjene), koje vrijednosti moze uzeti svaki od ovih atributa odn. postoje li ogranicenja po pitanju unosa u ove rubrike?

U pitanju su "Vagonske" osovine, atribut BROJ jeste serijski broj osovine (nije jedinstven jedan isti broj se može pojaviti u različitim godinama na pr. 10012 - 1987 i 10012 - 2012), "Godina" je godina proizvodnje. Osovina može biti stara maksimalno 40 godina. Tip je (ukratko) A ili B ne postoji drugi. Napomena su moja zapažanja nešto na šta treba obratiti pažnju.



U pravu ste, DNEVNIK prati stanje osovine i to stanje može biti: Zaliha, Ugrađena, Neispravna, Remont ili Škart. U jednom danu ne može biti dve promene stanja. Lokacija je mesto gde se trenutno nalazi. Ako je stanje "Neispravna" lokacija je "Neispravne" a u "Izmene" pišem kratak opis neispravnosti; za stanje "Zaliha" lokacija je isto "Zaliha" u "Izmene" pišem šta joj je popravljeno ako je došla sa remonta; za stanje "Škart" lokacija je isto "Škart" a u "Izmene" pišem šta je razlog otpisa. Ako je stanje "Remont", "Lokacija" je ime remontera a u "Izmene" ide šta se radi na njima. Ako je stanje "Vagon" "Lokacija" je broj mesta (broj mesta je jedinstven).

"Praćenje promene stanja" je otprilike idealan primer, samo što meni ne trebaju ograničenja koja su tamo postavljena (iz stanja u stanje). Moj plan je bio da krenem od "PracenjePromeneStanjaDex2+Z2" i da dodam polja "Lokacija", "Prečnik" i "Izmene". Htela sam da upotrebim i primer "povezani combo box-evi" sa ovog foruma i da se ponuđene vrednosti combo box-a "Lokacija" i "Izmene" respektivno menjaju u odnosu na izabrano stanje. Glavna prepreka u svemu mi je neznanje oko formata datuma i tipa podataka (ostalo nekako i naučim sa foruma ili Youtube).

Kao što to obično biva odgovori rađaju nova pitanja dok se stvari ne istjeraju na čistac.
-Da li je serijski broj osovine uvjek petocifren (10012)?

-Šta se dešava sa osovinama koje pune 41 godinu? Da li se zamjenjuju iako su ispravne, odnosno da li je ovo jedan od uslova za otpis?

-Da li se umjesto tipa A moze ugraditi tip B ili se ovi tipovi ne mogu mješati jedan sa drugim?

-Pojasnite malo ovaj atribut napomena. Za koga je u samom procesu bitno to što napišete. Dajte jedan primjer napomene.
U pravu ste da Vam prijer iz teme "Praćenje promjene stanja" adekvatan i za Vaš primjer uz male izmjene. Trebalo bi utvrditi koje je inicijalno stanje, a mislim da bi to bilo Ugrađena-Ugrađena.
-Da vidimo šta se dešava u raznim "stanjima"

"Zaliha" - Pretpostavljam da se stalno nabavljaju nove osovine koje će biti rezerva za one koje će biti otpisane. Uz njih u ovom stanju su i one osovine koje se vrate sa remonta. Da li sam u pravu?
-Gdje su smještene ove osovine, da li su sve na jednom mjestu-jednom magacinu. Da li je jedan rukovaoc- jedan odgovoran za sve ove osovine. Da li se u ovom procesu vrše još neke radnje ( na osnovu kojih se utvrđuje ispravnost pri prijemu u ovaj status)?
"Ugrađena" - Ovde jedna napomena - treba biti dosledan u imenovanju. U prvom dijelu teksta ste naveli status "Ugrađena",a kasnije u tekstu "Vagon". Ako se ovo desi u bazi teze se radi.

-Navedite primjer broja mjesta- primjer načina obilježavanja( Da li je to broj ili kombinacija slova i brojeva i šta označava)
"Neispravna"- Na osnovu čega se utvrđuje neispravnost, ko utvrđuje neispravnost? Šta se dešava kada se primjeti neispravnost- opišite ovaj proces.
"Remont" - Da li remont rade neke druge firme sa kojima imate ugovor ili neki sektor u Vašoj firmi. Šta prethodi remontu. Da li se na remont šalje samo osovina? Ako je tako ko skida osovinu sa vagona? Da li upućivanje na remont prate neki propratni papiri? Ako ima dobro bi bilo imati primjer tog papira.
"Škart" - Osovine koje se nađu u ovom statusu se otpisuju i više se ne mogu naći u ostalim statusima. Šta se dešava sa ovim osovinama, da li se negdje odlažu za rezervne dijelove ili se šalju u topionicu?
Niste dali opis atributa "PREČNIK". Pretpostavljam da se ova vrijednost u nekom procesu može mjenjati. U kom procesu se to dešava? O kakvom prečniku se radi, ko utvrđuje ovaj prečnik i na koji način.
Znam da Vam se čini previše pitanja, ali jedino na ovakav način može se doći do ispravnog modela.

Ne, ima šestocifrenih, dvocifrenih, sa jednom cifrom a ima i napisanih ovako "00040" pa pretpostavljam da mora da bude Text a ne Number

Da zamenjuju se svejedno, i to je jedan od glavnih uslova za otpis (uz neka teža oštećenja)

Svaka čast za ovo pitanje. Preporuka je da ispod jednog vagona uvek bude isti tip, ako se menja jedna mora da bude istog tipa ali ako se menjaju sve ne mora da bude istog tipa kao prethodna ali moraju sve da budu iste (to ne bi trebalo da bude uslov u bazi)

Napomena je nešto na šta moram da obratim pažnju u budučnosti i pišem je samoj sebi... na primer "Obrušen broj" ili "Ne poklapa se broj na čelu i na pločici" Vrednost polja napomena je jedina koju bih unosila ručno, sve ostale su tipske i mogu se spakovati u tabele.
Inicijalno stanje (ako mislite početno) ja mislim da bi trebalo da bude Zaliha (tu dolaze i nove i remontovane)

Apsolutno.

Sve na jednom mestu, jedan rukovaoc ne vrše se nikakve radnje ona kod mene stiže kao ispravna i ja je tako vodim dok majstor ne utvrdi neispravnost.

Pretpostavljam da onda stanje treba da bude "Vagon" a ne "Ugrađena"?

Broj mesta "000-1/2", "000-3/4", "000-5/6", "000-7/8"; trocifrena oznaka "000" je broj vagona a sledi pozicija, može biti 2,4 ili 8 pozicija po vagonu. Ja sam zamislila jednu tabelu sa tako upisanim pozicijama koja bi "hranila" combobox "Lokacija" ukoliko vrednost "Stanja" bude "Ugrađena".

U redovnom ili vanrednom pregledu, majstor utvrđuje neispravnost i onda to javlja meni, ja je šaljem na lokaciju "Neispravne" gde čeka red za slanje na remont. Red ja određujem u zavisnosti od više parametara (recimo približnog prečnika ili sličnog kvara)

Remont rade druge firme. Na remont šaljem ja samo osovinu. Osovinu skida majstor koji je utvrdio problem, i zatim meni šalje izveštaj (koju je skinuo i koju je stavio na njeno mesto). Upućivanje na remont prati jedna tabela u koju upisujem redom: godinu proizvodnje, serijski broj, tip, i opis kvara (polje izmene).

"Škart" se odlaže na lokaciju "Škart" (to je otpad, posle ide merenje i ja sa njima više nemam ništa, kad odu mogu ih izbrisati iz baze)

Prečnik se meri pri svakoj promeni stanja, pošto se stalno menja, prilikom eksploatacije ali i pri remontima ili oštećenjima, vrednost može biti od 900mm do 1000mm.

Pitanja nikad nije previše. Pitanja postavljena na ovakav način su me i naučila ponešto. Hvala.

p.s. nadam se da nisam ništa preskočila ili previdela.

Da rezimiramo ono što do sada znamo.
Zadatak baze koja se projektuje je praćenje promjene stanja za OSOVINE vagona.
Osovine imaju SERIJSKI BROJ (koji se nalazi na čelu osovine i na pločici. Ovi brojevi trebaju biti indentični. Može se desiti da se ovaj broj obrusi tj. da nedostaje) Serijski broj se može ponavljati u različitim godinama.
-Šta se dešava ukoliko nedostaje serijski broj? Da li se ukucava novi?
Osovine imaju godinu proizvodnje. Osovine mogu biti najveće dozvoljene starosti 40 godina. Ukoliko osovina prelazi ovu starosnu granicu mora se zamjeniti i na to bi nas sistem trebao upozoriti.
Ako sam ispravno shvatio ovo prethodno to znači da čak ni kombinacija SerijskiBroj-GodinaProizvodnje nije pouzdan Primarni ključ, ali svakako da bi mogao biti alternativni ključ tj. trebalo bi ovu kombinaciju indeksirati.
Osovina može biti tipa A ili B
Osovina ima prečnik koji može biti u rasponu od 900 do 1000 mm.
Osovine mogu biti u različitim statusima: "Zaliha","Vagon", "Neispravna", "Remont" ili "Škart".
Početni-inicijalni status svake osovine je "Zaliha"
Kada je u ovom statusu smatra se da je osovina ispravna i spremna za ugradnju u vagone. Poznat je njen prečnik i tip.
-Kada se osovina izda za ugradnju da li se odmah mijenja njen status iz statusa "Zaliha" u status "Vagon" i pri tome se konstatuje pozicija i ostalo ili se čeka izvještaj da je ugrađena i gdje je ugrađena. Da li ovo izdavanje osovine i slanje na ugradnju prati neki propratni papir? Da li se desi da se pri ugradnji osovine konstatuje da ona ustvari ima neki kvar odnosno da je neispravna.
Kada je u statusu "Vagon", znači da je u upotrebi- ugrađena je na neki vagon. Tada se obilježava kombinovanom oznakom "XXX-Y/Y" gdje je "XXX" brojčana (ne slovna) oznaka-broj vagona , a Y/Y pozicija na vagonu i može imati vrijednosti 1/2;3/4;5/6 i 7/8. Kada su na vagonu svaka osovina mora biti istog tipa A ili B. Ne mogu biti različitog tipa na jednom vagonu.
Ispravnost osovine se konstatuje u redovnim i vanrednim pregledima. Ove preglede vrše majstori.
Ukoliko se primjeti neispravnost majstor skida neispravnu osovinu i zamjenjuje je ispravnom. Da li je prethodno trebuje od vas ili je uzme pa vas poslije izvjesti, pomalo je nejasan ovaj proces.O izvršenoj zamjeni majstor dostavlja izvještaj. U ovom prcesu se vrši promjena statusa za dvije osovine- ona koja je skinuta prelazi iz statusa "Vagon" u status "Neispravna", a ona koja se postavlja prelazi iz statusa "Zaliha" u status "Vagon". Obe osovine moraju biti istog tipa osim ako se vrši izmjena svih osovina jednog vagona, ali tada sve postavljene osovine moraju biti istog tipa ( naravno i sve skinute su istog tipa).Da li se i pri ovim radovima mjeri prečnik? Šta sve piše u tom izvještaju (valjalo bi imati primjer tog izvještaja)? Da li je potrebno evidentirati i koji je majstor u pitanju?
Skinute osovine dobijaju status "Neispravna", i čekaju remont.
Na remont se osovine upućuju na osnovu sličnih karakteristika ( približne veličine prečnika ili sličnog kvara). Ovdje bi trebalo imati izvještaj koji bi se izlistao na osnovu upita.
Ako osovine već čekaju na remont, postoje li ovde neki kriterijumi. Da li čekate da se skupi više osovina da bi smanjili troškove transporta, da ne šaljete samo jednu osovinu nego kad se sakupi određeni broj ili šta?
Kada se ispune određeni uslovi za slanje na remont ove osovine prelaze iz statusa "Neispravne" u status "Remont". Slanje na remont prati propratni papir- tabela u koju se upisuje :godina proizvodnje, serijski broj, tip, i opis kvara. (Ovaj dio će se automatizovati i neće biti potrebe za pojedinačnim pisanjem )
Remont vrše druge firme. Da li ima više firmi kojima se šalju osovine na remont? Ako ima i njih bi trebalo evidentirati u bazi da bi znali gdje je koja osovina, kod kog remontera. Postoje li rokovi za koje vrijeme se mora odraditi remont? Da li se desi da se osovina vrati sa nemogućnošću remonta. Dobijate li izvještaj šta je odrađeno na osovini?
Kada se konstatuje neispravnost koja se ne može remontovati osovina dobija status "Škart" , odlaže se na otpad i vrši se njeno mjerenje. Nakon statusa "Škart" osovina ne može dobiti drugi status.
Da li sam nešto propustio što smatrate da je bitno pomenuti?

Serijski broj se ponekad ponavlja u različitim godinama (retko). To oko polja "Napomena" su sve nebitne informacije za stanje osovine (bitne su samo meni, ne menjaju stanje rade se u hodu).

Moglo bi upozorenje da je nastupila godina u kojoj osovina mora biti zamenjena, ali i ne mora.

Kombinacija SerijskiBroj-GodinaProizvodnje jeste pouzdan ključ ne postoji dve iste kombinacije. Retki su slučajevi da je isti broj a različita godina.

Da.

Sve je to posao majstora ja dobijam izveštaj (osovina broj XXX skinuta sa mesta A i njeno stanje je sada neispravna, na isto to mesto ugradjena je osovina YYY. (od tih neispravnih kasnije ja biram koje idu na remont)

Da. Taj redovni pregled se radi isto kod remontera i planirala sam da isto uzima stanje "Remont" pošto ima isti status kao i popravljane neispravne. Ponovo ste postavili izvanredno pitanje... Poslednji osovina mora ići na pregled svake 4 godine (Remont ima isti status kao i pregled).

Majstor sve radi sam, primeti, uzme, zameni, a mene samo izveštava (opisala sam u prethodnom redu kako).

Nekad se čeka da se nakupi, tada šaljem sve što imam. Nekad je remonter pretrpan poslom pa se nakupi puno neispravnih, tad biram da bude sličan kvar. Nekad mi majstor preporuči koje bih trebala poslati.

Ima više firmi koje remontuju, planirala sam da u lokacija upisujem ime remontera. Sve što je potrebno za svako stanje može se upisati u tri polja Stanje Lokacija i Izmene. Recimo:
Neispravna, Neisprave, Precnik, OpisNeispravnosti
Zaliha, Zaliha, Precnik, (prazno polje izmene)
Vagon, brojmesta, Precnik, (prazno polje izmene)
Remont, SifraRemontera, Precnik, sta je uradjeno (u ovom slučaju bi polje izmene i precnik bilo upisano po povratku sa remonta kada dobijam izveštaj t.j. tabelu "serijskibroj, godinaproizvodnje, tip, vrsta uradjenog remonta" )
To sam sve isplanirala uraditi pomoću kaskadnih kombo bokseva (after update Stanje). Za Neispravnost, Remontere, Broj mesta i vrstu uradjenog remonta sam planirala posebne tabele,
Rokovi ne postoje, može se desiti da se ne može popraviti i da se sa remonta vrati kao škart.

Škart je finalni status, posle toga može biti samo obrisana iz baze


Ništa niste propustili, naprotiv.

Da postavimo prvi predlog modela. Ovde bih zamolio Zorana i Zidara za mišljenje da li bi predloženi model mogao da prati opisani realni sistem, a da se ipak upotrebi Zidarev primjer iz teme "Praćenje promjene stanja"? Trenutno samo slike.
ps. Zaboravio sam da dodam i pomoćnu tabelu VrstaRemonta koja je neidentifikujućom vezom kao nadređena vezana za tabelu Remont.

_{[Ovu poruku je menjao nenadmarkoni dana 01.08.2014. u 23:32 GMT+1]}

Ponudjeni modeli su OK, dopunio si osnovni model dodatnim tabelama za cuvanje dodatnih podataka, jako lepa ideja, bravo.

Ima samo jedan previd. Modeli su u stvari isti, iako su zamisljeni kao razliciti. Jedan kao predstavlja specijalizaciju (broj 2), a drugi generalizaciju (broj 1), a u stvari su oba specijalizacija. (Hm, ovo je kao Petar petru Plete petlju...)

Oba modela omogucuju da se za svako novo stanje unesu dodatni podaci u odgovarajuce dodatne tabele (deca tabele PracenjePromenaStanja). Recimo, za stanje 'Vagon' lepo je znati i koji vagon, u kojoj kompoziciji, na kojoj poziciji. Slicno za remont, koji majstor je uradio remont, broj radnog naloga i slicno.

Kad je speciajalizacija u pitanju, dodatni podatak se moze poslati bilo koju tabelu. Kod generalizacije, podatak se mora poslati u tacno odredjenu tabelu. Oba modela dozvoljavaju da se dodatni podatak unese u bilo koju dodatnu tabelu. Kako? Pa nista nas ne sprecava da kas stanje predje u 'Vagon' mi unesemo podatak u 'Remont'. Ili u bilo koju drugu dodatnu tabelu. U stvari, mozemo uneti isti podatak u sve dodatne tabele odjednom. Oba modela to dozvoljavaju, prema tome isti su, bez obzira na razlicite simbole na cvoru odakle se granaju childeren tabele. Probaj pa ces se uveriti i sam.

Sta treba da uradimo da bismo garantovali da se dodatni podaci o svakom novom stanju upisu u tacnu tabelu? Evo sta:
Umesto da iz roditelj tabele PracenjePromenaStanja u 'children' tabele prenesemo PK ( SerijskiBrojOsovine, Godina, TrenutakPrelaza ), prenesimo Super Key (SerijskiBrojOsovine, Godina, TrenutakPrelaza, NovoStanje ). Ovo naravno zahteva da se u children tabelama doda kolona 'NovoStanje', kao i dfa se u roditelj tabli definise Super key. Onda se zada da u svakoj child tabeli kolona Novo Stanje mora imati konstantnu vrednost - koja odgovara onom stanju za koga skupljamo dodatne podatke. Na primer:


Izgleda neobicno, ali u sustini nema nicega sto je zabranjeno u teoriji. PK ima u child tabelama manje kolona od FK - nigde ne pise da ne sme tako. Koristimo Super Key tebele roditelj umesto PK, da bi napravili vezu sa children tabelama. Takodje nije zabranjeno... Glavni stos je uvodjenej CHECK ogranicenja (Validation Rule za kolonu u Accessu). CHECK zahteva da kolona NovoSTanje bude konstantna i da se samo takve (NovoStanje = const = 'Zaliha' na primer) promene stanja mogu uneti u child tabele. E, kad dodamo extra kolonu u child tabelu, i vezemo je za Super kljuc u roditelj tabeli, onda imamo genralizaciju. Jeste, children tabele su denormalizovane, imaju redundatan podatak, NovoStanje, pa jos konstantna vrednost. Jeste, ali bez toga ne bismo mogli da garantujemo vazno ogranicenje. A kako onda svi kazu 'treba normalizovati do Byce-Codd Normalne Forme (BCNF)'? To vazi za staticke podatke. Ako se prate promene bilo cega, onda nije moguce dostici BCNF a da se ne zanemare vazna ogranicenja.

Medjutim, mislim da je ovo prekomplikovano za postavljaca pitanja. Poceli smo od toga kako se puni i prazni nevezana forma, a dodjosmo do modela baze.

Ko hoce da se bavi naprednim naucnim radom, evo zanimacije:
Kako na primer garantovati da u istoj kompoziciji, u istom danu, na vagonu 7 ne budu dve razlicite osovine na prednjem kraju? Ili da se ogranici da kompozicija ne moze imati vise od N vagona u datom mementu. Ja ne znam tacno kako bi se to izvelo, ali vredi eksperimentisati, ako neko ima vremena.



P.S. nece me biti do sledece srede na forumu.

Zahvaljujem @Zidar-u. Izvinjavam se ako sam unio zabunu, naime na obje slike je isti model samo prikazan na logičkom i na fizičkom nivou baš zbog diskriminatora u čvoru (na fizičkom nivou se ne vidi naziv diskriminatora). Znači ne radi se o dva različita modela.

He,he.. Prekomplikovano je ovo i za mene, ali imamo primjer u temi "Praćenje promene stanja" pa ćemo zajedno pokušati nešta da uradimo (ne garantujem).
Zamisao funkcionisanja je da na formi koja će prikazivati podatke osovine postavimo 5 komandnih dugmadi za promjenu stanja, koja će biti omogućena ili onemogućena u zavisnosti od dozvoljenih promjena stanja, a koja bi otvarala specijalizovane forme za unos dodatnih podataka. Podaci koji su predefinisani i garantuju tačnost bi se u pozadini dodavali automatski kodom pri otvaranju specijalizovane forme. Ostaje da osmislimo kako da osovine koje su u statusu "Vagon" budu istog tipa pri montaži kao i ostale na tom vagonu, tj. ako se mijenjaju sve da sve budu istog tipa.
@marija.ana I ja sam, može se reći, početnik pa ne garantujem da ćemo ovo istjerati do kraja, ali igramo se pa šta uradimo

Otisli ste predaleko, teško mi je i da pročitam.



Ja to zamislila ovako:

Stanje Lokacija
Vagon, 000-1/2
Ovaj izraz mi govori sve, i broj vagona i mesto na vagonu.

Ja Vas teško razumem, volela bih da mi neko kaže da li je izvodljivo sve to pisati u tabelu DNEVNIK (u ovom slucaju PracenjePromeneStanja) onako kako sam ja zamislila (sve u tri polja Stanje, Lokacija, Izmene).

Recimo ako odaberem Neispravna, pomocu after update polja Stanje ako je Stanje Neispravna da mi u polje lokacija upise Neispravne i da combobox Izmene "hrani" sa tabelom Neispravnost (gde bih čuvala opise neispravnosti).

Ako odaberem Vagon, after update polja Stanje ako je Stanje Vagon da mi combobox Lokacija hrani sa tabelom Vagoni gde bi bile upisane pozicije u formatu XXX-y/z gde je XXX broj vagona a y/z pozicija osovine.

Podatke o majstoru koji je uradio remont nemam. Nema ni broja radnog naloga. To se sve radi u drugoj firmi. Imam samo ko je zamenio osovinu i broj radnog lista.


Posatavljač pitamnja se (u čudu) češka po glavi...

@marija.ana Ne brinite, za sada se cini prekomplikovano ali kako bude odmicalo trebalo bi da se sve više razjašnjava. Rekao sam igramo se pa gdje stignemo, a trebalo bi da ispadne dobro.

Niste do kraja dobro opisali ovaj proces. Uz remontovanu-popravljenu osovinu dobijate radni list na kojem je broj radnog lista, vrsta rada i ime(potpis) majstora. Je li tako? U kojem je formatu broj radnog lista.
Evo doradjen BE baze, s tim što treba unijeti izmjenu prema gore napisanom kad to razjasnimo.

Ovako.

Ošteti se osovina. Majstor je skine i zameni. Meni pošalje "dnevni list izgradnje". Trenurno ih nemam kod sebe ali mogu skenirati u ponedeljak. Pokušaću da je opišem.

Majstor sam skida osovinu sam uzima drugu, menja je a zatim u dnevni list upisuje broj lista i datum, zatim popunjava kolone sa podacima i potpisuje se na dnu lista.
Prvo idu kolone sa podacima o izgrađenoj osovini. Broj osovine, godiste, tip, razlog izgradnje, zatim idu kolone koje se odnose na ugrađenu Broj osovine, godiste, tip, a zatim idu kolone koje ja popunjavam Remonter i Datum poslednjeg remonta ili pregleda.


Kada se steknu uslovi za slanje na remont, ja određujem koje osovine se šalju (uzimajući u obzir vrstu kvara i prečnik) i popunjavam tabelu sa kolonama:

Broj osovine, godiste, tip, zahtevani radovi,

Kada se osovina vrati dobijam otpremnicu. Otpremnica je tabela koja ima broj datum i kolone:

Broj osovine, godiste, tip, vrsta opravke.


Moje je još i da pazim da se ne koristi starija od 40 god, i da proteklo vreme od poslednjeg remonta ne sme biti veće od 4 godine.

To je sve otprilike.

Dobro, doradjen je model i mislim da ce sada ispunjavati i taj poslednji zahtjev, ali svakako skenirajte dokumente koji se javljaju u sistemu. Pri modeliranju baze oni su jedna od karika i iz njih se takođe uzimaju podaci potrebni za pravilno postavljanje-modeliranje baze. Ponudjeni model bi trebao, uz dodatna ograničenja, da garantuje pravilno pracenje promjene stanja osovine. Ograničenja od maksimum 40 godina starosti i 4 godine od poslednjeg remonta, bar koliko ja mislim, neće se moći postići samim modelom i ograničenjima nad tabelama već se moraju ograničiti kodom. Pogledajte malo relacije i tabele pa ako nema daljih primjedbi da lagano krenemo na FE baze.

Mada malo zurimo evo prvih radova na FE baze. Tabele je trenutno potrebno ručno prelinkovati na BE baze( tamo gdje ste raspakovali BE). Kasnije ćemo napraviti linker koji će to raditi umjesto nas. Znači potrebno je prelinkovati sve tabele osim tblErrorLog. Ona se ne nalazi tamo gdje su ostale tabele već je u sastavu FE baze. Zbog lakšeg dodavanja Error Handler-a ja koristim MZTools for VBA koji se besplatno nudi na internetu i pomoću kog jednim klikom možemo u svakoj proceduri dodati kod za 'hvatanje' runtime grešaka. Greške se pomoću njega upisuju u pomenutu ErrorLog tabelu. Dodata je i forma pomoću koje se provjerava funkcionisanje samog Error Handlera i pregled pomenute tabele.Sve ovo je skinuto ovde sa foruma i djelo je forumaša. Trebalo bi da je neko pravilo (makar sam ja to tako shvatio) da se najprije izrađuju forme za pomoćne tabele- šifarnike. Te tabele su na našem modelu : Stanje, DozvoljenePromeneStanja,Kola,Godina,Tip,Neispravnost,RadniList,Majstor,Remonter i VrstaRemonta. Za tabelu Godina omogući ćemo da se sama popunjava kada se u sistemskom datumu pojavi nova godina. Ovo ćemo omogućiti pomoću dva Macro-a, jednog akcionog Query-a(Upita) - QGodinaDodaj. U formama koje imaju za ključ ID umjesto AutoNumber polja postavili smo Number polje, i u pozadini pomoću jednog sakrivenog polja na formi - Broj i koda u pozadini omogućili programski AutoNumber koji radi pouzdanije od onog koji se nudi u samom Access-u. Sada bi trebalo da unesete u ove forme ispravne podatke da bi mogli dalje da radimo...
Kada to uradite zakačite popunjen BE baze ovde.

OsovineBE je super. Kada otvorim OsovineFE1 dobijem "c:\Dosuments and Settings\Nenad\Desktop\Osovine\2003\OsovineBE.mdb oa not a valid path." Mogu li da ispravim path nekako, ili moram formirati ovakav kao Vaš?

Otvorite FE baze, i izaberete Tools->Database Utilities->Linked Table Manager. Kliknete na Select All i čekirate Alweys prompt for new location. Zatim u prozoru koji se otvori nadjete lokaciju gdje ste raspakovali BE baze i prelinkujete.

Evo Dnevnog lista izgradnje (papir koji dobijam kad majstor skine osovinu)
i Pregleda Osovinskih sklopova za opravku (papir koji ja šaljem uz osovine na remont)
Evo i popunjene baze OsovineBE. Nisam stigla sve podatke uneti (bilo nekih grešaka koje moram na terenu proveravati).


Jedno pitanje:
Osovine treba da imaju svou napomenu (napomena koja ih prati ceo radni vek), zar to ne bi trebalo da bude u tabeli osovine?

Ovde sada pored radnog lista imamo jos 2 dokumenta. Prvi povezuje tabele Neispravne i Remont, a drugi Remont i Zaliha. Koliko sam vidio u njima postoje polja koja niste pomenuli a koja bi takodje trebala biti u bazi. Postoji li neki dokument i kada osovina odlazi u Skart? Da li dokument koji prati slanje na remont ima neki broj pod kojim se zavodi? Da li se po istom broju osovine i vracaju sa remonta? Trebalo bi opisati sve rubrike dokumenata i navestivrijednosti (opseg vrijednosti) koje se mogu unijeti u te rubrike . Trenutno nisam uz racunar

Ne postoji dokument kada osovina odlazi u škart.
Nema broj dokumenta. Kada pošaljem na primer 14 osovina na remont, moguće je da mi se vrati samo na pr. 4 a ostale da ostanu kod remontera dok se ne nadju delovi pa da se vrate sa nekom grupom.

Dokument "Pregled" ima polja koja se ne popunjavaju (to je dokument za velike železničke vagone).
Za tabelu "Pregled" ja popunjavam: godinu proizvodnje, broj NN, ono "monoblok" ili "sa bandaž." su tipovi A i B, Precnik kruga kotrljanja je onaj "moj" precnik, osiguranje ležaja se takođe odnosi na neki drugi tip osovina (ni to ne popunjavam). Tabela ispod služi da je remonter popuni po završenom poslu: popunjavaju samo "Godinu proizv" "Broj NN", prečnik, i izvršene zamene.

Tabela "Pregled" mi dolazi zajedno sa osovinama. I obično je kopija (pošto je moguće da mi poslate osovine vrate iz nekoliko puta u podužem vremenskom razmaku). Potvrda da su mi se osovina vratile je "Otpremnica" (papir na kome su rukopisom napisani brojevi osovina koje su mi poslate).

Možete li skenirati i jednu Otpremnicu ako nije problem. Uvid u dokumente koji se javljaju u sistemu je, kao što sam rekao, važan dio projektovanja baze. Ne samo što nam govori koja polja su nam potrebna i koji tip polja da izaberemo, već bi i izgled forme trebao da prati izgled dokumenta ukoliko je to moguće. Izvještaji koji su izlazni dokumenti iz sistema su upravo ti dokumenti( kako izgledom tako i sadržajem).
Pri izradi aplikacije trebalo bi da vodimo računa da funkcionisanje aplikacije prati radne procese koji se javljaju u sistemu, a ne da im kontrira. U opisanom sistemu otprilike identifikuje se nekoliko radnih procesa:
-Evidentiranje osovine ( u ovom procesu se unose podaci o osovini u sistem, pri čemu osovina dobija inicijalni status 'Zaliha'. Obzirom da se osovine koje treba unijeti u sistem realno nalaze u drugim statusima ovde bi trebalo iz inicijalnog statusa omogućiti njihovo prebacivanje na statuse iz realnog sistema)
-Izgradnja/Ugradnja ( u ovom procesu majstor skida neispravnu osovinu koja iz statusa 'Vagon' prelazi u status 'Neispravna', a na njeno mjesto postavlja drugu koja iz statusa 'Zaliha' prelazi u status 'Vagon' vodeći računa da na istom broju vagona budu osovine istog tipa. Popunjava "Dnevni list izgradnje" , koji ima svoj broj, potpisuje ga i dostavlja ga Vama, a Vi na osnovu njega unosite podatke u aplikaciju.)
-Upućivanje osovina na remont ( u ovom procesu iz spiska osovina koje su u statusu 'Neispravna', a na osnovu priblizne velicine precnika ili sličnosti u opisu kvara Vi birate osovine koje će biti upućene na remont. Izabrane osovine se upisuju u "Pregled osovinskih sklopova za opravku", i šalju se na remont. Pri ovom procesu izabrane osovine prelaze iz statusa 'Neispravne' u status 'Remont')
-Prijem osovina sa remonta ( u ovom procesu osovine koje su u statusu 'Remont' prelaze u status 'Zaliha'. Na osnovu dokumenta "Pregled popravljenih osovinskih sklopova" unose se nove vrijednosti prečnika osovine i podaci o izvršenim zamjenama-rekonstrukcijama na osovini. Dokumentom "Otpremnica" razdužuje se dokument "Pregled osovinskih sklopova za opravku" te služi kao potvrda da su sve upućene osovine sa tog dokumenta vraćene.[Tako sam razumio. Da li je tako?])u
-Otpis osovina ( u ovom procesu osovine iz statusa 'Neispravne' prelaze u status 'Skart'. [Nije do kraja razjašnjen ovaj proces. Jedino što znamo je da se osovine vagaju.] Osovine iz statusa 'Skart' ne mogu preći u druga stanja.)

Iz ovoga naslućuje se kako otprilike treba da izgleda i funkcioniše aplikacija koju treba izraditi.

Sad sam pogledao podatke koje ste unijeli i nisu mi baš jasni podaci u tabeli "Dozvoljene promene stanja". Naveli ste:
IzStanja UStanje
Neispravna Remont
Neispravna Skart
Remont Skart
Remont Vagon
Remont Zaliha
Vagon Neispravna
Vagon Remont
Vagon Skart
Vagon Vagon
Vagon Zaliha
Zaliha Neispravna
Zaliha Remont
Zaliha Skart
Zaliha Vagon

Nisu mi jasne promjene : Remont-Vagon,Vagon-Remont,Vagon-Skart,Vagon-Vagon, Vagon-Zaliha, Zaliha-Neispravna,Zaliha-Remont, Zaliha-Skart.

Ako su zaista ove promjene dozvoljene onda sistem ne funkcioniše onako kako sam napisao u gornjem postu.??? :-/

Remont-Vagon i Vagon-Remont, Osovine nekada idu na remont sa sve vagonom, nisam znala kako to da opišem uslovom.
Vagon-Škart - Pretpostavila sam da se može desiti tako velika havarija da osovina sa vagona ode pravo u škart a ne u neispravne.
Vagon - Vagon i Vagon - Zaliha, ponekad se desi da se ne oštete sve osovine (sa jednog vagona) odjednom, tj oštete se na primer 3 a jedna ostane ispravna precnika 920mm. Ako u tom trenutku na Zalihama nema osovine sličnog precnika već na primer samo osovine precnika veceg od 950mm, ispravna osovina se odlaže na zalihe, kao razlog za njenu izgradnju se navodi "uklapanje". Ako se oštećenje desilo na osovinama dva vagona, a oštete se recimo 3 osovine na prvom i 1 na drugom vagonu, i ako su približnog prečnika može se desiti da se osovina sa prvog vagona prebaci na drugi a da se na prvi ugrade 4 sa zalihe.
Zaliha - Remont, Moja je pretpostavka da se može desiti da nekoj osovini na zalihama istekne 4 godine od remonta i da mora da se uputi na novi remont.
Zaliha - Skart - opet pretpostavka da na osovina zalihama može da zatekne 40. godinu
Zaliha - Remont - opet moja pretpostavka "sta ako se desi da neko osteti osovinu na zalihama?"



Sistem funkcionise tačno onako kako ste Vi opisali u postu iznad. Otpremnicu ću sutra skenirati.

UH!!!! Priznajem, sva mišljenja su ispravna, samo je pitanje kako sve ovo uklopiti u funkcionisanje buduće aplikacije. A i ovoliki broj dozvoljenih stanja povećava mogućnost greške. Pokušaćemo!

Evo i Otpremnice, ne vidi se najbolje.
U prvom redu piše: "Zamena bandaža na" pa su u sledećem redu brojevi tri osovine na kojima je to urađeno
U sledećem: Obrada profila točka, pa zatim brojevi osovina na kojima je to rađeno.


U zadnja dva reda piše broj reversa i datum (podaci nebitni za mene).

Broj 24949 je broj ugovora koji ste sklopili sa tom firmom da vrsi opravke, nije broj porudzbine-Pregleda osovina za popravku? Je li tako?Broj osovina koje su opisane u otpremnici odgovara broju osovina koje su upucene po jednom dokumentu "Popis osovinskih sklopova za popravku?

Da

Ne mora da znači. Može da se desi da ja pošaljem u januaru brojeve 1, 2, 3, 4, 5 i 6 u februaru 7, 8, 9, 10, 11, 12 pa mi oni u martu vrate 1, 2, 3, 7, 9, 12. Nema nekog pravila. Možda bi i bilo da nije kako jeste (štrajkovi, restrukturiranje, nestašice delova, nemanje novca...)

Uh,uh...sve zamršenije, ali tako to obično ide, krene se sa prostim zahtjevom pa kad krene da se rasplice....
Moramo još malo da rasplićemo.

Da li u tom slučaju uz vraćene osovine dobijate dvije kopije "Pregled popravljenih osovinskih sklopova" od januara(za osovine 1,2,3) i februara(7,9,12) i jednu Otpremnicu (1,2,3,7,9,12)

Da sistem zaista funkcioniše samo po pravilima koja sam opisao napravili bi forme koje u sustini izgledaju slično dokumentima koje dobijate i pratile bi te radne procese, ali ovako ćemo morati još malo da razmislimo i da to prilagodimo dozvoljenim stanjima koje ste naveli, ukoliko to budemo u stanju.
U suštini najlakše bi bilo napraviti formu iz koje bi se mjenjala sva stanja ali to ne bi pratilo radne procese i bilo bi Vam naporno u tome raditi. ( to će biti krajnje rješenje ukoliko ne uspijemo ništa drugo)
Da malo prokomentarišemo sva stanja koja ste naveli i da o njima postavimo dodatna pitanja.
Neispravna -Remont Ovo je prirodan prelaz stanja.Kako bi forma trebala da funkcioniše: Iz osovina koje su u statusu 'Neispravne' izaberete osovine koje ćete slati na remont.Pri tome u formi birate Remontera, a za osovine upisujete ili birate predefinisane (ako je to moguće slično kao i Neispravnosti) zahtjevane radove. Njihov status se promjeni u status 'Remont' i upišu se kao takve na Report-Dokument koji odštampate i pošaljete uz osovine.
Neispravna-Škart I ovo je prirodan prelaz.Ovo znači da je osovina skinuta sa vagona sa takvom neispravnosti koja vodi otpisu osovine. Pitanje je koja je to neispravnost koja bi vodila otpisu osovine. Da li je samo starost od 40 godina i prečnik ispod 900 mm usov za otpis ili postoji Neispravnost koju niste upisali u tabelu Neispravnost a koja bi vodila otpisu? Kako bi trebala izgledati forma zavisi od toga koliko se često dešavaju otpisi?
Remont-Škart Ovde bi trebalo da se radi o osovini kojoj neispravnost nije prepoznata kao takva da bi vodila otpisu pa je poslata na remont. I ovde je pitanje koje je to oštećenje, i kada sa remonta vrate ovakvu osovinu i nju evidentiraju kroz Otpremnicu. Šta u tom slučaju napišu? Otpremnice bi trebale da su dokument koji veže 'Remont' i 'Zaliha' i forma bi trebala da se odradi prema tome, međutim ovakav slučaj remeti to, pa je i ovde pitanje koliko često se dešava ovako nešto?
Remont-Vagon i Vagon-Remont Slučaj kada 4 osovine koje su na vagonu, skupa sa vagonom odlaze na remont. Da li i kako majstor u ovom slučaju popunjava "Dnevni izvještaj"? Da li i ovakav slučaj čeka da ga Vi odaberete i pošaljete na remont? Kako u ovom slučaju popunjavate "Pregled osovinskih sklopova za remont"? Da li se ovakve osovine vraćaju kroz jednu otpremnicu sve skupa i na vagonu sa kojim su poslate?Koliko često se dešava ovakav slučaj? Od odgovora zavisi da li se i ovaj slučaj može uklopiti u normalan proces: Vagon-Neispravne-Remont-Zaliha-Vagon i na koji način ovo rješiti.
Remont-Zaliha i Vagon -Neispravna Prirodan prelaz i uklapa se u zamišljeno funkcionisanje formi. Remont-Zaliha je vezan dokumentom Otpremnica i Pregled popravljenih OS, a Vagon - Neispravna Dnevnim izvještajem u dijelu Izgrađene osovine.
Vagon-Škart Ovde se radi o osovini koja je skinuta sa vagona ali je u takvom stanju da se mora otpisati. Da li u ovom slučaju majstor popunjava "Dnevni izvještaj". Šta u tom slučaju navodi- koja je to neispravnost koja vodi otpisu? Mislim da se i ovaj slučaj se možda može uklopiti u proces: Vagon-Neispravna-Škart
Vagon-Vagon Komplikovan slučaj. Ovde se sa jednog vagona izgrađuje a na drugi ugrađuje osovina. Na Dnevnom izvještaju majstor upisuje ovu osovinu na dva mjesta, kao izgrađenu pa opet kao ugrađenu.
Vagon-Zaliha Slučaj kada se ispravna osovina izgrađuje iz vagona, a kao Neispravnost se navodi "Uklapanje".
Zaliha-Neispravna i Zaliha-Remont Pretpostavka da se na Zalihama osovini desi neispravnost ili istekne 4 godine od poslednjeg remonta. I ako se ovo desi pretpostavljam da se evidentira kao neispravna(Neispravnost-istekle 4 godine ili neka druga neispravnost iz liste). Takođe čeka na odobrenje za remont i šalje se kroz Pregled tako da direktan prelaz Zaliha-Remont možda i ne treba?
Zaliha-Škart Pretpostavka da osovini na Zalihama istekne rok od 40 godina.
Zaliha-Vagon Prirodan prelaz.

Sad glavno pitanje. Da li sistem uglavnom funkcioniše onako kako sam ja opisao:
Evidentiranje osovine prema stvarnom statusu - Vagon - Neispravna - Remont ili Otpis - Zaliha(ako je prethodno Remont), a navedeni Prelazi su rijetki izuzeci, ili su ovi ostali slučajevi česti?
Ako ovi slučajevi nisu toliko česti da pravimo forme koje prate ovaj proces, a da za ove druge slučajeve pravimo posebne forme. Ako su česti ne znam koliko nam sve to vrijedi.

Da

Da, tačno ovako. Mali problem su i te predefinisane stavke (zahtevani radovi, neispravnost...) ima ih još sa kojima se nisam srela, nema ih negde napisanih gde bih mogla pročitati, a majstori su priča za sebe... Vole da mi pričaju sve (sem ono što ih pitam).

Otpisi se dešavaju veoma retko. Sem godišta razlog može biti: "Kriv trupac" i "Oštećen rukavac". Prečnik nije razlog za otpis (obrađuje se).

I ovo se veoma retko dešava. "Kriv trupac" i "Oštećen rukavac" su oštećenja koja se nekada mogu prepoznati golim okom a nekada prođu neprimećene, ali to kasnije otkrije remonter.

Vagoni imaju svoje "revizije" koje se rade svake 4 godine, kada se na reviziju pošalje ceo vagon, ako je potrebno remonter radi i reviziju osovine "Revizija sa obradom" ja dobijem samo tabelu sa brojevima osovine i datumom revizije (pošto se na svima isto radi), nemam ni jednu kod sebe, nisu tipske nema prčat nema ništa... nekad odštampaju kompjuterom, nekad je formular firme koja to radi. Ovo je slučaj koji ja još nisam srela. Iz priče sa majstorima znam da se može desiti da tako ide 2-3 vagona godišnje.

Dnevni izveštaj se popunjava za svako skivanje osovine. Pretpostavljam da je ovo moja greška u razumevanju materije i da je ovo lakše opisati kako ste Vi naveli "Vagon-Neispravna-Škart"

Ovo se nije desilo nikad, verovatno da je moja greška. Pretpostavljam i da nije po zakonu. Ako je osovina ispravna skinuta sa vagona ide na zalihu, kao razlog izgradnje se navodi Uklapanje.

Da

Ponovo ste u pravu.



Tačno kako ste Vi to opisali. Sporni prelazi su veoma retki izuzetci.

_{[Ovu poruku je menjao marija.ana dana 06.08.2014. u 14:19 GMT+1]}

Prema onome što ste opisali dokument "Pregled popravljenih osovinskih sklopova" odgovara dokumentu iznad njega "Pregled osovinskih sklopova za opravku i rekonstrukciju" tako da ga nema potrebe ponavljati i evidentirati. Vama je u suštini važna "Otpremnica". Pretpostavio sam da u opisu neispravnosti, zahtjevanim radovima i izvršenim radovima po jednoj osovini može biti više stavki pa sam tako postavio i model. Dokumentu "Pregled osovina za remont", upućenu jednom remonteru, odgovara jedna ili više otpremnica od istog remontera. Razlog otpisa po jednoj osovini uglavnom je jedan i to nije toliko važna stavka pretpostavljam. Pa evo izmjenjenog modela i opet bih zamolio za mišljenje stručnjaka sa ovog foruma, ako je moguće.

Iako nemamo misljenje iskusnijih kolega trebalo bi da je model ispravno [email protected] pokusajte doraditi BE prema prilozenoj slici, a na osnovu prethodne BE baze.ps. Da bi raskinuli postojece relacije i formirali nove moracete mozda isprazniti postojece unose iz nekih tabela. Na datoj slici hvali tabela Tip koju sam zaboravio unijeti u model, i atribut BrStanja u tabeli stanje (vidjecemo kasnije da li ce nam ovaj atribut trebati)

Prvo se uplaših "da li ću moći". Mislim da nije bilo problema...

Dodatno pitanje. Da li bi sada (bez dodatnih komplikacija), mogla da se ubace i polja PunNaziv, Adresa, LiceZaKontakt i TelefonLicaZaKontakt u tabelu Remonter? Kad već ima sveee



_{[Ovu poruku je menjao marija.ana dana 07.08.2014. u 14:11 GMT+1]}

Ne vidim nista specijalno lose, izgleda OK, verzija od 6 Aug 2014. Kako rekoh, resenje sa generalizacijom - posebnim tabelama za razlicite vrste stanja, izgleda obecavajuce. Bice puno posla za front end. Ugrubo, broj tabela puta dva daje broj potrebnih formi i kverija. Preporucujem da se FE uradi na najjednoistavniji moguci nacin -zaboravite na unbound forme i tako ustedite sebi vreme za pisanje rutina 'podaci u formu'-'podaci iz forme'.

Srecno

Moglo bi prosto da se ubace 4 polja tipa text u tabelu Remonter, ali ako želite da se to uradi po pravilima relacione baze to bi izgledalo ovako kao na prikačenoj slici.
@Zidar- Zahvaljujem. Potrudićemo se pa šta uradimo, a ako zakoči valjda će neko priskočiti u pomoć.

Mijenjamo li?

_{[Ovu poruku je menjao nenadmarkoni dana 07.08.2014. u 17:10 GMT+1]}

Samo PuniNaziv i Adresa. Ne shvatam relaciju između FizickoLice, KontaktLice i Majstor (a i bojim se da je to jos jedna komplikacija). Jel FizickoLiceID jedan prema jedan sa MajstorID i KontaktLiceID?

_{[Ovu poruku je menjao marija.ana dana 07.08.2014. u 19:04 GMT+1]}

U postupku projektovanja baze radi se takozvana Normalizacija (1,2,3 normalna forma), a jedna od njenih funkcija je da se izbjegne redudantnost-ponavljanje podataka. Ako bismo postavili text polje KontaktLice u suštini mogli bi u njega upisati Ime i prezime kontakt lica, ali u tabeli Majstor takođe imamo neko lice sa imenom i prezimenom. Ko garantuje da sjutra neki Majstor neće biti KontaktLice a tada bi ponavljali podatak. Šta ako se promjeni KontaktLice? U ovom primjeru to možda i nije bitno, to Vam je možda čisto informativni podatak, ali šta da je to podatak koji nam treba u nekim dokumentima?
Tako je, odnos je jedan prema nula ili jedan.
Postavljene relacije dozvoljavaju da jedan majstor bude na više dokumenta Pregled, a da za jednog Remontera imate više KontaktLica.
Ne brinite doradiću ja. I to bi bilo to? Nema još neki zahtjev?

To je sve.

Dorađen BE. Nadam se da nisam ništa propustio. Još jedno pitanje, da li prečnik ima decimalni zarez npr: 950,50 i da li pri vaganju takođe može biti 120,50 ?
U prilogu BE i FE baze. Pokušajte da prepravite postojeće forme i dodate im nedostajuća polja i da napravite nedostajuće šifarnike-forme za tabele:IzvrsenRad,ZahtevaniRad,RazlogOtpisa. Šifarnik Majstor prepravite u FizickoLice. Sifarniku Remonter dodajte nedostajuća polja. Sifarniku Tip dodajte nedostajuće polje.
Za forme koje treba da napravite možete Copy-Paste odgovarajuću formu, dodate joj ime identično tabeli, pa joj promjeniti Record Source i onda mjenjati naziv polja i labela i promjeniti kod da bi proradilo... Samo lagano...

Uradila sam sve kako ste napisali. Najlepše Vam hvala. Puno ste me naučili.

Ni prečnik ni težina nemaju decimalni zarez.

_{[Ovu poruku je menjao marija.ana dana 08.08.2014. u 11:42 GMT+1]}

Kao model koji ste kopirali ste koristili formu Neispravnost, međutim jedino svojstvo koje ste promjenili je Control Source polja i Record Source forme. Da bi forma proradila bilo je potrebno promjeniti ime polja i kod koji se nalazi na tri događaja forme. Da bi na formi bio naziv koji treba da bude bilo je potrebno promjeniti i svojstvo Caption forme. Ovako kako je ostalo još uvjek je dio forme gledao u podatke tabele Neispravnost. Idemo dalje...

Malo smo se zaletjeli pa sam napravio jedan previd. Postavio sam jednu relaciju koja nam u suštini ne treba i to pogrešno. Potrebno je izbrisati relaciju između tabela PregledOsovina i Otpremnica. Mislim da nam neće trebati a kada bi nam trebala ova relacija bi morala biti više prema više pa bi nam na njoj trebala međutabela.
Izbrisaćemo je i izbrisaćemo preneseni ključ PregledOsovinaID iz tabele Osovine.

Da bih Vam pojasnio na šta je @Zidar mislio zakačio sam njegov fajl iz teme "Magacinsko poslovanje" u kojem objašnjava pokrivanje modela formama. Meni se više sviđa korišćenje Tabular forme umjesto Datasheet tamo gdje to može zbog ljepšeg izgleda i mogućnosti dodavanja komandnog dugmeta umjesto dvoklika za pregled, a na isti način je moguće filtriranje podataka kao i kod Datasheet forme. Inače skup tema Magacin-Maloprodaja-Caffe je vrlo edukativan, naročito za početnike pa Vam savjetujem da ga pročitate. Šteta što @Zidar ne želi da napiše knjigu o Access-u i relacionim bazama podataka, jer nisam naišao da je neko o toj temi bolje objasnio od njega.
Pokrivanje modela formama u našem slučaju prikazan je na prikačenoj slici. Za žute tabele ćemo praviti samo Tabular forme, a za zelene i Tabular i Columnar forme.

Biće mi drago ako Vam moje skromno znanje bude od pomoći. Sve što znam naučio sam uglavnom ovde na forumu, najprije od @Zoran.Eremije i @Zidar-a, a zatim i ostalih iskusnijih forumaša.

Auu, uradila sve to, ali izgubila fajl na serveru na poslu pa posle u frci verovatno okacila pogresan. uradicu ponovo

Lapsus, mislili ste na Otpremnica?

:-) Tako je. Lapsus trebalo je Otpremnice. Ne morate opet raditi, svakako cemo mjenjati svašta nešta. Nisam odavno ništa radio u Access-u pa sam mnogo toga zaboravio. Valja se prisjetiti onoga što sam,valjda, znao...

Konačno sela za svoj računar. Sredila ponovo sve. Nisam znala kako da napravim forme Majstor i LiceZaKontakt a vidim da su potrebni. Na koji način treba da funkcioniše unos novog majstora ili lica za kontakt? Na koji način treba da funkcioniše unos nove (a stare) osovine, da li se prvo mora uneti Godina u tabelu Godina ili unosu u polje Godina tabele Osovine treba da prethodi automatski unos u tabelu Godina?

Jedno pitanje, zašto je potreban šifrarnik "Stanje" i zašto se ručno dodaje broj stanja?



_{[Ovu poruku je menjao marija.ana dana 09.08.2014. u 02:15 GMT+1]}

U pravu ste, izrada ovih formi je malo komplikovanija. Ova polja vuku podatak iz tabele FizičkoLice, a obzirom da je ovaj podatak primarni ključ ovih tabela sistem neće dozvoliti da se isti podatak unese 2 puta, međutim problem je obezbjediti logičko funkcionisanje forme, a za to je potreban trik koji sam naučio od @Zoran.Eremija- Uvodi se polje koje će prikazivati podatak, a u Row Source combobox-a uvodi se upit koji ne dozvoljava ponavljanje podatka u izboru.
Uvjek kada nedostaje podatak iz nadređene tabele treba obezbjediti način dodavanja ovog podatka, nekad je način prekid, pozivanje nadređene forme, unos podatka, osvježavanje polja, a nekad se ovo odradi kodom u pozadini ili akcionim upitom koji dodaju ovaj podatak.

U tabeli "DozvoljenePromeneStanja" podatak npr. "Zaliha" imate na 5-6 mjesta. Kada se ovako ponavlja podatak po pravilima baze podataka takav podatak se smješta u zasebnu tabelu kao nadređenu a podatak se obezbjeđuje prenosom FK u podređenu tabelu.
Atribut BrStanja je podatak koji je @Zidar koristio u primjeru Praćenje promjene stanja, a da li će nama trebati vidjećemo, ako ne bude trebao izbrisaćemo ga kasnije. Automatski unos bi mogao da se obezbjedi kasnije ako za to bude potrebe.

Ne žurite. Već sam napomenuo da sam i sam početnik-amater , a dugo se nisam bavio ovim. Ljudi uče fakultete i pročitaju veliku količinu literature da bi se ovim bavili, pa i pored toga opet su im potrebne godine prakse da bi zaista bili uspješni u ovom poslu. Ja imam, možda, samo malo više znanja od Vas po ovom pitanju pa je rješavanje pojedinih zadataka i meni problem. Pokušaću da ono što znam podjelim sa Vama. Već sam rekao, igramo se, pa šta uradimo... :-)
Samo polako.



_{[Ovu poruku je menjao nenadmarkoni dana 09.08.2014. u 10:29 GMT+1]}

U BE baze sam izbrisao Lookup pogled u svim tabelama. U suštini sam ga bio postavio da Vama olakša snalaženje. U FE baze sam dodao određene promjene i dijelom doradio forme. U daljem radu ćemo izbrisati podatke iz tabele Osovine, oni će morati ručno da se dodaju da bi omogućili da forma doda inicijalno stanje u PracenjePromeneStanja. Forme još nemaju punu funkcionalnost niti konačan izgled. Na slici su prikazane narandžactom bojom tabele za koje smo napravili forme.

Predivno izgleda, samo što ja sve teže hvatam korak. Pokušala sam da napravim formu KontaktLice, kopirajnem/prepravljanjem forme Majstor, ali sam onda videla da je Vaš QKontaktLice drugačiji. Pretpostavljam da ste zamislili da forma KontaktLice drugačije izgleda/funkcioniše.

_{[Ovu poruku je menjao marija.ana dana 09.08.2014. u 23:45 GMT+1]}

Forma KontaktLice ce biti subforma forme Remonter, u kojoj ćete moći odabrati kontakt lica (više lica) za tog Remontera.
Tabela Remonter je vezana sa tabelama Otpremnica,PregledOsovina,Remont i KontaktLice. To nam govori koje subforme treba napraviti. Imaćemo pregled Otpremnica koje su došle od tog remontera, pregled PregledaOsovina koji su upućeni tom remonteru, Imaćemo pregled osovina koje su bile, ili su još uvjek kod tog remontera i imaćemo pregled Kontakt lica za tog remontera.
Za sad je djelimično riješen unos Osovina i unos stvarnog stanja za tu osovinu. Otvorite OsovineLista , u gornjem lijevom uglu je taster za dodavanje nove osovine. Dodajte neku probnu. Kada unesete Serijski broj, godinu i tip pritisnite Tab ili Enter da bi zapamtili zapis. Kod u pozadini će pokrenuti 2 Append Query-ja koji će dodati inicijalno stanje i prikazaće se tasteri za upis stvarnog stanja osovine. Dvoklikom na RBr statusa u subformi imaćete uvid u taj zapis. Može se izbrisati samo zadnji unos. Ako postoje zapisi u subformi ne može se izbrisati Osovina. Da bi izbrisali Osovinu ispraznite zapise u subformi, obiljezite zapis klikom u lijevi dio forme i pritisak na taster Del na tastaturi. Igrajte se malo sa unosima, pogledajte kako šta radi, kasnije ćemo se pozabaviti stvarnom logikom funkcionisanja- šta nam treba a šta ne. U formama koje se otvaraju na komandne tastere upotrebili smo kod koji je @Zidar dao u temi Praćenje promjene stanja, ali malo izmjenjen. Mislim da ćemo izbrisati atribut BrojStanja u tabeli Stanje. Nismo ga koristili. Možda sve nije najsrećnije napravljeno, ali za početnike poput mene i Vas nije loše. Ako neko ima neka bolja rješenja bilo bi ih korisno čuti.

Do sada smo djelimično rješili radni proces "Evidentiranje osovine". Sledeći proces koji rješavamo je "Izgradnja i ugradnja osovina" U prikazanoj slici su glavne tabele koje učestvuju u ovom procesu. Osovine koje se izgrađuju su osovine koje su u statusu "Vagon" i one prelaze u status "Neispravna".Znači samo osovine koje su u ovom statusu mogu se izgraditi.Ukoliko je kao neispravnost navedeno Uklapanje ove osovine će preći u status "Zaliha". Na njihovo mjesto se ugrađuju osovine koje su u statusu "Zaliha", i one prelaze u status "Vagon" Ne može se unijeti pozicija na vagonu koja nije slobodna-izgrađena. Kada Vam majstor dostavi Dnevni izvještaj izgradnje-ugradnje, unosite podatak o datumu poslednjeg remonta i remonteru u dijelu ugrađenih osovina. Ovaj podatak ćemo dobiti automatski upitom za ugrađenu osovinu. Unesite kroz forme koje su urađene podatke za nekoliko osovina u različitim statusima da bi imali probne podatke za izradu formi za sledeći proces, ostale izbrišite.

Već izgleda ozbiljno, daleko ozbiljnije od moje kreacije. Mali problem sa unošenjem podataka unazad (prethodni remont) rešila sam pomeranjem sistemskog datuma. U formi remont nema polja za unos remontera. U formi OsovineLista sam morala da "Filter On Load" postavim na "No" (nije htela da prikazuje listu osovina, bio filter OsovinaBr"1111" verovatno greškom).

Za ocekivati je da ce unos podataka unazad biti problem,jer je baza projektovana da prati podatke unaprijed. Ono sto je omoguceno je unos trenutne pozicije osovine. Dnevni list izgradnje-ugradnje je ulazni dokument. Za njega necemo raditi izvjestaj, a podatak o zadnjem remontu cete na njega svakako unositi rucno, u bazi ce ovaj podatak biti informativni da ga ne bi morali traziti.Access pamti zadnji filtar, a filtar za osovinu 1111 sam ja zadnji koristio. Mogli ste jednostavno desni klik na formu i izaberete Remove filtar. Formu Remonter jos nismo izradili kako treba. I oko nje ce biti dosta posla.
ps. Ne morate brisati osovine ako vec niste, mozemo probati ubaciti pocetno stanje za sve odjednom ako zelite pa im Vi postavite trenutnu poziciju.

Izvinjavam se tek sam shvatio sta ste pitali u vezi forme Remont i unosa Remontera. On tu i ne treba da bude. Podatak o Remonteru imacemo na Otpremnicama koje dodju od njega i na Pregledu koji posaljemo njemu. Forma Remont prati samo stanje osovine.

Evo unešeni su inicijalni zapisi za sve osovine.Dodali smo ih pomoću 2 akciona upita. Sad možete rasporediti osovine tamo gdje se nalaze. Ovo su samo probni podaci da bi imali podatke za dalji rad i ne morate unositi prave podatke.

Kod dodavanja stanja Neipravna, Neispravnosti su "potrošne" kada dodam neku više je nema u listi. Pretpostavljam da ste tako i zamislili, medjutim jednom upotrebljena neispravnost se više ne pojavljuje ni kod sledeće osovine (kad ih potrošim sve više ih nema i ne mogu dodati novu neispravnu osovinu). Eto, ja i moje objašnjavanje. Ako sam uspela da objasnim.

Objašnjeno. Riješeno!
Neće me biti sjutra na forumu. Pauza

Izmenio sam naslov teme. Mislim da je ovo adekvatnije. Nakon završetka ćemo temu pridodati u spisak "Gotovi programi članova foruma".

Ako budemo uspjeli da završimo. Evo već je potrebna pomoć. Napravio sam formu RadniList, Na nju sam dodao dvije subforme za izgrađene i ugrađene osovine. Na njima su polja Tip, Remonter i Datum Remonta koji su izračunata polja upita koji je Record Source za formu. Ova polja bi trebala da nam prikažu traženi podatak ali tek nakon ažuriranja forme, međutim prilikom unosa na njima se prikazuje greška što je i logično. Da bih prikrio prikazivanje greške ova polja sam prekrio poljima koja će nam privremeno dok unosimo podatke prikazati traženi podatak. Međutim njima je potrebno dodati ControlSource tek nakon ažuriranja tj. izbora Serijskog broja. Napisao sam kod na After Update polja SerijskiBrojOsovine ali je problem greška u sintaksi. Može li neko pomoći?

Mene je sintaksa pridavila odavno

@ nenadmarkoni
Mislim da bi trebalo ovako.
Napravi kopiju forme RadniListLista. Skini dugme za dodavanje i u osobinama joj omogući Allow Additions. Continues forms je takva da joj ne trebaju posebna dugmad za dodavanje. Kad uneseš podatke u toj formi onda na dugmetu za detalje (…) omogući otvaranje drugih podformi, makar i u posebnom prozoru. A možda će raditi i ovako. Nećeš imati greške prilikom unosa za koje kažeš da su logične pojave.
U svakom slučaju posebno bi trebalo da se dodaju zapisi o : ID, Broj dnevnog izveštaja, Datum i Majstor. Nakon toga detalji.
Izvinjavam se ako nisam u toku jer ovo pratim s vremena na vreme, tek da tema ne izmakne kontroli.


_{[Ovu poruku je menjao Getsbi dana 13.08.2014. u 16:20 GMT+1]}

@Getsbi U pravu ste da je tako trebalo napraviti i to sam izmjenio, međutim greška nije u tome. Forma RadniListUgradjeneOsovine- na AfterUpdate polja SerijskiBrojOsovine potrebno je dodati ControlSource za tri nevezana polja ali griješim u sintaksi jer treba nešta puno navodnika i počinje sa:Polje.ControlSource="=""".....

Tu gde kažeš nevidim grešku u sintaksi. VBA nebi dozvolio kompajliranje. Možda je problem i sa nevezanim poljima. A možda da pokušaš da umesto osobine ControlSource koristiš DefaultValue. Ne mogu tako brzo da uđem u problematiku. Forme sa nevezanim poljima su dobre ako tabela ima ima na hiljade zapisa, a treba da se učita samo radi upisa novog zapisa. U svakom slučaju ako je polje nevezano, za njegovo ažuriranje treba da postoji VBA kod koji će ga uneti u tabelu. Ako su u pitanju forma i podforma onda je bolje da su ti polja vezana.

Očigledno me ne razumijete, a vjerovatno sam i ja to uradio malo čudno. Izvor za formu je upit preko kog će se ažurirati unijeti zapis. Na tom upitu sam napravio 3 izračunata polja za Tip, Remonter, i PoslednjiRemont za tu osovinu. Kada se unosi zapis na combobox SerijskiBrojOsovine kao izvor imamo samo osovine koje su u statusu Zaliha. Izborom osovine u Text Box-evima koji prikazuju ove izračunate podatke dobijemo #Error , što je i logično jer još uvjek ne postoji zapis. Da bih to prikrio preko ovih polja sam postavio nevezana polja koja će nam privremono prikazivati te podatke dok se ne izvrši ažuriranje zapisa. Ako u ova polja unesem kao ControlSource kod koji sam napisao onda će prije izbora osovine u njima stajati #Error, tako da je ControlSource potrebno dodati tek pošto se izabere osovina.

:-( Loše riješena forma RadniList. Ne radi i ne izgleda kako sam ja mislio. Pokušaćemo drugačije.

Nova forma RadniList. Unos na RadniListLista.
Po @Getsbi-jevom savjetu. Tek sam kasnije skontao šta je hteo da mi kaže.
Ima još rada na ovoj formi ( postavljanje uslova da se ne može ugraditi osovina ako na toj poziciji već postoji osovina, da na jednom vagonu budu sve osovine istog tipa[ovo baš i ne znam kako bi rješili] i sigurno još štošta...) ali sada nemam vremena. Čisto da @marija.ana ne izgubi vjeru da ćemo nešta od ovoga napraviti.

Oduševljena sam, nisam ni zamišljala da može ovako da izgleda. Moj pokušaj nije bio primitivan, nego amebica. Uslov da na jednom vagonu budu sve istog tipa nije ni potreban to majstor sam radi to se jasno vidi.

Pokušao sam da riješim zahtjev da ako se kao neispravnost navede "Uklapanje" osovina pređe u status "Zaliha". Napravio sam Append Query-je koji bi ovo trebali da urade. U pitanju su "QUklapanjePracenjePromeneStanjaDodaj" i "QUklapanjeZalihaDodaj". Pokreću se posle izbora Neispravnosti u formi Neispravnost. Na "QUklapanjePracenjePromeneStanjaDodaj" dobijem prave vrijednosti polja, ali upit se ne izvrši do kraja. Šta je u pitanju? Jel se može izvršiti akcioni upit dok je otvoren rekord iz tabele u koju treba upisati vrijednosti? Da li je problem što je ovaj rekord otvoren?

Izvorna tabela može da bude otvorena. Ciljna takođe, s tom razlikom što nećeš videti rezultat dok ciljnu ne zatvoriš, pa ponovo otvoriš ili uradiš osvežavanje tabele.

Zahvaljujem. Greška,ako se tako može nazvati, je bilo to što u DozvoljenePromeneStanja nije bilo unijeto Neispravna-Zaliha. Znači nema greške :-)

Napravljena forma Remonter i dorađeni pojedini uslovi u RadniList. Mislim da ću tokom sledeće nedelje biti malo više zauzet pa ostalo kad stignem.

Nešta sam napamet uradio, jer nemamo probne podatke. @marija.ana isprobajte u ovome što je urađeno da unosite neke logične podatke, vidite ima li negdje grešaka.

Ono što na prvi pogled primećiujem. Unos i manipulacija preko "Evidentiranje osovina" fukncioniše super. Unos preko radnog lista ima problem, kad se unese izgradjena osovina trebalo bi da se automatski popune polja broj vagona i pozicija, pošto ugrađena dolazi na mesto izgrađene, nije lako naći ručno podatak a obavezan je za unos. Takođe bi tu negde trebala da vidim i datum, mesto i vrstu zadnjeg remonta (to moram rukom da napisem u onaj dnevni list).
Pregled osovina za remont - izbacuje gresku prilikom pokusaja unosa osovine.
Vagon lista - lepo bi bilo da se vidi broj vagona, pozicije i ako je moguće datum poslednjeg remonta.
Pogrešila sam starosnu granicu za škart nije 40 nego 45 godina.

Super izgleda, lepo pregledno, lako za upotrebu.

Ispravljeno. Pored kontrole unosa logičnih podataka aplikacija treba da je izrađena tako da spriječi unos nelogičnih podataka, a time ćemo se pozabaviti kada utvrdimo da li smo najprije riješili pravilan unos logičnih.

Nisam bio ispravio VagonLista, evo sad je i to sređeno.

Nisam neki stručnjak za Reporte pa Vi doradite izgled izvještaja RPregledOsovina.

Izgleda fenomenalno. Počeću sutra da unosim prave podatke.

Ima još dosta posla. Nismo rješili proces otpisa osovina, nismo rješili praćenje rokova od 45 godina starosti i 4 godine od poslednjeg remonta. Tu je i pitanje kad šta može da se briše, a kad ne. Oni tasteri na formi Osovina bi trebali da služe samo da rasporedimo osovine tamo gdje su u realnom sistemu i samo za to, ne za dalje korišćenje i unos. Svakako krenite sa pravim podacima, tako se najbolje uoče greške. Popunite šifarnike. Ne znam koliko ima logike unositi podatke unazad, a mislim i da je dosta teško, ali kako hoćete. Treba i proći opet kroz sve forme i upite, zbog eventualnih grešaka kojih sigurno ima. Kad sve završimo treba spakovati aplikaciju tako da se ne vidi ono što ne treba da se vidi...... a ni tada nije sve gotovo.

Čini mi se da je "Izvrseni rad" i "Vrsta remonta" dupliranje.

Izvrseni radovi su oni radovi koje je remonter naveo na otpremnici npr. : Zamena bandaza, Obrada profila tocka.., a tip remonta je verovatno da li je redovan ili vanredan ili revizija sa obradom i revizija bez obrade...

Da, da, moja greška. Vrsta može biti: Redovan, Vanredni ili Investiciona opravka, a Izvršeni radovi su revizija, zamena ili obrada.

Pitanje: kako da unesem novu osovinu i postavim joj stanje na "Zaliha"? Unesem ja nju, ali ne mogu da postavim početno stanje.

Na OsovinaLista se unose nove osovine. Pokazivac se pozicionira najprije na Serijskibroj kad unesete pritisnite Enter ili Tab na tastaturi i tako redom. Inicijalni status ce aplikacija sama unijeti a to je Zaliha tako da je nema potrebe opet unositi. Dodatne napomene unesite dvoklikom na RBr u subformi forme osovina cime cete otvoriti formu Zaliha sa tim zapisom. Ako kojim slucajem nisam ogranicio prelaz Zaliha-Zalija samo na inicijalni zapis onda to treba uraditi, jer jedino za njega je ovaj prelaz logican.

_{[Ovu poruku je menjao nenadmarkoni dana 18.08.2014. u 12:27 GMT+1]}

Izgleda da forma OsovineLista ima problem. Izadje "Enter Parameter Value" prozor. Na kraju sam shvatila da ako unesem podatke ponovo (u tom prozoru) postavi stanje u "Zaliha".

Problem je što je u upitima QPracenjePromeneStanjaDodaj i QZalihaPocetnoStanjeDodaj ostao uslov koji gleda na formu Osovina umjesto na OsovineLista. Evo ispravljeno

Ja izgleda uvek moram da naučim na teži način. Umesto da Vas poslušam i da unesem trenutno stanje, izgubila sam puno vremena pokušavajuči da unesem podatke "unazad". Otvorim cmd prozor i menjam datum. Zbunjujem se, pravim greške... Sizifov posao. Sutra postavljam stvarno stanje.
Ako mi se desi, a desiće se, da je neki broj pogrešno unet (na primer pogrešan broj na pločici a to se otkrije tek na remontu), ne mogu da promenim broj osovine? Pretpostavljam da je moram obrisati pa ponovo uneti pravilne podatke. To u neku ruku i nije problem pošto se dešava veoma retko, a ova baza podataka će ukinuti mogućnost greške (kada unesem tačne podatke).

Dodala sam u QTrenutnoNaKolima sortiranje po broju vagona i po poziciji.

_{[Ovu poruku je menjao marija.ana dana 18.08.2014. u 18:50 GMT+1]}

To Vam neće biti preteško, jer do prvog remonta osovina će imati tek par promjena stanja. Bas zbog ovoga sam Vas i pitao da li ste sigurni da je kombinacija SerijskiBrojOsovine-Godina dobar kandidat za Primary Key. Da ste tada odgovorili negativno za kljuc bi postavili onaj programerski AutoNumber, a kombinaciju koja nam je sada PrimaryKey bi indeksirali da se ne ponavlja. Tada bi bez velike muke mogli promjeniti SerijskiBroj. :-(

_{[Ovu poruku je menjao nenadmarkoni dana 19.08.2014. u 11:17 GMT+1]}

Nismo bili postavili pravila validacije u tabeli PracenjePromeneStanja.
Otvorite OsovineBE. Otvorite tabelu PracenjePromeneStanja. Pređite u Table Design mod. Kliknite desnim klikom na tabelu i izaberite Properties. U polju Validation Rule upišite sledeći kod :
Ovo bi trebalo da obezbjedi da se prelaz stanja iz Zaliha u Zaliha može unijeti samo za prvi inicijalni unos i da TrenutakPrelaza bude veći od StariTrenutakPrelaza kao i da RBr bude veći od StariRBr.

ps. Kad ovo promjenite da bi mogli promjeniti podatke u tom inicijalnom unosu potrebno je malo promjeniti i kod u formi Zaliha. Koristite ovaj FE iz priloga. U formi Osovine za unos pravog početnog stanja u suštini nam neće trebati tasteri Zaliha i Škart. Zalihu unosi inicijalni zapis i dovoljno je da omogućimo izmjenu prečnika i napomene , a osovine koje su otpisane vjerovatno nećete ni unositi. Vidjećemo kad budem imao malo više vremena da nastavimo.

_{[Ovu poruku je menjao nenadmarkoni dana 18.08.2014. u 21:59 GMT+1]}

Uhvatih malo vremena pa da se malo pozabavimo onim što nismo rješili - Otpis osovine i prelazi koje nismo rješili.
Što se tiče otpisa osovina. Naveli ste da pored starosti od 45 godina mogu biti još 2 razloga za otpis: Kriv trupac i Oštećen rukavac. Sva tri razloga su ustvari tipovi neispravnosti. Kada se osovina evidentira kao neispravna sa ovom vrstom neispravnosti automatski ide u Škart. Znači da tako treba i aplikacija da radi. Isto kao što smo izveli da kada se kao razlog izgradnje odn. neispravnosti navede Uklapanje osovina pređe u status Zaliha, sada ćemo izvesti da ako se izabere neki od navedenih razloga osovina automatski pređe u Škart ,vodeći računa da ako je razlog starost od 45 godina sistem najprije provjeri da li je izabrana osovina zaista te starosti( da se ne desi da za osovinu staru 10 godina izaberemo ovu neispravnost). Samim tim nije nam potreban RazlogOtpisa u posebnoj tabeli, odnosno nije nam potrebna ta tabela. RazlogOtpisaID nam je zapravo NeispravnostID pa ćemo tako i spojiti relacije a relaciju sa tabelom RazlogOtpisa ćemo raskinuti i tu tabelu izbrisati. Znači za odlazak osovine u Škart najprije se mora evidentirati u Neispravne pa odabirom pomenutih neispravnosti osovinu Otpisati. Slažete li se sa ovim?
Što se tiče navedenih prelaza svi pomenuti prelazi mogu se rješiti prelazom Zaliha-Neispravna.
Remont-Škart - osovina se vraća sa remonta sa utvđenim kvarom koji vodi otpisu, ali se vraća takođe kroz Otpremnicu pa ćemo je evidentirati u Zaliha i odatle prebaciti u neispravne gdje ćemo joj odrediti neispravnost koja vodi otpisu.
Ako se desi neispravnost na Zalihama takođe ide u Neispravne
Ako istekne rok od 45 godina na Zalihama takođe ide u Neispravne-> izvor neispravnosti 45 godina starosti-> Škart
Ostaje pitanje revizije vagona kada sa njim odlaze sve četiri osovine na remont-reviziju. To treba malo bolje da pojasnimo i ako treba da ovo ubacimo u bazu moraćemo da dodamo još tabela i relacija.
Mislim da ćemo uspjeti i da ubacimo kontrolu da pri ugradnji u vagon budu sve osovine istog tipa.
Maći ćemo i atribut BrojStanja iz tabele Stanje.
Za sada model izgleda kao na slici.

Uhvatih malo vremena pa da se malo pozabavimo onim što nismo rješili - Otpis osovine i prelazi koje nismo rješili.
Što se tiče otpisa osovina. Naveli ste da pored starosti od 45 godina mogu biti još 2 razloga za otpis: Kriv trupac i Oštećen rukavac. Sva tri razloga su ustvari tipovi neispravnosti. Kada se osovina evidentira kao neispravna sa ovom vrstom neispravnosti automatski ide u Škart. Znači da tako treba i aplikacija da radi. Isto kao što smo izveli da kada se kao razlog izgradnje odn. neispravnosti navede Uklapanje osovina pređe u status Zaliha, sada ćemo izvesti da ako se izabere neki od navedenih razloga osovina automatski pređe u Škart ,vodeći računa da ako je razlog starost od 45 godina sistem najprije provjeri da li je izabrana osovina zaista te starosti( da se ne desi da za osovinu staru 10 godina izaberemo ovu neispravnost). Samim tim nije nam potreban RazlogOtpisa u posebnoj tabeli, odnosno nije nam potrebna ta tabela. RazlogOtpisaID nam je zapravo NeispravnostID pa ćemo tako i spojiti relacije a relaciju sa tabelom RazlogOtpisa ćemo raskinuti i tu tabelu izbrisati. Znači za odlazak osovine u Škart najprije se mora evidentirati u Neispravne pa odabirom pomenutih neispravnosti osovinu Otpisati. Slažete li se sa ovim?
Što se tiče navedenih prelaza svi pomenuti prelazi mogu se rješiti prelazom Zaliha-Neispravna pa ćemo samo za ovaj prelaz praviti posebnu formu.
Remont-Škart - osovina se vraća sa remonta sa utvđenim kvarom koji vodi otpisu, ali se vraća takođe kroz Otpremnicu pa ćemo je evidentirati u Zaliha i odatle prebaciti u neispravne gdje ćemo joj odrediti neispravnost koja vodi otpisu.
Ako se desi neispravnost na Zalihama takođe ide u Neispravne
Ako istekne rok od 45 godina na Zalihama takođe ide u Neispravne-> izvor neispravnosti 45 godina starosti-> Škart
Ostaje pitanje revizije vagona kada sa njim odlaze sve četiri osovine na remont-reviziju. To treba malo bolje da pojasnimo i ako treba da ovo ubacimo u bazu moraćemo da dodamo još tabela i relacija.
Mislim da ćemo uspjeti i da ubacimo kontrolu da pri ugradnji u vagon budu sve osovine istog tipa.
Maći ćemo i atribut BrojStanja iz tabele Stanje.
Za sada model izgleda kao na slici.

Uvek ste nekoliko koraka ispred mene. Slažem se sa gore napisanim uz malu izmenu: Kontrola da na vagonu budu samo osovine istog tipa nije potrebna. To majstor sam pri ugradnji radi (a kad nema drugog rešenja nakada i odstupi od tog pravila). Pravilo je da ispod iste ćelije (deo vagona) budu istog tipa osovine: 1/2 i 3/4 (te dve moraju istog tipa) ili 5-6 i 7/8, ali to nije toliko bitno.
Kada Osovine idu sa sve Vagonom to je "Investiciona opravka". Na investicionu opravku se šalje nekoliko vagona i tu se može desiti da im izmenjaju mesta ispod vagona ili pozicije osovine. Znači može da ode Vagon A sa osovinama 1,2,3 i 4 i Vagon B sa osovinama 5,6,7 i 8 a da se vrate: Vagon A sa osovinama 1,2 5 i 6 i Vagon B sa osovinama 3,4,7 i 8.

Mozete li detaljno opisati ovaj proces revizije vagona sa osovinama. Sta se popunjava kad ih saljete i koji dokument prati vracanje? Da li i u ovom procesu moze biti nepredvidjenih situacija npr. jedna id osovina je za otpis i ne moze se ugraditi, sta tada?
ps. Pri modeliranju nema nebitnih stavki. Ono sto se Vama sada cini nebitno bitno mijenja sam model. I pojam Celije je trebalo ubaciti u model. Aplikacija mora da garantuje unos pravilnih podataka da bi vrsila svoju funkciju.

Nekako imam osjecaj da je jos nesta ostalo nedoreceno! Pomenuli ste Broj na celu i Broj na plocici. Je li to kao kod auta plocica sa brojem sasije i Broj sasije ukucan na samoj sasiji? Kod Vas je to serijski broj koji moze da se ne poklapa dok remonter to ne utvrdi, je li tako?

Ovo jos nisam imala prilike da radim, moram se malo raspitati.
Ćelija je žargon, u stvari je to teretni vagon sa dve pregrade. Nema potrebe za uslovima i pravilima (osovine istog tipa na vagonu) pošto se to pravilo ponekad i ne poštuje (nekad nema odgovarajuci precnik, nekad je nesto drugo u pitanju).
Pločica je "napolju" zavrnuta na osovini, može se desiti da otpadne, da se ošteti ili da se prefarba nečim. Sem pločice postoji i serijski broj na samoj osovini, ali je do njega teško doći, moraju se skidati plombe i razni delovi. Kada majstori nešto kontrolišu i skidaju "poklopce", može se desiti da pomešaju pločice pa to posle otkrije remonter.

Ovo jos nisam imala prilike da radim, moram se malo raspitati.
Ćelija je žargon, u stvari je to teretni vagon sa dve pregrade. Nema potrebe za uslovima i pravilima (osovine istog tipa na vagonu) pošto se to pravilo ponekad i ne poštuje (nekad nema odgovarajuci precnik, nekad je nesto drugo u pitanju).
Pločica je "napolju" zavrnuta na osovini, može se desiti da otpadne, da se ošteti ili da se prefarba nečim. Sem pločice postoji i serijski broj na samoj osovini, ali je do njega teško doći, moraju se skidati plombe i razni delovi. Kada majstori nešto kontrolišu i skidaju "poklopce", može se desiti da pomešaju pločice pa to posle otkrije remonter.

Strašno, koliko ne umem da objasnim... Pločica sa brojem se nalazi ispod šrafa koji drži poklopac, serijski broj je upisan ispod poklopca na "čelu" osovine (pčelu što bi rekle plavuše). Poklopac sme da se skida samo kod remontera. Nekad mi zamenimo pločicu greškom (spadne, ošteti se, zameni se), nekad je remonter zameni.
Investiciona opravka je kada se pošalje nekoliko vagona na remont, ja treba da pošaljem "defektažnu listu" (broj vagona i brojevi osovina) a remonter mi vrati istu listu ako nije menjao raspored ili listu sa novim rasporedom.

Ukoliko je moguće bilo bi dobro imati primjer Defektažne liste

Evo, pronađena. "Moja" je samo stavka "1" osovinskim sklopovi. Popunjavam samo fabrički broj i godinu (upisem u isto polje) ostala polja ne popunjavam. Vracaju mi istu listu samo sa novim rasporedom (ako ima promena).

Za svaki vagon se popunjava po jedan Defektazni list? Ako odu 2,3 vagona na reviziju tad mogu da kombinuju osovine sa tih vagona medjusobno. Ne odgovoriste sta ako utvrde da jedna, ili ne daj Boze vise njih, nije za dalju upotrebu odn. da su za otpis? Sta se tad desava? Da li traze da im dostavite neke osovine iz zalihe ili ugrade neku svoju, koju Vi ne duzite? Ako vrse promjene u redosledu ili u osovinama koje su ugradjene napisu novi Defektazni list sa novim brojevima ako sam dobro shatio. Po dokumentu bih rekao da i vagon ima svoj tip?

Da, traže da im dostavim odgovarajuću.
Da pošalju novi list sa novim rasporedom. Vagoni sigurno imaju svoj tip, ali se ni to ne popunjava pošto mi imamo samo taj jedan tip.

Kao sto sam i mislio. :-(
Pretpostavljam da sam jako dosadan sa svim ovim pitanjima, ali svi ovi dodatni zahtjevi drasticno mijenjaju prvobitni model baze, a Vama je potrebna baza koja ce ispratiti sve procese koji se javljaju. Ovde imamo jos jedan dodatni proces koji ce zahtjevati i novu tabelu. Da bi je pravilno postavili i ovaj proces moramo razjasniti. Osovinu koju im saljete mogli bi opisati promjenom Zaliha-Vagon, ali ova promjena se vrsi kroz Radni list koji se ovom prilikom ne popunjava. Realniji opis je da i ova osovina odlazi na remont, jer ce je oni svakako pregledati prije ugradnje. Niko ne garantuje da se ne moze desiti da i ova osovina koju im posaljete nije za ugradnju. Pitanje je kako Vam traze novu osovinu? Dokumentom ili telefonom? Kada im saljete ovu osovinu koji dokument je prati. Da li Vam osovinu koja nije za ugradnju salju pri zahtjevu za zamjenu ili kad vrate vagon? Salju li uz nju Otpremnicu na kojoj je konstatovan kvar za otpis, jer se ona ne vraca kroz Defektazni list. I jos jednom, da li na istoj "Celiji" (koliko sam mogao zakljuciti po slikama teretnih vagona to je sklop od dvije povezane osovine) moraju biti osovine istog tipa?

Da, osovina tako odlazi na remont, svejedno sto je sa vagonom, tamo se skida proverava i obrađuje ako je to potrebno (usled obrade se menja prečnik pa zato menjaju mesta da bi se bolje uklopilo). Novu osovinu mi traže ili email-om ili telefonom i ne može se desiti da i ta ne odgovara. Kada je pošaljem, ne šaljem poseban papir (samo pišem izlaznicu vozaču kamiona). Isti kamion vrati onu koja je škart i uz nju mi pošalju otpremnicu. (Ovo još nisam radila, tako mi je objasnio kolega koji je pre radio taj posao. Pretpostavljam da se to može opisati Vagon-Remont Remont-Vagon, i za zamenu škart osovine fiktivni radni list? Jesam li lupila sad??

Evo zvala sam majstora upravo. Kaže "to je naše nepisano pravilo ali ne piše tako u pravilniku". Nekada je nemoguće da se to pravilo ispoštuje (recimo nema odgovarajuće osovine).

Da li upisuju negdje šta je urađeno na osovinama, kao što to pišu na otpremnici?

To se zove "Investiciona opravka". Na tu opravku idu vagoni, (mislim svake 4 godine). Na osovinama se veoma retko nešto menja, skoro nikad. Pošto su te osovine ispravne, samo provere vizuelno i ubaci se nova mast (i obavezno pomešaju pločice). Premeštanje osovina ispod vagona retko dešava ali se desi ponekad. Nikada se do sada nije desilo da je osovina bila neupotrebljiva, to je moja pretpostavka. Ako je nešto menjano dodje snimni list (sve isto kao i otpremnica).

_{[Ovu poruku je menjao marija.ana dana 21.08.2014. u 21:43 GMT+1]}

Citiraću @Zorana.Eremiju u dva navrata:"Ako ima ijedan pojavni oblik, smatra se kao da je to opšta pojava" i "Jedino rješenje je potpuni reinženjering" :-)
Shodno prethodnim zahtjevima novi model baze bi izgledao otprilike kao na slici, ali vidjećemo još.

Ja cu da placem, unela sam 800 osovina u bazu.

:-) To je najmanji problem, to ide na copy-paste. Sta kad Vam kazem da cete novu verziju raditi uglavnom Vi? :-O Tako to obicno bude kad se ne sagledaju svi procesi i ne uzme se sve, ali bas sve u obzir na samom pocetku. Ja sam svoju prvu pravu bazu radio preko 2 godine i nisam je zavrsio - tema "Odrzavanje zgrade", ali sam puno naucio. Vjerovatno Vam je jasno da i pojam "Snimni list" treba ubaciti u model.

_{[Ovu poruku je menjao nenadmarkoni dana 22.08.2014. u 08:37 GMT+1]}

Tu je novi BE fajl i nepotpuni Erwin fajl(nisam uspio da u njemu napravim sve što je u BE fajlu pa sam BE fajl dorađivao). Tu su i slike pojedinih procesa izvučene iz Erwin fajla. Nisam siguran da li sam dobro modelirao sve procese prema dobijenim zahtjevima ( pomalo su zbunjujući).

Ako je Vama zbunjujuće zamislite mene jadnu. I još zamislite koliko sam tužna što ni da objansim ne umem. Većinu problema do sada sam ja napravila lošim i nepotpunim objašnjavanjem.

p.s. evo još jedne greške nije "SnimniList" nego "MerniList". Videla sam to još juče ali mi je loše radio internet poslu pa nikako nisam mogla da prepravim poruku.

_{[Ovu poruku je menjao marija.ana dana 23.08.2014. u 12:15 GMT+1]}

@marija.ana Radi li se na FE baze? Evo otprilike nivo na koji smo bili stigli prije prepravke. Ako bude još nešta što niste pomenuli odustajemo . Vjerovatno postoji i dosta grešaka na ovome što je prepravljeno. Ako zelite da ubacite osovine koje ste prethodno unosili otvorite tabelu Osovina u prethodnoj verziji, obilježite sve zapise i prekopirajte ih u prazan Excel fajl. Dodajte jedan red ispred svega. U njega unesite redom brojeve 1,2,3 , postavite pokazivač na ivicu tog polja i kada se pojavi krstić povucite do kraja zapisa. Time ste dobili OsovinaID u svim zapisima. Obiljezite ih i kopirajte u tabelu Osovina nove verzije BE.

Trebaće mi malo vremena da shvatim sve promene u novoj verziji (tek sam se uhodala u staru a nova mi deluje zbunjujuće). Podatke ću najverovatnije morati ponovo da unosim (trenutno stanje i pozicije po vagonima).

Sačekajte malo sa tim unosima. Izgleda da se neće moći unositi trenutna pozicija onako kako sam ja mislio ( stvara posle probleme, npr. unesemo trenutnu poziciju remont ali nismo unijeli kroz otpremnicu pa se taj zapis vidi kod svih remontera i to onako kako ne treba). Za sada možete uraditi ono što sam Vam rekao i onako kako sam Vam rekao da ne bi plakali što ste unosili osovine. Recite mi da li možda imate poslednje radne listove za osovine koje su na vagonu i u neispravnim, preglede osovina za one osovine koje su kod remontera i otpremnice za one koje su se vratile sa remonta?
Prikačena verzija sa izmjenama u BE i FE.

_{[Ovu poruku je menjao nenadmarkoni dana 24.08.2014. u 18:25 GMT+1]}

Kačim u ponedeljak.

Ne treba ništa da kačite, već ćete najvjerovatnije njihovim unosom postavljati trenutnu poziciju osovina pošto onaj način na formi osovina izgleda ne valja. Znači imate, odlično.

Izgleda da ce jedino za osovine koje su u stvarnom statusu Remont morati da se unosi preko Pregleda za remont, sto znaci da ce se ove osovine najprije evidentirati u Neispravne pa Pregledom prebaciti u Remont. Za one koje su u statusu Zaliha omogucili smo izmjenu inicijalnog stanja, a za one u statusu Vagon i Neispravna radice dugmad na formi Osovina. Nece me biti danas i sjutra na forumu. Pokusajte da uradite formu za slanje na Investicionu opravku. Prije svega treba da napravite forme za sifarnike TipKola i VrstaDefektazneListe i da prepravite sifarnik Kola dodavanjem comboboxa TipKola koji ce vuci podatak iz sifarnika TipKola. Postavite kod na event On dblclick ovog polja da otvori sifarnik TipKola za novi unos. Za NazivVrsteDefektazneListe postavite 1='Slanje';2='Prijem'.Forma DefektaznaListaSlanje ce imati za Control Source upit QDefektaznaLista koji takodje treba da napravite. On se gradi kao i upit za ostale dokumente npr. QRadniList, QOtpremnica. I ova forma ce biti subforma forme Remonter pa velicinom treba da odgovara ostalim subformama forme Remonter. Logika funkcionisanja ove subforme: Posto ce biti subforma forme Remonter bice kao i ostale vezana poljem RemonterID za formu Remonter. Polje VrstaDefektazneListe ce biti nevidljivo i imace DefaultValue=1, Polja Godina, ID, VrstaDokumenta i DefektazniListID ce takodje biti nevidljiva. Za defaultValue ili RecordSource ovih polja pogledajte kako je uradjeno kod ostalih dokumenata. Napravite polje Broj i prekopirajte kod sa forme RadniList i prilagodite ga ovoj formi. Na formi DefektaznaListaSlanje imace vidljivo i obavezno polje Datum i BrojKola. Izborom ovih polja sve osovine koje su zrenutno na kolima preci ce u status Remont, a ovo ce odraditi AppendQuery ciju izradu cu objasniti ako ovo uspijete.

Problem (verovatno ja negde grešim). Prilikom unosa inicijalnog stanja, napravim fiktivni dnevni list gde samo ugradim četiri osovine (bez izgradnje, samo ugradnja). Dešava se da svaki zapis bude upisan tri puta (kada kliknem na broj vagona u šifrarniku "Vagoni" vidim da je ugrađeno 12 osovina na taj vagon (umesto 4 koje sam ja minut pra ugradila).

Vjerovatno greska u upitu koji prikazuje podatke. Ne treba fiktivni radni list vec se za osovine pojedinacno dugmetom Vagon na formi Osovina. Zato se aplikacija i testira unosom probnih podataka jer su ovakve pojave neminovne... Nisam uz racunar da bih mogao vidjeti i rjesiti a necu moci ni danas ni sjutra. Napravite rezervnu kopiju FE baze pa onda pokusajte sami pronaci resenje- Igrajte se malo Siguran sam da su na vagonu samo 4 (pogledajte u tabeli vagon), ali na formama koje prikazuju stanje prikazuje X 3 zbog nepravilnog upita koji je izvor forme za prikaz.

_{[Ovu poruku je menjao nenadmarkoni dana 25.08.2014. u 14:25 GMT+1]}

Otvorite QTrenutnoNaKolima, pređite u Design mod, pređite u SQL mod, zamjenite postojeći upit ovim: Snimite izmjenu. Trebalo bi da je riješen problem prikaza 12 osovina

Rešeno. Sledeći problem: kada osovini odredim trenutno stanje preko forme OsovineLista/Osovine recimo "Vagon", vidim je na vagonu preko formi Kola/VagonLista ali je nama u formi "Dnevni izvestaj izgradnje i ugradnje..." (combobox je prazan). Kada osovinu ugradim preko fiktivnog naloga sve je u redu.

Trebalo bi da je imate u izboru na combobox u dijelu izgradjene osovine. Znaci kad kliknete na ovaj combobox u padajucoj listi bi trebalo da imate osovinu koju ste prethodno unijeli. Ako je nema onda je greska u Row Source polja OsovinaID.

Jeste li pokušali da napravite forme? Evo i ja sam nešta napravio na brzaka i vjerovatno će biti grešaka. Trebalo bi da sam i rješio i problem koji ste postavili u prethodnom postu. Povežite ovaj FE sa Vašim BE pa isprobajte slanje na investicionu opravku.

Pokušala ali nisam daleko dogurala. Vidim koje forme treba da se dodaju ali mi nije jasno kako bi trebale da izgledaju, pokušala da nadjem "sličnu" pa da kopiram/editujem ali nisam daleko dogurala. Puno bi mi lakše bilo kada bih imala malo konkretniji zadatak. Ja u ovome poslu sam na nivou deteta iz jaslica, ne mogu ništa bez vaspitačice.

Kompletno projektovanje baze podataka i izrada aplikacije koja je prati zasniva se na principima čiste logike. Sagledavanjem poslovnih procesa koji se javljaju u realnom sistemu projektuje se funkcionalni model baze. Obično se primjenjuje IDEF0 standard upotrebom case alata BPWin. Time se na slikovit način sagledavaju procesi(nesto nalik slici u prilogu) koji se javljaju u sistemu i koje aplikacija treba da prati. Na osnovu ovog modela izrađuje se informacioni model , uz uvažavanje detaljnih zahtjeva korisnika dobijenih intervjuom i uvidom u dokumenta koja se javljaju u sistemu( slike koje su prikazivane u prethodnim postovima). Tek kada se verifikuju ovi modeli kreće se u aplikativno modeliranje. Pri aplikativnom modeliranju meniji aplikacije treba da prate radne procese koje smo funkcionalnim modeliranjem uočili i analizirali time se obezbjeđuje da aplikacija prati realni sistem za koji se izrađuje. I pri aplikativnom modeliranju primjenjuje se logički sled npr. ne može se izgraditi osovina koja već nije na vagonu(izvor combobox-a u dijelu izgrađena osovina),ako saljemo osovinu na remont najprije moramo znati kojem remonteru je šaljemo(forma Remonter i subforma PregledOsovina su spojene poljem RemonterID-Child i Parent), ako vagon-kola idu na investicionu opravku i osovine koje su na njoj treba da pređu u status remont(akcioni upiti u pozadini)....
Kao što vidite krenulo je sa prostim pitanjem i tri tabele, a razvilo se u nešto mnogo ozbiljnije. Da Vas odmah upozorim da je sve naprijed urađeno samo pokazni primjer u cilju edukacije. Nije mi cilj da uradimo aplikaciju koja će Vam sa sigurnošću služiti u radu- to rade profesionalci koji se bave ovim poslom, meni je ovo samo hobi, a i ne mogu Vam kasnije pružiti tehničku podršku u održavanju aplikacije koje je neophodno. Prema tome nemojte se pretjerano pouzdavati da će aplikacija koju uradimo moći profesionalno da se primjeni.
Idemo dalje... Obzirom da smo uvelu još jednu vrstu dokumenta - Defektazna lista, po kojoj osovine takođe idu remonteru i od njega se vraćaju upit koji smo bili napravili da nam prikaze osovine koje su bile i koje su trenutno kod remontera neće funkcionisati ispravno( prikazuje samo osivine koje smo poslali putem Pregleda osovina). Ovde će morati već urađeni upit da se kombinuje sa sličnim upitom koji će prikazivati osovine koje su bile i koje su sada kod remontera , a koje su upućene Defektažnom listom. Ova dva upita spojićemo trećim koji se zove UnionQuery i objedinjuje dva i više upita u jedan.

Još jedno pitanje da bi rješili i vraćanje sa investicione opravke.
Kad vagon ode na investicionu opravku tamo skidaju osovine, kontrolišu ih i obrađuju. Da bi se bolje uklopile obično im mijenjaju mjesta na vagonu. Ukoliko je neka neodgovarajuća može li se desiti da postave i osovinu koja je kod remontera otišla u redovnom ili vanrednom remontu osovine? Ukoliko je neka osovina za otpis da li takođe može da se desi da iskoriste neku osovinu koja je na redovnom-vanrednom pregledu? Ukoliko ne postoji takva osovina onda traže da im pošaljete odgovarajuću, a neispravnu Vam vraćaju uz otpremnicu? Ako se već obrađuju i popravljaju osovine tada Vam šalju mjerni list na kome pišu šta je odrađeno na osovini. Ako je već ustaljeno da skidaju i obrađuju osovinu onda mi je logično da se sa investicione opravke vraćaju uz Mjerni list? Pomalo je zbunjujuće pa ako možete odgovorite i malo bolje opišite ovaj proces.
I da, zaboravio sam da pitam, grešku u serijskom broju može da uoči isključivo Remonter i da Vas o tome obavjesti kroz otpremnicu?

_{[Ovu poruku je menjao nenadmarkoni dana 28.08.2014. u 21:41 GMT+1]}

Nisam juče stigla ni da priđem kompjuteru (polaze deca u školu). Ne, ne skidaju osovine, ako nema nekog oštećenja osovine se samo otvaraju (dok su na vagonu) i proverava se ležaj osiguranje i mast, samo u veoma retkim slučajevima se desi da ih skinu pa obrade i onda promene mesta. Do sada se obično dešavalo da vagoni idu kod "drugog" remontera (recimo tokom cele godine osovine idu u Smederevo a onda pred kraj godine vagoni odu Ćupriju, gde nema naših osovina). Veoma je teško da se desi da ode oštećena osovina sa Vagonom u Reviziju, to sve kontrolišu majstori svakodnevno, pretpostavljam da je nemoguće da ode sa vagonom neka osovina koja je neupotrebljiva (za otpis) ali sam ostavila tu mogućnost (to se verovatno nikad neće desiti, sve to je moja pretpostavka, tako ste me naučili da razmišljam). Uobičajeno je da vagoni odu i vrate se sa istim rasporedom osovina, malo je ređi slučaj da se raspored menja (prečnik ili neki rugi razlog), najređi slučaj je da se neka obrađuje. Nikad se nije desilo da osovina koja je otišla sa vagonom bude škart. Vagoni se vrate, dan dva pre nego što stignu "Merne Liste" (u tom slučaju merne liste idu poštom).
Grešku u serijskkom broju nekad uoči remonter (prilikom otvaranja osovine) a nekad ja (pošto sam ubacujući u excel tabelu pronašla puno duplikata). Kolega koji je radio taj posao pre mene je bio star slabo je video a i nije se puno mešao u svoj posao, to je i proizvelo najveći broj grešaka, ja nameravam da te greške ispravim do kraja ove godine i to se više neće dešavati. Pre mesec dana imala sam 68 prebrojanih problema (pogrešnog broja) trenutno ih ima samo 7. Kada jednom budem sredila brojeve(a to će biti do kraja ove godine), takve greške se više neće dešavati.

edit: pitala kolegu, može da se desi da pođaljem kod istog remontera vagone, pa da ubace neku osovinu koja je već kod njih.

_{[Ovu poruku je menjao marija.ana dana 29.08.2014. u 15:50 GMT+1]}

Kasno sam pročitao izmjenu. U skladu sa prethodnim opisom dodao sam još jednu tabelu PovratnaDefektaznaListaIzmena gdje se evidentira vrsta izmjena koje se mogu javiti, i povratnu vezu na DefektaznaLista gdje se evidentira koja PovratnaDefektaznaLista razduzuje onu koju ste poslali. Zbog pretpostavke koju sam imao sam i pitao, jer i ta mogućnost je trebala da se doda, ovako moraće opet da se mijenjaju usovi u upitima. :-(
I ovako je dovoljno teško, nemojte dodatno otežavati sa nepreciznim odgovorima.

Prekomplikovano za mene. Ne samo da ne mogu da napravim formu da izgleda i funkcioniše kako treba, već ne mogu da ispravim ni nešto što otprilike i znam. Celu noć pokušavam da ispravim "Dnevni Izveštaj". Kod "izgrađene osovine" polje Serijski Broj se ne vidi posle unosa. Pretpostvaljam da "serijski broj prikaz" ostane sakriveno kada fokus predje na "prečnik". Stvar je pretpostavljam trivijalna ali ja ne mogu da nađem grešku. Možda nisam ni gledala gde treba, moja je pretpostavka da "serijski broj prikaz" služi samo za prikaz na ekranu i da je greška u After Update ili On Got Focus nekog "povezanog" polja.

Udjite u formu u Design Mod , izaberite polje SerijskiBrojPrikaz, u Meniju idite na Format i izaberite Bring to front. Međutim nije to najveći problem, vidim da forma sporo radi-baguje jer vjerovatno ima veliki broj proračuna. Nažalost ja nisam u stanju da ovo riješim što je i dokaz da komplikovanije aplikacije treba da rade profesionalci.

Meni sve to ni ne treba, treba mi samo evidencija. Koliko ima kojih (tip, godiste). Koliko na stanjima (vagon, remont, neispravna, zaliha). Podatke o poslednjem remontu osovine. Prethodna verzija je funkcionisala . Ne treba mi revizija vagona to mogu ručno (od 10 vagone koji odu promeni se raspored ispod jednog), u principu samo treba da upišem datum revizije i eventualno da promenim pozicije. Revizija vagona i defektažne liste nisu moj posao. Moje su samo osovine.

_{[Ovu poruku je menjao marija.ana dana 01.09.2014. u 01:18 GMT+1]}

Poenta cijele price je bila da se nauci nesta o principima izrade baza podataka i realizaciji aplikacije u MS Access. Kao sto ste vidjeli baza podataka se ne projektuje onoliko koliko Vam treba, vec onoliko siroko koliko to zahtjeva realni sistem koji se preslikava u informacioni. Najprije smo kroz Vase opise sistema uocili radne procese koji se javljaju u sistemu, entitete koji ucestvuju u tim procesima i atribute tih entiteta. Zavisnoscu izmedju entiteta uspostavili smo relacije i odnose. U prvoj verziji niste u potpunosti bili opisali sistem pa smo pojedine procese bili izostavili i nismo bili dobro odredili primarni kljuc za tabelu Osovina. Ovo je zahtjevalo reinzenjering pa smo morali da prepravljamo. Ono sto sam uocio kroz moje skromno iskustvo sa Access-om je da zna da se cudno ponasa nakon ovakvih prepravki. Zasto, to ne znam!? Sto se tice realizacije aplikacije, pored ispravno postavljenog modela i pracenja radnih procesa potrebno je koliko se to moze uvaziti i detaljne zahtjeve korisnika, kao i omoguciti kontrolu unosa cime se smanjuje mogucnost unosa nepravilnih podataka. Tok same izrade aplikacije i uspjesnost zavise od znanja i iskustva, mada je i uz to cin izrade borba da se aplikacija "natjera" da uradi ono sto hocete. U toku njene izrade uocavajju se izostavljeni entiteti i atributi, pogresno uspostavljene relacije,itd. Znaci i tokom izrade aplikacije, neminovno se mijenja model a time i BE baze. U toku izrade funkcionisanje se provjerava uvodjenjem testnih podataka. Tokom izrade aplikacije takodje se uocava koji dio moze da se automatizuje a koji ne. Kada se postigne puna funkcionalnost pristupa se testiranju i debagovanju. I u ovom procesu desavace se promjene koje bi trebale da doprinesu boljem i brzem radu aplikacije. Time se dobija prva funkcionalna verzija aplikacije. Ni ta verzija nije konacna jer se kroz uvodjenje i testiranje od strane korisnika uocava sta se izostavilo, ili sta bi trebalo da funkcionise drugacije pa se to kroz sledece verzije dodaje i doradjuje. Zbog toga je bitna tehnicka podrska ukoliko niste sami izradili aplikaciju. Ja sam se potrudio da Vam sve ovo prezentujem kroz primjer na realnom sistemu koji je u fokusu Vase paznje. Vas zadatak je bio da sa paznjom dobrog studenta propratite i uocite koje procese realizujemo kojim formama, koje djelove procesa automatizujemo, kako funkcionise koja forma i kojom dinamikom, a sve to prateci slike procesa informacionog modela koje sam Vam prikazao. Mi jos nismo rjesili sve procese, pa samim tim nismo ni postifli punu funkcionalnost. Ima jos puno,puno posla... ;-)

Ne mogu da shvatim zašto javlja grešku kada kod izgradnje navedem "uklapanje", javi poruku da će osovina preći na "zalihu" a onda poruka o grešci... a sve uradi kako treba koliko se meni čini (osovina zaista promeni stanje u zaliha). Takođe kod slanja na remont pomoću otpremnice ne mogu da unesem "zahtevani rad" (forma remont), javlja grešku "You must enter a value in the 'RemontZahtevaniRad.TrenutakPrelaza' field.". Isto je i kod "Otpremnice" ne može da se unese "Izvršeni rad". Sem toga osovina normalno menja stanje iz remonta u zalihe, i koliko vidim sve ostalo radi.

_{[Ovu poruku je menjao marija.ana dana 05.09.2014. u 20:57 GMT+1]}

U prvom slučaju na subformi NeispavnaNeispravnost , na AfterUpdate event polja OsovinaID imate kod koji:
-Isključi upozorenja
-Pozove 2 akciona upita koji dodaju zapis u PracenjePromeneStanja i Zaliha
-Uključi upozorenja
-Osvjezi subformu PracenjePromeneStanja na formi Osovina.
Pošto forma Osovina nije aktivna u ovom trenutku Access prijavljuje grešku.
Umjesto ovakvog osvjezavanja forme upisite:
Call RefreshForm("PracenjePromeneStanja") . Ova linija koda poziva funkciju RefreshForm koja omogucava da ukoliko forma nije otvorena nastavi dalje i ne prijavi gresku, a ukoliko je otvorena osvjezi formu.
U drugom slučaju nisu određeni ChildField i MasterField između forme Remont i subforme RemontZahtevaniRad pa prijavljuje grešku jer se ne preslikava zahtjevani podatak.



_{[Ovu poruku je menjao nenadmarkoni dana 05.09.2014. u 21:20 GMT+1]}

Sjutra idemo dalje. Čini mi se da Vam je i dalje pažnja usmjerena na unos podataka. Tako nećete mnogo naučiti.
Potrebno je da otvorite sliku procesa npr. Evidentiranje osovine, pa za taj proces propratite sta se dešava od pritiska na dugme u meniju koje prati taj proces ( proučite kod koji je na OnClick), preko forme za pregled i unos ( sta se desava na koji event te forme, i razmislite zašto je to tako, pa preko dugmeta na toj formi koje otvara sledeću formu itd... i tako za svaki proces i sve forme. Sva ta dešavanja bi trebalo da prate logički sled radnji. Primjetio sam da sam pogrešno zamislio proces Zamena osovine na investicionoj opravci i tu ćemo morati mjenjati...

Prva verzija spremna za testiranje.Vjerovatno ima puno grešaka. Kao što sam rekao za proces Zamjena osovina na investicionoj popravci izvršene su izmjene kao na priloženoj slici.
Sad bi trebalo proći kroz svaku formu, ispraviti greške,uobličiti svaku formu, ispraviti i popraviti upite i izvore za combobox-ove, razmisliti gdje ima logike nešto brisati a gdje ne pa prema tome zaključati polja ili čitave forme....
Vi doradite upite i izvještaje za izlistavanje osovina kojima ističe 45 godina u narednoj godini ili kojima će naredne godine biti 4 godine od poslednjeg remonta pa i to dodajte u meni. Od mene toliko .... Srećno!

_{[Ovu poruku je menjao nenadmarkoni dana 06.09.2014. u 23:21 GMT+1]}

Našla dve greške u formi Remont. U formi QRemontZahtevaniRad je bila greška u kucanju umesto NazivZahtevanogRada je pisalo NazivRada. Drugu grešku se ubih da sredim ali ne vredi, ZahtevaniRrad se troši, kada se upotrebi za jednu osovinu više ga nema. Isti je problem i sa Formom Zaliha (IzvršeniRad). Tri dana već gledam u "Neispravnost" znam da smo tamo imali isti problem (Neispravnosti su se trošile). Otprilike vidim gde je razlika i šta je greška ali ne vredi ne mogu da nateram da radi kako treba.

Pogledajte da li je sada u redu? Ako jeste onda je greška bila u mapiranju uslova u upitima QZalihaIzvrseniRadZauzet , QRemontZahtevaniRadZauzet kao i u mapiranju uslova na Row Source polja IzvrseniRadID i ZahtevaniRadID formi ZalihaIzvrseniRad i RemontZahtevaniRad. Ti uslovi su gledali na pogrešno mjesto :-)

_{[Ovu poruku je menjao nenadmarkoni dana 09.09.2014. u 21:06 GMT+1]}

Imate isti problem u formi VagonMernaLista i subformi VagonIzvrseniRad koja koristi upit QVagonIzvrseniRadZauzet. Ako smo u prethodnom postu rješili problem, pokušajte na isti način da riješite i ovaj...

I dalje se troše. ili ja nešto grešim.

_{[Ovu poruku je menjao marija.ana dana 10.09.2014. u 01:59 GMT+1]}

I treba da se trose za jedan unos, ali u sledecem treba da se pojave.

Svesna sam toga, kod mene se ne pojavljuju u sledećoj. Da nisam ja nešto pogrešila?

Niste Vi pogrješili , već ja. Vezao sam u Row Source polja ZahtevaniRadID upit QRemontZahtevaniRad umjesto QRemontZahtevaniRadZauzet pa je davalo pogrešno. Evo ispravljeno.

Takođe se potkrala greška u nazivu polja i kodu na On got focus( DoCmd.requery...)- nije ga bilo :-)

Ispravljeno još par sitnica

Mene query ubiše u pojam, već dva dana gledam i ne mogu da shvatim... Otpremnica pokazuje po četiri kopije od svake osovine. Forma ZalihaIzvršeniRad, kada ispravim QZalihaIzvrseniRad (greška u kucanju piše IzvrseniiRad umesto IzvrseniRad), ne prikazuje ništa. Upoređivala sam i sa RemontZahtevaniRad i sa NeispravnaNeispravnost ali ne mogu da shvatim gde je greška.

Pa rekao sam da ima mnogo grešaka.
Prepravio sam upit za izvor comboboxa u formi Otpremnica.
Ubacio sam još jednu tabelu u BE- VagonIzvršeniRad, jer onako kako sam bio vezao nije moglo.

Nesto sam eksperimentisala. Čini mi se da ako se u properties polja SerijskiBrojPrikaz, "Locked" podesi na "Yes" a "Enabled" na "No", forme bolje funkcionišu.

Mislim da Vam se samo čini. Sporost rada je zbog proračuna koji se odrađuju u pozadini, ali je ispravno da ovo polje bude zaključano. Zamutili smo ga žestoko.
Evo još malo mućkanja.

Nisam mislila brzinu, već na način unosa podataka. Ako je Locked "Yes" a Enabled "No" (polje SerijskiBrojPrikaz), klik u polje je u stvari klik u SerijskiBroj i funkcioniše unos podataka. Ako je Locked "Yes" i Enabled "Yes" posle klika u polje ne funkcioniše unos podataka (pošto smo u stvari kliknuli u SerijskiBrojPrikaz), mora da se klikne na trouglić od combobox-a.

I još par sitnica dorađeno u dijelu zamjene osovine na investicionoj opravci.
Da bi mogli da planirate koje osovine naredne godine treba da se otpišu, odnosno koje osovine treba poslati na redovni remont treba Vam izvještaj o ovome. Potrebno je napraviti dva upita i dva izveštaja, a na komandnoj tabli potrebno je dodati pristup ovim izvještajima. Pokušajte ovo da napravite i dodate.

Ovo sa poslednjim remontom mi više treba kao mesečni izveštaj. Čini mi se da mi je sve potrebno za taj izveštaj u "QPoslednjiRemontUnijaFiltar"?
Napravila sam novi query QIstekRevizije U njemu so potrebna polja iz Query-ja "QPoslednjiRemontUnijaFiltar" i tabele "Osovine" plus novo polje "PreostaloDoistekaRevizije:1460-(DateDiff("d";[Datum];Date()))" kome je criteria "<60 and >30". Tako sam dobila osovine kojima isti;e revizija za 60 dana (sa njima treba da planiram). Pretpostavljam da moram da napravim novi query sa uslovom "<30" (osovine kojima ističe revizija u tekućem mesecu, tako da se Vagoni pod kojima su mogu na vreme isključiti iz saobraćaja).

Što se tiče godišta gledam direktno u tabelu Osovina (find duplicate query radi posao). Da li sam u pravu? Sa jednom malom izmenom, ovaj izveštaj bih napravila malo opširnije (koliko osovina ukupno po tipovima ima: "u svakom godištu", koliko je kod remontera, koliko neispravnih, koliko na vagonima, koliko rezerve.



<sub>[Ovu poruku je menjao marija.ana dana 15.09.2014. u 14:47 GMT+1]

[Ovu poruku je menjao marija.ana dana 15.09.2014. u 15:07 GMT+1]</sub>

Evo malo kao ideja - taster Izveštaji

U poslednje dve verzije ne radi Izgradnja osovina. Preko Novog praznog dnevnog lista se ne mogu izgraditi osovine. Stari dnevni list u kojima je neka osovina već izgrađena radi... Ne shvatam.

Negdje smo poremetili nesta. Trenutno nisam uz racunar, vidjecu popodne, a mozete i da izbrisete forme koje ne rade pa da ih uvezete iz verzije koja radi.

Bio je loše postavljen uslov na combo OsovinaID u formi Izgrađene da ne prikazuje ugradjene osovine sa tog radnog lista pa on nije prikazivao ništa, moraće se drugačije uraditi- slično kao sa upitima za pracenje zauzetih radova i neispravnosti. Izvinjavam se, trenutno nemam vremena da ovo osmislim pa ako Vam smeta ovakvo stanje pokušajte napraviti.

Kada i kako se apdejtuje polje "pozicija" u formi za izgradnju? U poslednjoj verziji ne prikazuje ovaj podatak.

Polje pozicija je pokriveno drugim poljem koje ga sakriva do ucitavanja osovine na koju se odnosi, jer bi prikazivalo gresku (nema podatka o kojoj se osovini radi). Kada se ucita osovina to polje gleda na poziciju te osovine dok je bila u statusu vagon, a polje koje ga je sakrivalo se sakriva. Pogledajte upit koji je izvor podataka za formu i ono sto se nalazi u polju pozicija pa propratite.

Bio je postavljen uslov u polju Pozicija da prikaze poziciju iz QVagon za trezenu osovinu i gdje je RBr= StariRBr-1 što nije bio pravilan uslov trebalo je gdje je RBr = StariRBr. Evo sada radi.
ps. Ovaj uslov neće odgovarati za prikaz vracene osovine na formi Otpremnica za koji je izgleda bio postavljen prethodni uslov, pa sam napravio kopiju upita QNeispravna i nazvao ga QNeispravna1 gdje je ostao stari uslov i on će biti izvor podataka za subformu OtpremnicaZalihaOtpremnicaNeispravna- slučaj kada se neispravna osovina vraca umjesto Defektaznom listom Otpremnicom.

_{[Ovu poruku je menjao nenadmarkoni dana 18.09.2014. u 22:08 GMT+1]}

Čudna greška, sada svaka neispravnost vodi u "Skart".

Desava se, zato se i testira. Greska je na kodu koji se nalazi na After update polja NeispravnostID . Nesta nije dobro napisano.

Evo ispravke u dijelu evidentiranje Neispravnosti i IzgradjeneOsovine Radnog lista. Istestirajte. Jeste li rješili prikaz onih izvještaja za otpis i remont?

Ne sstižem već dva dana da sednem za kompjuter.
Ovo za istek četvorogodišnje revizije sam rešila. Dva queryja (jedan za osovine kojima ističe revizija <60 i >30 dana i jedan za osovine kojima ističe za <30 dana). Ovo zo osovine kojima ističe radni vek je lako čak i za mene.

Kad smo već kod šifrarnika, šifrarnik Tip javlja grešku kada se klikne na "detaljno" pretpostavljam da je trebalo da prikaže "osovine lista" filtrirano po tipu. Da li je moguće uraditi "dugmence" detaljno i na šifrarniku stanje?

Moguće je. Ja se ovde isključujem definitivno. Baza nije perfektna, mnoge forme i upiti koče, kod je napisan potpuno amaterski, ali šta je tu je. Ako sam uspio da pomognem drago mi je, ako nisam bar sam pokušao. Sigurno je da sada znate malčice bolje nego što ste znali. Srdačan pozdrav i srećno!

Ovo meni deluje veoma profesionalno. Nadam se da ću nekada uspeti da dostignem Vaš "amaterski" nivo. Puno ste mi pomogli, ne možete ni zamisliti koliko. Puno sam i naučila ali tek treba da učim. Najlepše Vam hvala.