- YouTube
- Bocsánatot kért az Apple, mert nagyon mellélőtt a legutóbbi reklámjával
- Visszavonta az Intel és a Qualcomm Huawei-hez kiadott exportlicencét az USA
- Milyen routert?
- Google Chrome
- Windows 11
- Windows Insider Program
- AutoCAD
- Már nem hisz a nagy európai EV-forradalomban a Ford
- Milyen program, ami...?
Új hozzászólás Aktív témák
-
sszever
őstag
Megnézem
A vonalkód nyomtatásról még valamit: van egy komplett jelentés, ahol az összes bevitt (és nem törölt termék szerepel), ott is kighagy 1-2 esetben vonalkódot (minden más infó megvan).
Mivel ez jelenleg egy 30 napos teszt verzió, és mivel arra esély sincs, hogy a fenti lekérdezésben nem volt elég idő az infó mentéséhez és lekérdezéséhez, így gondolom ezt betuthatom a TRIAL verzió korlátozásának. ??Csak egy ember hiányzik, és máris üres a világ!
-
rebel56
tag
Sziasztok! Lesz a következő hetekben még jópár kérdésem.. Most egy olyannal találkoztam, hogy leraktam egy parancsgombot, ami egy másik űrlap megnyitására szolgált volna, de ezt sehogysem tudtam beállítani vele, a kifejezésszerkesztővel próbálkoztam. (Varázslóval persze sikerült utána, csak érdekelne a technika anélkül is.)
-
jeges
senior tag
ha modulból akarod vezérelni (ami szerintem gyorsabb és ''tisztább''), akkor a szellem kollega által leírtaka próbáld, azaz
létrehozol egy lekérdezést, ami a kivánt rekord adatait hozza le (gondolom vmiféle paraméterezéssel)
létrehozol egy riportot, lehetőleg varázslóval, mer' úgy egyértelmű a dolog, a fontos az, hogy az előző lekérdezésen alapuljon (azaz a forrása az a lekérdezés legyen).
az űrlapra kiteszel egy parancsgombot, aminek a tulajdonságai közt a 3. fülön vannak az eseményvezérelt eljárások. létrehozol egy modult hozzá (azaz ''eseményvezérelt eljárás'' az onclick-re), és a modulba ezt írod:
if me.dirty then
DoCmd.DoMenuItem acFormBar, acRecordsMenu, acSaveRecord, , acMenuVer70
DoCmd.OpenReport ''Jelentés neve'', acViewNormal
me.close
sajna itthon továbbra sincs access, úgyhogy csak fejből írtam, a domenuitem parancsra csak halványan emlékszem...lehet, hogy acrecordmenu, vagy csak acsave, de alapjában a fentiről van szó.
az openreport parancsot így is tudod paraméterezni, hogy csak az aktuális rekordra legyen szűrve az űrlapról, de ez most fejből nem fog menni... -
jeges
senior tag
a linkcriteria csak akkor köll, ha szűrni is akarod az űrlapot
ölég csak az openform parancs, pl. docmd.openform ''űrlap neve''
rebel: ha ''általában'' érdekel a dolog, javallom a help-et. sok jól használhat dolog van benne. én a macro-s megoldásokat nem szeretem, a modulban sokkal jobban paraméterezhetők a dolgok, és gyorsabb a végrehajtás is. -
sszever
őstag
Csináltad nekem a minap a keresést.
Azt hogy lehet belevinni, hogy csak azokat az eredményeket adja ki, ahol a foglalt=igaz, azokra pedig, ahol a foglalt=hamis hibaüzenetet küldjön? (pl. Azt, hogy: a termék még nem lett lefoglalva)?Csak egy ember hiányzik, és máris üres a világ!
-
sszever
őstag
Nos az alábbi módon oldottam meg:
ha igaz, kiírja az eredményt, ha hamis nem csinál semmit (erre kitalálok még valamit)
Viszont, ami nagyon zavar:
van lent a lábrészben az űrlapnak a rekordléptetés része. Azt hogy lehet eltüntetni???Csak egy ember hiányzik, és máris üres a világ!
-
-
sszever
őstag
S melyik részébe kell beszúrni?
Private Sub Form_Load()
DoCmd.GoToRecord , , acNewRec
End Sub
Private Sub Parancsgomb2_Click()
DoCmd.GoToRecord , , acNewRec
If IsNull(Szöveg0.Value) Then
MsgBox (''Keresés előtt kötelező a mező kitöltése'')
Szöveg0.SetFocus
Szöveg0.BackColor = 11053311
Else
vagatkod.SetFocus
DoCmd.FindRecord Szöveg0.Value, acEntire, False, acSearchAll, , acCurrent, True
Szöveg0.BackColor = 16777215
End If
End Sub
Private Sub Szöveg0_BeforeUpdate(Cancel As Integer)
End SubCsak egy ember hiányzik, és máris üres a világ!
-
Gh0sT
addikt
Private Sub Parancsgomb2_Click()
DoCmd.GoToRecord , , acNewRec
If IsNull(Szöveg0.Value) Then
MsgBox (''Keresés előtt kötelező a mező kitöltése'')
Szöveg0.SetFocus
Szöveg0.BackColor = 11053311
Else
vagatkod.SetFocus
DoCmd.FindRecord Szöveg0.Value, acEntire, False, acSearchAll, , acCurrent, True
Szöveg0.BackColor = 16777215
Szerintem itt jó lesz
End If
End SubSoha nem késő, hogy azzá válj, aki lehettél volna.
-
sszever
őstag
Option Compare Database
Private Sub Form_Load()
DoCmd.GoToRecord , , acNewRec
End Sub
Private Sub Parancsgomb2_Click()
DoCmd.GoToRecord , , acNewRec
If IsNull(Szöveg0.Value) Then
MsgBox (''Keresés előtt kötelező a mező kitöltése'')
Szöveg0.SetFocus
Szöveg0.BackColor = 11053311
Else
vagatkod.SetFocus
DoCmd.FindRecord Szöveg0.Value, acEntire, False, acSearchAll, , acCurrent, True
Szöveg0.BackColor = 16777215
If foglalas.Value = False Then
MsgBox (''Az temék még nem lett lefoglalva'')
End If
End If
End Sub
Private Sub Szöveg0_BeforeUpdate(Cancel As Integer)
End Sub
Így? Mert nem csináljaCsak egy ember hiányzik, és máris üres a világ!
-
Gh0sT
addikt
Megnéztem, egy gond van vele:
Az űrlap ugye egy SQL lekérdezésen alapul, amiben a foglalas-hoz az igaz érték van hozzárendelve (ergo csak azok a termékek jelennek meg, amelyek le vannak foglalva). Annyi a dolgod, hogy ezt a feltételt kiveszed.
Magyarán: keress most rá mondjuk a 14. termékre
Találat: nem lesz, mert alapból úgy hívod meg a lekérdezést, hogy kiszűröd a le nem foglalt termékeket.
Teendő:
Szerkeszted az űrlapot, tulajdonságok, adat, rekordforrás, ...
Bejön ugye a lekérdezés, amiben a foglalás mező alatt kitörlöd az Igaz feltételt.
Ennyi.Soha nem késő, hogy azzá válj, aki lehettél volna.
-
Gh0sT
addikt
Nem, nem gond.
Módosítod a kódot:
Private Sub Form_Load()
DoCmd.GoToRecord , , acNewRec
End Sub
Private Sub Parancsgomb2_Click()
DoCmd.GoToRecord , , acNewRec
If IsNull(Szöveg0.Value) Then
MsgBox (''Keresés előtt kötelező a mező kitöltése'')
Szöveg0.SetFocus
Szöveg0.BackColor = 11053311
Else
vagatkod.SetFocus
DoCmd.FindRecord Szöveg0.Value, acEntire, False, acSearchAll, , acCurrent, True
Szöveg0.BackColor = 16777215
If foglalas.Value = False Then
MsgBox (''Az temék még nem lett lefoglalva'')
Ide kell beírni egy olyan kódot, ami letiltja a kivételezést. Ha ezt a kivételezés kapcsolóval csinálod, akkor csak ennyi:
kiadva.Enabled = False
End If
End If
End Sub
Szerk.: esetleg
kiadva.Visible = False
Bár szerintem elegánsabb egy olyan megoldás, hogy rejted a kapcsolót és beraksz a helyére egy parancsgombot (Parancsgombx) Kiadás felirattal.
Ennek a click eseményéhez hozzárendeled az alábbit:
If kiadva.Value = False then
kiadva.Value = True
Parancsgombx.Caption = ''A termék kiadva''
else
kiadva.Value = False
Parancsgombx.Caption = ''Termék kiadása''
End If
Fentebb pedig a Parancsgombx.Enabled tulajdonságát engedélyezed, vagy tiltod.
[Szerkesztve]Soha nem késő, hogy azzá válj, aki lehettél volna.
-
jeges
senior tag
nekem nem egyértelmű: az a cél, hogy az űrlapon csak a kiadott vagy kiadható (azaz lefoglalt vagy nem lefoglalt) cikkek látszanak, vagy a foglalhatóság megteremtése? szellem kollega megoldása gyakorlatilag a lefoglalás műveletét oldja meg, ha jól értem, de most úgy tűnik, nem ez a feladat. (''ha le nem foglaltra nyomok, akkor is lefoglalja'')
ghost: én az ilyesmit esetleg váltógombbal szoktam csinálni, azon is egyértelműen látszik, mi az ábra. -
Gh0sT
addikt
A váltógombbal szerintem akkor lesz gond, ha mondjuk egy termék ki van adva és nem szeretnénk, hogy az visszavehető is legyen. Ilyenkor a radio buttonban le lehet titalni az egyik tagot? Igazából váltógombot még nem használtam soha.
Szerk.: jah, le lehet tiltani az egészet.
[Szerkesztve]Soha nem késő, hogy azzá válj, aki lehettél volna.
-
sszever
őstag
Király ebben már.
Azért gondoltam, hogy jobb lenne ha a bezár gomb helyett a termék kiadása gombra kattintva be is zárná (majd újra megnyitná), mert így , ha véletlen kétszer megnyomja a kollega akkor a kiadást már vissza is vonta.Csak egy ember hiányzik, és máris üres a világ!
-
jeges
senior tag
így van, de a váltógomb alatt azt a típust értem, amelyik ha benyomod, úgy is marad, ha meg kinyomod, akkor is úgy marad. a nem visszavehetőség, ha jól értem, egy másik tulajdonság, valamint a kiadottság feltétele. azaz akár ki van adva (kiadva=true), akár nem visszavehető (visszaveheto=false), le köll tiltani. oszt jónapot
a váltógomb ugyanúgy használható, mint a normál gomb, előnye, hogy forrástulajdonsága is van, azaz mint a checkbox, egy létező boolean változóra mutat rá. -
Gh0sT
addikt
Még egy fontos dolog!!!
Látom, hogy az azonosítást számlálóval oldod meg. Ha többen használjátok a táblát, akkor ez a megoldás hibát fog eredményezni. Ez akkor következik be, amikor egyszerre ketten is rögzítenek terméket és a számláló mindkét esetben ugyanazt az értéket kapná. Vagyis igazából nem kapja, de valamiért ilyenkor ketté válik az adatbázis. A felek nem fogják látni a másik által rögzített termékeket.Soha nem késő, hogy azzá válj, aki lehettél volna.
-
Gh0sT
addikt
Tényleg, biztosan tudsz nekem ebben segíteni:
Adott egy üzleti terület, akik berögzítenek az adatbázisba egy ügyletet. Az ügylet azonosítójának generálása a háttérben történik. Tehát nem a user adja meg az azonosítót, hanem kódból kell legenerálni. Van erre valami tuti módszer, hogy ne legyen duplikáció és hibaüzenet?
Egyelőre annyit csináltam, hogy a mentés gombra klikkelve egy 0 és 10 millió közötti véletlenszámot generálok, és az lesz az azonosító. Jó esetben kicsi az esély arra, hogy kétszer ugyanaz a szám lenne az azonosító, de valahogyan lehet ezt csekkolni a mentés előtt?Soha nem késő, hogy azzá válj, aki lehettél volna.
-
jeges
senior tag
nem teljesen értem: a számviteli bizonylatok általában sorszámozottak. ez nem feltétlen access-féle számlálót jelent, de azt jelenheti, hogy pl. egy típusú ügyletek emelkedő számsorrendben sorszámozottak.
a véletlenszám generálást nem szokás használni, már csak azért sem, mer' elegendően nagy számosság esetén már megfelelően nagy a duplikátumok valószínűsége.
miért lenne jó a véletlenszám?
#385: access 2005öt még csak távolról láttam
[Szerkesztve] -
Gh0sT
addikt
Én ezt úgy oldottam meg, hogy meghagytam az azonosítót számlálónak és a tábla tervező nézetében átállítottam véletlenszerűre az értékadást. Ezzel ugye szinte biztos, hogy egyedi értéket fogsz kapni mindig és nem fognak eltűnni az adatok.
Hátránya, hogy a user nem fogja ismerni az azonosítót. Ezért itt beraktam egy azonosító1 nevű mezőt, amit ő adhat meg és igazából semmilyen célt nem szolgál, csak keresni lehet rá.Soha nem késő, hogy azzá válj, aki lehettél volna.
-
Gh0sT
addikt
Nem kimondottan számvitelről lenne szó.
Szóval:
Az ügyleteknek adunk ugyan számot, de elég érdekesen. Adott az üzleti terület, ami felrögzíti az ügyletet és nem ad neki számot (egész egyszerűen azért, mert nem ismeri a számadás szintaktikáját). Az ügylet átkerül az elemzésre és itt kap egyedi azonosítót. Ergo az üzleti területen nincs mivel azonosítani az ügyletet, mert csak egy másik területen kap majd tényleges számot. Valahogyan azonban már a rögzítés pillanatában adnom kell neki valami azonosítót. Na erre használom én a véletlenszámos módszert. Sajnos nem tudok jobbat.Soha nem késő, hogy azzá válj, aki lehettél volna.
-
jeges
senior tag
a többszörös azonosító nem rossz megoldás, és úgy látom, Te is ilyesmit használsz. ha jól értem, a probléma leginkább a konkurrens felhasználók miatt merül fel. én csak annyit mondtam, hogy amennyiben ''látható'', visszakereshető azonosítót akarsz adni az ügyeknek, úgy általában a szigorú sorszámozás a célravezető, de az nincs kikötve, hogy a sorszámozás nem történhet úgylet-típusonként, vagy még inkább felhasználónként...
egyébként attól még, hogy az üzleti terület nem tudja, hogyan képződik a sorszám, attól még a program tudhatja.
szerintem akkor lehet kavarodás a véletlen generálásból, ha nincs tisztességes archiválási rend. ha van, azaz ''rendes'' kereshető ID-vel nem rendelkező ügyletek kikerülnek az adatbázisból, úgy nem valószínű, hogy gond lenne. egyébként ellenőrizni nem nagyon kell, mer' ha duplikátum születne, az hazavágja a tranzakciót, rosszabb esetben az adatbázist is. -
Gh0sT
addikt
''egyébként attól még, hogy az üzleti terület nem tudja, hogyan képződik a sorszám, attól még a program tudhatja.''
Az a baj, hogy nincs rá konkrét algoritmus. Illetve van, de rohadtul bonyolult.
Visszatérve a problémára: tegyünk fel egy abszurd példát. 1-50 között generálok véletleszámot (csak hogy érthető legyen a példa). Ilyenkor ugye egyre nagyobb a valószínűsége annak, hogy olyan szám lesz generálva, ami már foglalt. Azt kellene megoldanom, hogy ne legyen hibaüzenetem a tárolás gombra nyomva, hanem fusson le valami rutin (biztos van valami ellenőrzés, mert hibát azt kapok duplikációnál), ami ellenőrzi a meglévő kódokat és ha már létezőt talál, akkor generáljon újra kódot.Soha nem késő, hogy azzá válj, aki lehettél volna.
-
jeges
senior tag
ilyet pl. dsum függvénnyel tudsz kódban csinálni.
az OK gomb megnyomásakor úgy generálod az ID-t, hogy az adatbázisban a dmax+1-gyel legyen egyenlő. ID=dmax(table.ID)+1
sajna ez sem tuti, de egy fokkal jobb a tapasztalatok szerint.
lehet esetleg olyan rendszert csinálni, hogy a usereket megjelölöd 1-től valamilyen range-et kiszakítva minden usernek (pl. 1 millió helyet adsz mindenkinek), majd megnézed, hogy az adott user mely ID-ket rögzítette, ezeknek veszed a maximumát (dmax), és ennél eggyel nagyobbat adsz a rekordnak.
Új hozzászólás Aktív témák
- Dragon Age: Origins
- Luck Dragon: Asszociációs játék. :)
- Konzolokról KULTURÁLT módon
- Apple notebookok
- Samsung Galaxy S22 és S22+ - a kis vagány meg a bátyja
- Autós topik látogatók beszélgetős, offolós topikja
- AMD Ryzen 9 / 7 / 5 / 3 5***(X) "Zen 3" (AM4)
- Honor Magic6 Pro - kör közepén számok
- Vallás
- Motorolaj és szűrő topik
- További aktív témák...
Állásajánlatok
Cég: Ozeki Kft.
Város: Debrecen
Cég: Promenade Publishing House Kft.
Város: Budapest