Új hozzászólás Aktív témák
-
lordring
aktív tag
-
jeges
senior tag
közben leteszteltem, #495nek működnie kell, mer' nálam numerikus és string változók esetében is működött.
-
jeges
senior tag
-
lordring
aktív tag
Köszönöm a segítséget.
Most ott tartok, hogy erre már nem jelez hibát:
SELECT Promotion.[Order No], cikkszám.F1, Promotion.[Designation-C/B], Promotion.Grade, Promotion.Quantity, Promotion.[Order Date], Promotion.[Handling No], Promotion.State
FROM Promotion LEFT JOIN cikkszám ON (Promotion.Grade = cikkszám.F3) AND ((Promotion.[Designation-C/B] = cikkszám.F2) OR (isnull(Promotion.[Grade]) and isnull(cikkszám.F3)))
Csak sajnos azokat továbbra sem párosítja, ahol A=C és B meg D NULL.
[Szerkesztve] -
lordring
aktív tag
Sziasztok! Van 2 táblám, amiből az összetartozó elemeket szeretném kigyűjteni, egy olyan feltétellel, hogy A mező egyezzen meg C-vel, B mező pedig D-vel. A és B az egyik, C és D a másik mezőben van. Meg is csinálja szépen, csak annyi a gond, hogy ha A= C,
de B és D értéknélküli (NULL) mező, akkor úgy veszi hogy a 2 rekord nem egyforma.
Imígyen néz ki most SQL-ben:
SELECT Promotion.[Order No], cikkszám.F1, Promotion.[Designation-C/B], Promotion.Grade, Promotion.Quantity, Promotion.[Order Date], Promotion.[Handling No], Promotion.State
FROM Promotion LEFT JOIN cikkszám ON (Promotion.Grade = cikkszám.F3) AND (Promotion.[Designation-C/B] = cikkszám.F2);
Úgy szeretném módosítani a szűrést, hogy azokat a rekordokat kérem, hogy A mező egyezzen meg C-vel, B mező pedig D-vel kivéve ha mindkettő NULL mező.
Tudna vki segíteni?
-
bredan
csendes tag
Munkalehetőség: Access gurukat keresünk alkalmi céges munkákra. Érdeklődni: 20/972-00-59
-
BoGyo[ME]
tag
Köszi a gyors választ!
Én is attól tartok, hogy sajna excel lesz belőle... csak jobb lett volna valami ''bamba-biztosabb'' megoldás (tartok tőle, hogy a táblázatot kitöltők nem igazán lesznek a helyzet magaslatán, sokuknak valószínűleg még az excel használatot is tanulni kell majd...
) -
válasz
BoGyo[ME]
#481
üzenetére
A kérdésem tehát az lenne, hogy megoldható-e az én kis adatbázisomnak, illetve a hozzá tartozó űrlapnak valami olyasféle exportálása, ami - egy átlagos felhasználói szoftverkörnyezetet feltételezve - önmagában is futtatható, kitölthető, aztán visszaküldhető?
Nem, mindenképpen kell hozzá Access. Hacsak nem te írod meg az interface-t valami másik nyelven (pl: VB.NET, de ehhez meg net framework kell). -
BoGyo[ME]
tag
Üdv Mindenki!
Volna nekem egy MS Office Access 2003 alatt létrehozott egyszerű kis adatbázisom (8-10 mezővel) meg egy ennek kitöltését segítő (szintén roppant egyszerű) űrlapocskám.
A problémám, hogy ezt el kellene küldeni kb. 3.000 embernek, akik aztán azt kitöltve (átlagosan kb. 30-50 adatsor) visszaküldenék. (Az így kapott kb. 3.000 táblázatot aztán persze összesíteni kellene...) A gond ott van, hogy nem várhatom el ennyi embertől, hogy fel legyen telepítve az Access a gépükre (indokolatlan is lenne egy 1 órás munka miatt).
A kérdésem tehát az lenne, hogy megoldható-e az én kis adatbázisomnak, illetve a hozzá tartozó űrlapnak valami olyasféle exportálása, ami - egy átlagos felhasználói szoftverkörnyezetet feltételezve - önmagában is futtatható, kitölthető, aztán visszaküldhető?
(Vagy inkább kérjem el a szükséges adatokat excel-ben? (az csak van mindenkinek
)) -
Gh0sT
addikt
Szeretnék hozzáférni egy régebben készített adatbázisomhoz, amit jelszóval védtem le. Szerencsére a jelszót elfelejtettem.
Nem tudtok valami megoldást, amivel ez kikerülhető? Az első két karaktert demo programokkal visszafejtettem, de hál' Istennek valami rohadt bonyolult pass-t használtam. 
-
jeges
senior tag
ez így van, de én vigyáznék ezzel, mer' nem csupán az alkalmazásodra, hanem az access-re globálisan vonatkozik a módosítás, ami más alkalmazások használata esetén nem túl praktikus. a másik gond, hogy ha az alkalmazásodat átviszed másik gépre, ott újra meg köll módosítani a menüt, hogy a neked szükséges parancsok látszódjanak (másik access nem látja, mit csináltál ezen a gépen).
azér' szokás modullal, makróval csinálni, mer' az alkalmazás nyitásakor automatikusan meggenerálhatod a saját menüidet, majd bezáráskor szintén automatikusan visszaállíthatod azokat. -
rebel56
tag
Sziasztok!
Megvan hogyan lehet elkészíteni az egyéni menüt, még makrók sem kellenek hozzá! Tehát az alábbi műveletekkel elérhető, hogy ne a Fájl, Szerkesztés, Nézet, Beszúrás, Eszközök, Ablak, Súgó menüpontok jelenjenek meg a felső menüsorban, hanem teljesen egyéni menüpontok.
- Nézet / Eszköztárak / Testreszabás / Létrehozás
Név megadása
- Tulajdonságok
Itt lehet megadni, hogy eszköztár vagy menüsör legyen, nekem az utóbbi kellett.
- Parancsok fül
Itt lehet új menüpontot hozzáadni, ezeken belül parancsokat definiálni és almenüket hozzáadni a saját menühöz: a parancsok listájából drag&drop módszerrel lehet a saját menühöz hozzáadni a parancsokat, meglevő menüpontokat, űrlapmegnyitást, makrófuttatást, stb.
Végül az Eszközök/Indításnál a Menüsorhoz meg kell adni az egyénileg létrehozott menü nevét és a jelölőnégyzeteket értelemszerűen kell megjelölni. -
sszever
őstag
Ezt értem, jobban mondva erre rájöttem a help segítségével.
A mező numerikus. Az azt lekérdező kód:
''Private Sub KombináltLista3_AfterUpdate()
Dim rs As Object
Set rs = Me.Recordset.Clone
rs.FindFirst ''[vastagsag] = ''' & Me![KombináltLista3] & '''''
If Not rs.EOF Then Me.Bookmark = rs.Bookmark
End Sub
''
Esetleg itt található valami? (a kódhoz hülye vagyok). A példatáblázat, amelyből kivettem karakteres mezővel dolgozott. -
jeges
senior tag
ennek a koncepciónak logikailag egy nagy baja van:
a jogosultságok hierarchiája miatt bizonyos szint fölött az admin látja mások password-jét, ami biztonsági szempontból nem elfogadható. a hierarchia még csak-csak megoldható (pl. csoportokba sorolással), de ebben a külön tárolt szerkezetben az admin tényleg ''isten'', ami kockázatot jelent. az üzleti adatok elválasztatlansága a ''technikai'' adatoktól nem javallott. nem véletlen, hogy az access-ben is külön .mdw (vagy mi a fene) tárolja a felhasználói adatokat.
ugyanez egyébként megoldható az access gyári userid és group tagságán kersztül is, és biztonságosabb is. ugyanúgy, ahogy vizsgálod a saját táblád tartalmát, az access gyári beállításait is le tudod kérdezni. -
jeges
senior tag
javallhatok egy harmadikat?
![;]](//cdn.rios.hu/dl/s/v1.gif)
komolyra fordítva: a 4 táblás megoldás OK, a 2 táblásat nem javaslom, mer' nagyon rugalmatlan lesz az adatbázis, a 3, ill 19 elemű ''segéd''táblában történő keresés pedig semmivel nem lassabb, mintha 40-50 karateren eltárolod a régiók, megyék neveit.
szóval az alternatív harmadik út: csinálsz egyetlen település táblát, és egy darab ''metatáblát''. azér' a macskaköröm, mer' egyesek szerint ezt lehet, mások szerint nem lehet metaadatoknak nevezni. mindegy, a lényeg: a tábla szerkezete:
ID, categoryID, name, narr1
a tábla lényege a szerkezete:
1, 0, ''Megye'',
2, 0, ''Régió'',
3, 1, ''Pest'', 24
4, 1, ''Bács-Kiskun'', 23
5, 1, ''Komárom-Esztergom'', 22
6, 1, ''Jász-nagykun-szolnok'', 24
[...]
22, 2, ''Észak-magyarország'',
23, 2, ''Dél-magyarország'',
24, 2, ''Közép-magyarország'',
és mi az előnye? egyetlen paraméter-táblában letárolod az összes, használt paramétert, amelyeket automatikusan be tudsz sorolni, és egy helyen karbantartani. pont olyan helyzetekben javallott, amiben Te vagy.
(egyébként: a category ID megmondja, hogy a ''nullás'' kategóriájú elemek közül melyikhez tartoznak az adott (nem-nullás) elemek, és a narratív egyéb célokra használható, mint pl. a fenti példában a megyék és régiók kapcsolatának tárolására)
kiegészítő javaslat: ha még rugalmasabbá akarod tenni a cuccot, hozzácsaphatsz egy tól-ig dátummező-párt a táblához, ami megmondja, mely időpontokban mely paraméterek aktívak.
ugyanakkor nem köll sok kis felszabdalt táblát használnod, csupán egyet.
szerk: hejessírás
[Szerkesztve] -
-
Gh0sT
addikt
1. Csinálsz egy üres formot.
2. Feldobsz a formra 5 command buttont.
3. Az eseményszerkesztőben a click eseményhez hozzárendeled az alábbi műveletet:
Private Sub Parancsgombx_Click()
Dim Urlapneve As String
Urlapneve = ''Ide írod az űrlap nevét, amit nyitni szeretnél''
DoCmd.OpenForm Urlapneve
End Sub
Persze előtte meg kell csinálni az almenüket is, hogy legyen mire hivatkozni. -
rebel56
tag
Sziasztok!
Szeretnék egy saját globális menüt létrehozni egy adatbázisban. Nézegettem a súgót, de nem volt egyértelmű, ezért kérem a segítségeteket! A menü 5 menüpontból állna, minden menüben lenne 3 almenü és azokban lennének a parancsok, hogy melyik űrlapokat melyik nyissa meg.
Ott tartok, hogy létrehoztam egy ''Menü'' nevű makrót, amelyben van 5 db MakróHozzáadása művelet, a menüpont nevével, illetve hogy melyik másik makróra hivatkozik. Ennek eddig az az eredménye, hogy az indításnál megjelennek a kívánt egyedi menüpontok, de üresek, mert nem tudom hogy a hivatkozott makróba mit kell betenni. (Pl. MenüelemBeállítása, Űrlapmegnyitás).
[Szerkesztve] -
Gh0sT
addikt
Adatmodellezési alapkérdés:
Adott ugye Magyarország, amin belül megkülönböztetünk 3 régiót (Kelet, nyugat, közép). Az egyes régiókon belül vannak megyék. A megyéken belül települések. A településeken belül partnerek.
Hogyan érdemes ilyenkor adattáblákat létrehozni? Ugyez az világos, hogy az egyes táblák között hierarchikus viszony van és egy a többhöz kapcsolat.
Régió (1)---->(n) Megye (1)---->(n) Település) (1)---->(n) Partner
Két lehetőségen gondolkodom:
1. Négy táblát hozok létre a fenti kapcsolati viszonyban. Ezzel tárhelyet takarítok meg, kódokkal fogok hivatkozni egy egyes táblák tulajdonságaira.
2. Két táblát hozok létre (Partner, Település). A település táblában rögzítem az adott településhez tartozó megyét és régiót betűvel. Ez ugye nem a legtakarékosabb megoldás, de a későbbiekben úgy vélem könnyebbé tenné a kezelést.
Amikor partnert viszek fel, akkor mellé egy legördülő listából csak a települést kell kiválasztani, a régió és megye autómatikusan jönne fel a kiválasztott település függvényében. Mi történi ilyenkor? Ha az első esetet választom, akkor le kell futtanom egy lekérdezést, ami használni fogja a régió, megye és település táblákat és kidobja a megfelelő találatot. A második esetben pedig már a település tábla alapján meg lenne a találat, nem kellene további táblákban turkálni és lekérdezéseket futtatni.
Melyik a jobb megoldás? Az elsőt kényelmetlen használni. Lekérdezésekkel több táblát kell átnyálazni, hogy eredményt kapjak (pl egy adott partner melyik régióba tartozik). Ellenben a második esetben elég lenne két táblával dolgozni, ami gondolom gyorsabb és kezelhetőbb is. Nincsenek kulcsként deffiniált kódok, amiknek nem ismerem a jelentését, viszont több helyet foglalok.
Mi az optimális?
Csak hogy átláthatóbb legyen:
Régióból van 3 db, megyéből 19, településből majd 4000, partnerből pedig kb 5000. Érdemes-e szétbontani ennyire az adatszerkezetet? -
Gh0sT
addikt
1. A tábla véleményem szerint törölhető. A keresést lekérdezésből célszerűbb megoldani.
2. Adattárolás szempontjából hátrány. Ha így marad, akkor nincs szükség ötvözet táblára sem, ellenben az ötvözet konkrét megnevezése többször is szerepelni fog a főtáblában. Ergo több helyet foglalsz tárolás szempontjából, de kevesebb táblád lesz, ami áttekinthető marad. Mégsem ezt javasolnám, mert egy egyszerű választó lekérdezéssel előállítható a kérdéses tábla és abból már lehet dolgozni. A raktárosnak nem kell feltétlenül látnia a főtáblát és abban dolgoznia, neki tökéletesen megteszi egy lekérdezés is, különbséget nem fog látni közte. Az meg lényegében mindegy, hogy a háttérben milyen eljárások futnak.
3. Ha nincs, akkor megszűnik, de ha marad ötvözet, akkor a probléma továbbra is fennáll. Az ötvözet és a termék tábla között egy a többhöz kapcsolat van. -
Gh0sT
addikt
Este egyébként küldöm, amit ígértem. Végül csak sikerült megoldanom.

Felhasználói jogok: én a következőt csinálom.
1. Létrehozok egy táblát a felhasználók fő adataival (ID, név, jelszó, jogosultsági szint, stb).
2. Készítek egy beléptető modult, ahol a user megadja a nevét és jelszavát.
3. Kiolvasom a táblából a beírt usernévnek megfelelő jelszót és jogosultsági szintet.
a.) ha nincs találat usernévre kiírja, hogy nincs ilyen user
b.) ha nem egyezik a beírt jelszó az adatbázisban tárolttal, akkor szintén hibát dob
c.) stimmel minden, engedi a belépést
4. Belépés előtt a jogosultsági szintet (ez legyen egy kód 1-10 között) eltárolom egy public változóban (jogosultsag).
5. Ha ezután a user valahova szeretne belépni, akkor csak a jogosultsagot vizsgálom, hogy megfelelő szinten van-e. (pl egy adott menübe csak 6-os szint alatt lehet belépni)
Előnyök:
- megoldható, hogy a userek saját maguk adják meg a jelszavukat és azt tárolják az adatbázisban
- nagyon jól és könnyen lehet paraméterezni az adatbázist ezután, könnyű a jogosultságok kiosztása
- felhasználó szintűvé lehet tenni az egyes felületeket (könnyű rejteni bizonyos mezőket a formon, ha nincs megfelelő jogosultsági szint) -
sszever
őstag
1,vastagság tábla egyszer került szóba, hogy jobb lenne, ha lenne, mert akkor egyszerűbben meg lehetne oldani a kettős keresést (vagyí valami ilyesmi). Ezért hoztam létre, bár a keresést már nem tudtam megcsinálni. Ergo igazából nincs rá szükség.
2, ha így marad, az hátrány? Ez szerintem a raktárosnak egyértelműbb. De vevő vagyok bármilyen javaslatra
3, ha nincs vastagság, ez a gond megszűnik, nem? -
Gh0sT
addikt
Van néhány észrevételem az adatszerkezettel kapcsolatban:
1. nem feltétlenül lenne szükség vastagság táblára
2. az ötvözet táblában érdemesebb lenne kódot használni az azonosításra
3. a kapcsolat a táblák között egy a többhöz
A vastagság táblát miért használod? Nem látom indokoltnak. Egyedül talán akkor kellene, ha csak meghatározott, véges számú vastagság létezik. Viszont ebben az esetben is egy a többhöz kapcsolat szükségeltetik a két tábla között, valamint a vastagság elsődleges kulcs szerepet töltsön be! -
sszever
őstag
Átmásoltam az adatbázis hálózati meghajtóra. Ott létrehoztam az adatbázisban biztonsági beállításokat (2 felhasználó, aki futtathatja, stb), saját gépemről indítva működik is, de másik gépről indítva:
![[kép] [kép]](http://kepfeltoltes.hu/060531/7665138131_www.kepfeltoltes.hu_.jpg)
[link] -
sszever
őstag
-
balmag
csendes tag
Üdv mindenkinek
Új vagyok még a PH-en de lenne egy Access kérdésem, amit már jó pár helyen feltettem több kevesebb sikerrel. Van egy kis access 97-ben megirt nyilvántartó alkalmazásom, amit valamilyen runtime környezettel akartam volna futtatni és csinálni neki egy telepítő készletetet. ehhez létezik egy ODE97 nevű progi de sajnos....
Hogyan csinálhatnék a kis mdb-nek egy telepítő készletetet runtime-al.
[Szerkesztve] -
sszever
őstag
Így igaz, egy htm oldalt generál.
Mivel űrlappal még ötletem sem lett volna, hogy kezdjek neki, azért indítottam ezzel.
Természetesen űrlappal szebb lenne / lesz. De ezzel meg fogok szenvedni, mire meglesz
De a találatokhoz hogy csinálom aut meg, hogy listát hozzon ki, ne csak 1-1 találatot? -
Gh0sT
addikt
Űrlappal ez nem lett vonal szebb és egyszerűbb?
Készíteni kell egy paraméteres lekérdezést, aminek van két paramétere:
- ötvözet
- vastagság
Ezeket hozzárendeled egy-egy textboxhot, vagy comboboxhoz, ami megjelenik az űrlap tetején és szabadon állíthatja a user.
A találatokhoz nem adsz módosítási jogot, kivéve ezt a foglalt dolgot tudná állítgatni, minek hatására ismét lefutna a lekérdezés és frissülnének az adatok.
Így hirtelen ez jutott eszembe. Én személy szerint nem dolgoztam soha adatelérési lapokkal, az űrlapokat jobban komálom. Kicsit utánanéztem és úgy láttam, hogy ez valami webes felülethez hasonló eredményt produkált. -
sszever
őstag
Ott próbáltam megcsinálni, hogy a kedves kollegák tudjanak ötvözet, majd vastagságra szűrve listát kapni a szűrésnek megfelelő, le nem foglalt, anyagokról, és azokat lefoglalni.
Ugyebár erre kérdeztem rá reggel, hogy létezik e más megoldás.
No, a lényege a következő lenne:
Felhasználó kiválasztja, hogy melyik ötvözetből, illetve vastagságból szeretne terméket lefoglalni, amire az adatbázis lehoz neki egy listát, hogy x ötvözetből és y vastagságból ezek a termékek vannak szabadon (lehet, hogy 10 találat lesz rá, lehet, hogy 100 találat lesz rá).
Nem tud rajta semmit sem módosítani, csak annyit, hogy bejelöli foglaltként a terméket, amely erre eltűnik a listából.
Valami ötlet? -
sszever
őstag
átraktam az adatbázis a fileszerverünkre (hálózati meghajtóra), majd ott hoztam létre az adatelérési lapot.
Mihelyt kilépek, majd ismét belépek, hiába jó az elérési útvonal, az adatelérési lapok nem működnek.

-
Gh0sT
addikt
Nah, van erre is megoldás
A DISTINCT SQL parancs kell hozzá.
Egy példa: van egy tábla, amiben vannak mondjuk személyek, akiknek nyilván van tartva a lakóhelyük. Ugye egyértelmű, hogy többen is lakhatnak egy helyen, de te csak egyszer szeretnél megjeleníteni minden települést
SELECT DISTINCT telepules_nev FROM szemely
Ugyanezt meg tudod csinálni a te tábláidra is. -
sszever
őstag
Esetleg a vastagságot választom ki listából, és az ötvözetekre csoportosítva hozza a megoldást?
-
sszever
őstag
Azt sem tudom mi az a kapcsolótábla

Más megoldás? Pl űrlapon egy olyan keresés:
Kiválasztom választólistából az ötvözetet, és beírom a vastagságot, amire szükségem lenne, majd eredményként kihoz egy listát, ahol az ötvözet és a vastagság feltételnek megfelelő összes eredményt kihozza? Vagy most nagyon hülyeséget kérdeztem?
Esetleg szétbontom a foglalatlan lekérdezést minden ötvözetre, és akkor már csak a vastagságokra kellene rákeresnem (bár kényelmetlenebb a használata, de ha működik...? -
Gh0sT
addikt
Több a többhöz kapcsolattal nem fogsz tudni mit kezdeni Access-ben. Szükség lesz egy kapcsolótáblára.
Ötvözet tábla (n) ------- (n) Vastagság tábla
Ötvözet tábla (1) ------- (n) Kapcsoló tábla (n) ------- (1) Vastagság tábla
A kapcsolótábla fogja tartalmazni az ötvözet és a vastagság kódját is és nem lesz benne elsődleges kulcs.
Viszont ebben nem vagyok biztos, tehát mielőtt szétbombázod az adatszerkezetet, valaki megerősíthetne.
-
-
Gh0sT
addikt
''Nekem valahogy úgy logikus, ha az vastagság több rekordjához az ötvözet egy rekordja tartozik (hisz egy ötvözeten belül lehet több vastagság!).''
Én a következőt érzem:
- egy ötvözet lehet többféle vastagságú (mondjuk 1-5 mm)
- egy adott vastagság több ötvözethez is tartozhat
Ez egy több a többhöz kapcsolat. Persze pontosan nem látom át a példát, de nem lehet, hogy ez a gond?
Egyébként ne kenődj el, én a Visual Basic topicban teszem fel az adatmodellezéssel kapcsolatos primitív kérdéseimet!
Valahol el kell kezdeni.
Szerk.: korán van, még írni sem tudok.
[Szerkesztve] -
sszever
őstag
MEgint elakadtam, s most már kezdek erősen kételkedni magamban:
Van ugyebár a ''foglalatlan'' lekérdezés, amely az összes olyan terméket tartalmazza, amely nem lett lefoglalva.
Ezt szeretném egy adatelérési lapban is elérni az alábbi módon:
Választólista ötvözetre (tehát kiválaszthatom milyen ötvözetre is vagyok kíváncsi)
Választólista vastagságra (itt kiválasztanám, hogy a fent kiválasztott ötvözeten belül mely vastagság érdekelne)
S ezután jönnének az adatok.
Namármost én a megoldst az alábbiak szerint képzeltem el:
elsőként jön az ötvözet a fejlécben, csoportszintű vezérlőelemként (eddig jó is, ki is tudom választani az ötvözeteket)
második fejlécben jön a vastagság (ugyancsak csoportszintű vezérlőelemként). Ugyebár amikor ezt behúzom, jön a kapcsolat varázsló. ''a foglalt új több rekordjához a foglalt egy rekordja tartozik''.
Nekem valahogy úgy logikus, ha az vastagság több rekordjához az ötvözet egy rekordja tartozik (hisz egy ötvözeten belül lehet több vastagság!).
De nem működik, ugyanis így a második csoportszintű vezérlőelemet (ötvözet) üresen hagyja.
Ha azt állítom be, hogy az ötvözet több rekordjához az ötvözet egy rekordja tartozik, működik, de persze a végén ötvözettől függetlenül az összes, a vastagságra érvényes találatot kihozza. -
sszever
őstag
Látod, ha az ember nem olvassa figyelmesen végig...
Meg is érdemli!
A ki nem adott, de lefoglalt vágatoknál ok a dolog. NEm jelenik meg
A kiadott vágatnál kiírja, ok a dolog.
A le nem foglaltnál viszont kiírja még!
S indulásnál is kiírja, amikor még minden üres
S amikor idáig eljutottam, gondoltam, megnézem mégegyszer, mit ronthattam el, s látom, hogy nem a 27-es címkére írtam be
-
sszever
őstag
Tuti.
Felbuzdulv a dolgon próbáltam én is betenni egy piros feliratú mezőt, mely szerint írja ki, ha már ki lett vételezve a termék. Mondanom sem kell, nem jött össze
Option Compare Database
Private Sub Form_Load()
DoCmd.GoToRecord , , acNewRec
Címke23.Visible = False
End Sub
Private Sub Parancsgomb16_Click()
DoCmd.Close acForm, ''Vágat kivételezés'', acSaveYes
End Sub
Private Sub Parancsgomb19_Click()
If kiadva.Value = False Then
kiadva.Value = True
Parancsgomb19.Caption = ''A termék kiadva''
Else
kiadva.Value = False
Parancsgomb19.Caption = ''Termék kiadása''
End If
DoCmd.Close acForm, ''Vágat kivételezés'', acSaveYes
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
Címke23.Visible = True
Parancsgomb19.Caption = ''Termék kiadása''
Parancsgomb19.Enabled = False
Else
Címke23.Visible = False
If kiadva.Value = True Then
Címke27.Visible = True
Parancsgomb19.Caption = ''A termék kiadva''
Parancsgomb19.Enabled = False
Else
Címke27.Visible = False
Parancsgomb19.Caption = ''Termék kiadása''
Parancsgomb19.Enabled = True
End If
End If
End If
End Sub
Private Sub Szöveg0_BeforeUpdate(Cancel As Integer)
End Sub
Private Sub Parancsgomb18_Click()
On Error GoTo Err_Parancsgomb18_Click
Screen.PreviousControl.SetFocus
DoCmd.FindNext
Exit_Parancsgomb18_Click:
Exit Sub
Err_Parancsgomb18_Click:
MsgBox Err.Description
Resume Exit_Parancsgomb18_Click
End Sub -
Gh0sT
addikt
A Keresés parancsgomb kódján kell változtatni.
A 2. feltétel vizsgálat után van egy ilyen sor:
If kiadva.Value = True Then
Parancsgomb19.Caption = ''A termék kiadva''
Parancsgomb19.Enabled = True
A True értéket kell átírni False-ra az utolsó sorban.
Parancsgomb19.Enabled = False
[Szerkesztve] -
sszever
őstag
GhOst.
Este még variáltam az adatbázissal és találtam még egy hibát:
termék kivételezésénél:
Ugyebár a még le nem foglalt termék esetében ki is írja: '' termék még nem lett lefoglalva'' és inaktív a kiadás gomb, viszont a már kiadott terméket hozza aktív kiadás gombbal, amellyel így vissza lehet hozni a kiadott terméket.
Gondolom a megoldás félsoros, csak mint láthattad eddig is, a kódokhoz hülye vagyok ám!
-
jeges
senior tag
most néztem meg az ms knowledge base-t ez ügyben. először is sokkal korrektebb a probléma leírása, mint 1-2 évvel ezelőtt. másodsorban viszont az az érdekes, h ők is azt ajánlják, h ha robosztus, hibatűrő, biztos rendszert akarsz, ne használd a jet motort szerver célokra, mer' nem arra való.

-
Gh0sT
addikt
Így van, ahogy jeges kolléga is említette. Előfordulhat olyan, hogy elsődleges kulcsba két egyforma érték kerül, ha több user egyszerre használja az adatbázist. Sőt, nekem most ennél jóval cifrább dolgokat is produkál, de valszeg azért mert nem körültekintően terveztem meg az adatbázist.
-
jeges
senior tag
az access nem ''klasszikus'' szerver-kliens adatbázis, nem tudja úgy lock-olni a központi szervert, mint egy oracle vagy ms sql szerver, abből származik a multiuseres megoldások központi problémája.
ponotsítás: a jet engine az, ami nem képes ilyesmikre, de ez már nem nagy különbség a fentiekhez képest.
[Szerkesztve] -
jeges
senior tag
ennek a dátumos megoldásnak nem látom a nagyobb biztonságát, mint a normál számlálónak. ha a 148-as user pont egy másodperccel (illetve egységnyi idővel) később OK-zza a rekordot, mint a 147-es, akkor megen' összegabalyodnak a cuccok. a now() függvénnyel mindig lehetnek ilyen gondok, ez sztem semmivel nem jobb, mint a számlálós ID. arról nem is beszélve, hogy az ID kiosztást nem gondolnám ennyire bonyolítani, mer' ez csak újabb hibalehetőség.
szerk: upsz, jól félreértettem, write-only üzemmód.
ez a konkatenált megoldás kissé pazarló, nem? 8+4+3 karakteren kellene tárolni minimum, ha jól értem 
én továbbra is a usereknek elkülönített range-t javallanám, az tényleg tuti(nak tűnik), és elég neki 9-10 számjegy bőven. igaz, az adatbázis átalakítása nehézkesebbnek tűnhet.
[Szerkesztve] -
sszever
őstag
Most már igazából csak egy dolgra kell valami jó megoldást találni:
1, termék felkerül az adatbáziba
2, felhasználónak el kell tudnia adni, ezért tudnia kell milyen termékek vannak. (ami számára fontos: ötvözet ,vastagság, szélesség, hossz). Ahogy keresnie kell: először kiválasztja az ötvözetet, majd a vastagságot. Ott kap egy listát, amely tartalmazza az ennek a két kritériumnak megfelelő összes nem foglalt terméket. Ezekből a kedves felhasználó kivákasztja és lefoglalja a teméket.
3, a raktáros a foglalt termékekből összekészíti és kivételezi a terméket.
1 - 3-as pont sok sok segítséggel sikeresen működik. 2-es pontra én adatelérési lapot csináltam első körben, ami működik. De gondoltam megkérdem, hátha van szebb, jobb megoldás!
Új hozzászólás Aktív témák
- Parfüm topik
- WayteQ xTAB-8Q
- Poco F8 Ultra – forrónaci
- Hosszú premier előzetest kapott az Arknights: Endfield
- Vezetékes FEJhallgatók
- Medence topik
- Autós topik
- Kormányok / autós szimulátorok topikja
- Doky586: Windows telepítés utáni beállítások
- Világ Ninjái és Kódfejtői, egyesüljetek!
- További aktív témák...
- Vírusirtó, Antivirus, VPN kulcsok GARANCIÁVAL!
- MEGA AKCIÓ! - Jogtiszta Windows - Office & Autodesk & CorelDRAW - Azonnal - Számlával - Garanciával
- Windows, Office licencek kedvező áron, egyenesen a Microsoft-tól - Automata kézbesítés utalással is!
- Kaspersky, BitDefender, Avast és egyéb vírusírtó licencek a legolcsóbban, egyenesen a gyártóktól!
- PC Game Pass előfizetés
- 266 - Lenovo ThinkBook 16 (G6 ABP) - AMD Ryzen 5 7430U, no GPU
- Samsung Galaxy Xcover 5 64GB, Kártyafüggetlen, 1 Év Garanciával
- ÁRGARANCIA!Épített KomPhone i5 14400F 32/64GB RAM RX 9060 XT 16GB GAMER PC termékbeszámítással
- Bomba ár! Lenovo ThinkPad T490 - i5-8G I 8GB I 256SSD I 14" FHD I HUN I Cam I W11 I Garancia!
- ÁRGARANCIA!Épített KomPhone Ryzen 7 7800X3D 32/64GB RAM RX 9070 XT 16GB GAMER PC termékbeszámítással
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest



)
(fognak szeretni...
)
)

Modulokkal még nem dolgoztam, remélem összejön.
)

Meg is érdemli!

