Hirdetés
- Luck Dragon: Asszociációs játék. :)
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- MasterDeeJay: ASRock B250M Pro4 coffeetime mod! (DDR4)
- Graphics: Telefonvásárlási kálváriám....avagy clickbait cím: Horror a hardveraprón
- ricsi99: 6. Genes alaplap tündöklése kontra MS/Zintel korlátozásai
- sziku69: Fűzzük össze a szavakat :)
- Elektromos rásegítésű kerékpárok
- Meggyi001: A Lidl Silvercrest kenyérsütő jó?.........Jelentem:Jó!
- f(x)=exp(x): A laposföld elmebaj: Vissza a jövőbe!
- sziku69: Szólánc.
Új hozzászólás Aktív témák
-
Gh0sT
addikt
Az Access képes több felhasználó egyidejű kiszolgálására is, tudtok egyszerre többen dolgozni ugyanabban az adatbázisban.
Ha nem akarod túlbonyolítani, akkor elkészíted az adatbázist és felhasználói felületnek űrlapokat használsz. Ezek teljesen jók adatok manipulációjához. Esetleg megtámogatod makrókkal meg mindenféle VB scriptekkel a működést.
Nézd meg a Fájl menü --> Beállítások -- Ügyfél beállítások menüpont alatt a Speciális részen, hogy az adatbázis megosztott módban van-e, illetve milyen rekord zárolás van beállítva.
-
Gh0sT
addikt
Ha jól értem, akkor valami ilyesmire lenne szükséged:
1. Adatbázis egy közös hozzáférésű hálózati meghajtón.
2. Kliens programok telepítve a felhasználók gépére.Esetleg:
Adatbázis egy közös hozzáférésű hálózati meghajtóra, ahol az adattáblákhoz nincs közvetlen hozzáférése a felhasználóknak, hanem mondjuk űrlapokon keresztül valósul meg a kommunikáció.Míg utóbbihoz nem kell kliens program, előbbi megoldáshoz nem árt valamilyen külső fejlesztő környezet és valamilyen programnyelv kicsit mélyebb ismerete.
-
Gh0sT
addikt
válasz
#36268800
#868
üzenetére
Tanulj adatbáziskezelést, adatmodellezést, mellé valamilyen programnyelvet (C++, C#). Access kevés, de alapnak jó. SQL magas szinten órási előny. Ha ügyes vagy, nagyon durván kiaknázható terület. Főleg pénzügyi szektorban, bankoknál, ahol hatalmas adatbázisokkal kell dolgozni és fizetést is adnak rendesen ha van hozzá érzéked.
-
Gh0sT
addikt
válasz
_Hunter_
#640
üzenetére
Private Declare Function ShellExecute Lib "shell32.dll" Alias "ShellExecuteA" (ByVal hWnd As Long, ByVal lpOperation As String, ByVal lpFile As String, ByVal lpParameters As String, ByVal lpDirectory As String, ByVal nShowCmd As Long) As Long
Function PdfLetezik(Fajlnev As String) As Boolean
On Error GoTo Hibakezelo
PdfLetezik = (GetAttr(Fajlnev) And vbDirectory) = 0
Exit Function
Hibakezelo:
MsgBox ("A keresett pdf dokumentum nem található")
End Function
Private Sub Hivatkozas_Click()
PdfLetezik ("EleresiUt" & Hivatkozas.Value & ".pdf")
ShellExecute 0&, "open", Hivatkozas.Value & ".pdf", "", "EleresiUt", vbNormalFocus
End Sub -
Gh0sT
addikt
Három a magyar igazság.
Private Declare Function ShellExecute Lib "shell32.dll" Alias "ShellExecuteA" (ByVal hWnd As Long, ByVal lpOperation As String, ByVal lpFile As String, ByVal lpParameters As String, ByVal lpDirectory As String, ByVal nShowCmd As Long) As Long
Private Sub Hivatkozas_Click()
ShellExecute 0&, "open", Hivatkozas.Caption & ".pdf", "", "EleresiUt", vbNormalFocus
End SubAhol Hivatkozas a link neve, EleresiUt meg a könyvtár, ahol tárolva vannak a pdf-ek.
-
Gh0sT
addikt
Kicsit finomítottam rajta, mert nagy hirtelen nem láttam a szintaxist.
Option Compare Database
Private Declare Function ShellExecute Lib "shell32.dll" Alias "ShellExecuteA" (ByVal hWnd As Long, ByVal lpOperation As String, ByVal lpFile As String, ByVal lpParameters As String, ByVal lpDirectory As String, ByVal nShowCmd As Long) As Long
Private Sub Hivatkozas_Click()
ShellExecute 0&, "open", Hivatkozas.text & ".pdf", "", "EleresiUt", vbNormalFocus
End Sub -
Gh0sT
addikt
válasz
_Hunter_
#636
üzenetére
Akkor egy példa. Egyelőre ez annyit tud, hogy egy labelre ha klikkelsz, akkor megnyit egy pdf dokumentumot:
Option Compare Database
Private Declare Function ShellExecute Lib "shell32.dll" Alias "ShellExecuteA" (ByVal hWnd As Long, ByVal lpOperation As String, ByVal lpFile As String, ByVal lpParameters As String, ByVal lpDirectory As String, ByVal nShowCmd As Long) As Long
Private Sub Hivatkozas_Click()
ShellExecute 0&, "open", "Elérésiút\Filenév", "", "", vbNormalFocus
End SubInnen már csak egy lépés a Te verziód.
Remélem... -
Gh0sT
addikt
válasz
_Hunter_
#628
üzenetére
Gondolom a segédűrlap meghív egy lekérdezést. Azt kellene átírni. Nézd meg, hogy a segédűrlapnak mi a rekordforrása (jobb klikk --> tulajdonságok --> adat --> rekordforrás)
Itt szerkesztheted a lekérdezést és a végére ha beleraksz egy "order by Rögzítés ideje desc" kifejezést, akkor a kívánt hatást fogod elérni.MOD: bár nem ismerem az adatbázist, de az első oszlopban eltárolod a teljes dátumot ugye (év.hónap.nap óra:perc:mp)? Nem tudom, hogy mi a cél, de ha csak óra:perc:mp formátummal dolgozol, akkor keveredés lehet a későbbi lekérdezéseknél. (pl. nem fogod tudni, hogy adott rekor melyik napon került rögzítésre, mert csak az óra:perc fog látszani)
-
Gh0sT
addikt
válasz
_Hunter_
#626
üzenetére
Nem tudom, hogy milyen a táblaszerkezet, de két lehetőség adott:
1. Ha a rögzítésnél használsz időbélyegzőt, akkor úgy írod meg a lekérdezést, hogy datum szerint csökkenőbe rendezed az adatokat (order by datum desc).
2. Ha nincs időbélyegző, akkor az ID lehet kiindulási pont, amennyiben számláló típusú. (order by ID desc) -
Gh0sT
addikt
Pffff, letöltöttem, megnéztem:
Van van 5-6 adatbázis, tele táblákkal amik között nincs kapcsolat. Rohadtul nem értem, de szerintem a VB felület alól töltődnek bizonyos mezők, de hogy melyek, arra nem sikerült rájönnöm. Az általad írt táblákat meg sem találtam, ellenben van 2 beteg tábla, de nem tudom, hogy ezeket tölti-e a rendszer.
-
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. -
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. -
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) -
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! -
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. -
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. -
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] -
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] -
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.
-
-
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. -
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. -
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á. -
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? -
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. -
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] -
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] -
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. -
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 Sub -
Gh0sT
addikt
Ha először letárolod az adatokat, majd utána meghívod a lekérdezésre alapuló jelentést és csak végül nyomtatsz, akkor nem lesz gond. Remélem...
Szerk.: A két üres lap hol helyezkedik el és miért üres? Fel vannak töltve rendesen a rekordok? Az oldalak nem csúsznak át a következő lapra?
[Szerkesztve] -
-
Gh0sT
addikt
Közben találtam egy elegánsabb megoldást:
Nincs szükség így a dátum rögzítésére sem.
Csinálsz egy új lekérdezést. Hozzáadod a táblákat, majd a táblából a megjeleníteni kívánt mezőt lehúzod a tervezőbe. Ezután fent az eszköztáron a szumma jelre klikkelsz. Megjelenik egy új feltétel a lekérdezésnél ''Összesítés'' címszóval. Itt kiválasztod a Last függvényt és kész is van.
SQL-ben valahogyan így néz ki:
SELECT Last(Tábla.Mező) AS Mezőnév
FROM Tábla;
Még egy fontos dolog!
A mező, amit lehúzol mindenképpen az Azonosító legyen, és ebben a lekérdezésben több mező nem szerepelhet!!!
Ha más adatokra is kíváncsi vagy, akkor kell készíteni egy másik lekérdezést, amit kapcsolni kell ehhez.
[Szerkesztve] -
Gh0sT
addikt
Egy ötlet: amikor terméket rögzítesz, akkor egy mezőbe letárolod a rögzítés dátumát a now() függvénnyel. Ezután csinálsz egy olyan lekérdezést, ami fordított sorrende rendezi a termékeket a rögzítés időpontja szerint. Ilyenkor a lekérdezés első eleme mindig az utoljára rögzített termék lesz. Erre kell majd hivatkozni.
-
Gh0sT
addikt
Még egy kis apróság, ami nálad hátrány lehet. Jelenleg a keresés nem jól működik, egy kis kozmetikázás után így szebb lesz:
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
Ezzel nem fogsz visszakapni rossz találatokat, erről az acEntire tulajdonság gondoskodik. -
-
-
Gh0sT
addikt
The server you were trying to contact sent an invalid response
Possible reasons:
The server violates the HTTP/1.1 protocol
There's an interoperability problem between the server and this gateway
Possible solutions:
Contact your system administrator for assistance
Contact your Zorp support for assistance
Additional information:
Invalid headers received in response
--------------------------------------------------------------------------------
Page generated by Zorp on aule, version 3.0.8 on Tue May 23 10:25:34 CEST 2006.
Nevezd át jpg-re és küldd el a mail címemre! -
Gh0sT
addikt
Összedobtam egy példát: [link]
Nézd meg a mögötte lévő kódot, nem nagy szám:
Option Compare Database
Private Sub Form_Load()
DoCmd.GoToRecord , , acNewRec
End Sub
Private Sub Parancsgomb22_Click()
Azonosito.SetFocus
DoCmd.FindRecord Szöveg23.Value, acAnywhere, False, acSearchAll, , acCurrent, True
End Sub
Még lehet finomítani, de ez már működik. A keresőmezőbe 1-5 között írhatsz értékeket. -
Gh0sT
addikt
Egy formon a következő képpen tudod használni:
1. Szükség lesz egy TextBox-ra, amiben bekéred a keresendő azonosító egy részletét, vagy akár az egész stringet. (KERESO_MEZO)
2. Szükség lesz magára az AZONOSITO-ra szintén egy TextBox formájában.
3. Szükség lesz egy találati mezőre is. Mivel nem ismerem a példát, ezért ez legyen egyelőre a TERMÉK mező Textbox formájában. Ezzel igazából sok dolgod nem lesz, csak beszúrod a formra és automatikusan megjelennek benne a találatok. Ha szeretnél még egyéb mezőket hozzáadni, akkor hasonlóan kell eljárnod.
4. Beraksz még a formra egy Command buttont, aminek a Click eseményéhez hozzárendeled az alábbi kódot:
Private Sub Parancsgomb1_Click()
AZONOSITO.SetFocus
DoCmd.FindRecord KERESO_MEZO.Value, acAnywhere, False, acSearchAll, , acCurrent, True
End Sub
Ez akár kód töredékre is keresni fog és az első találatot jeleníti meg. Én szoktam még mellé egy másik Command buttont is beszúrni ''Következő'' felirattal, így végig tudok menni az egész adatbázison, ha esetleg több találat lenne.
Ennek a kódja:
Private Sub Parancsgomb2_Click()
On Error GoTo Err_Parancsgomb2_Click
Screen.PreviousControl.SetFocus
DoCmd.FindNext
Parancsgomb2.SetFocus
Exit_Parancsgomb2_Click:
Exit Sub
Err_Parancsgomb2_Click:
MsgBox Err.Description
Resume Exit_Parancsgomb2_Click
End Sub -
Gh0sT
addikt
válasz
lordring
#300
üzenetére
SELECT Raktar.Cikkszam, Leltar3.Beszerzes_ar
FROM Leltar3 INNER JOIN Raktar ON Leltar3.Cikkszam = Raktar.Cikkszam;
vagy
SELECT Raktar.Cikkszam, Sum(Leltar3.Beszerzes_ar) AS Összesen
FROM Leltar3 INNER JOIN Raktar ON Leltar3.Cikkszam = Raktar.Cikkszam
GROUP BY Raktar.Cikkszam; -
#296
Gh0sT
addikt
Alvin_ti4200
#289
Gh0sT
addikt
válasz
Alvin_ti4200
#289
üzenetére
Kereszttáblás lekérdezéssel viszonylag könnyű. Pontosan nem értettem a problémát, de itt van két példa:
1.
TRANSFORM Sum([szam1]+[szam2]+[szam3]+[szam4]) AS Összeg
SELECT Tanulo.Neme
FROM Tanulo
GROUP BY Tanulo.Neme
PIVOT ''Összeg'';
Eredmény:
Neme Összeg
F 114291
N 541928
2.
TRANSFORM Sum([szam1]+[szam2]+[szam3]+[szam4]) AS Összeg
SELECT Tanulo.Tanulo_nev
FROM Tanulo
GROUP BY Tanulo.Tanulo_nev
PIVOT Tanulo.Neme;
Eredmény:
Tanulo_nev F N
Dezső 184
Évi 48504
Géza 7153
Isti 31815
Jani 10120
Jenő 65019
Kati 223068
Orsi 270356
Jah, az adatszerkezet meg az alábbi:
Tanuló{AZ, Tanulo_nev, szam1, szam2, szam3, szam4, Neme}
[Szerkesztve] -
Gh0sT
addikt
Nos, a rendszer úgy van megcsinálva, hogy 3 userre van szükség a teljes folyamat végigviteléhez. DE:
Monitorolnom kell tehát a teljes modellt és az egyes fázisokat is. A teljes folyamattal azért nincs gond, mert egy-egy csalót ki tudok szűrni. A probléma ott kezdődik, amikor a fázis átfutási idejére szeretnék mérni és nincsenek meg az ügyletek.
Még azon gondolkodtam, hogy a státuszváltás command buttonját időmérőhöz fogom kötni. Ergo, addig nem lesz aktív a gomb, amíg nem telik el 15 perc a beérkezést követően. -
Gh0sT
addikt
Igen, az lesz amit írtál.
Még egy kérdés: lentebb/fentebb vázoltad nekem anno, hogy miként tudom kiküszöbölni a dátumok közül a hétvégéket és ünnepnapokat. Megcsináltam, működik, ám van egy igen nagy probléma.
1. Először csak a napokat rögzítettem, ebben az esetben viszont, amikor a beérkezés és a döntés időpontja egy napra esett az ügylet nem jelent meg a lekérdezésben, mivel az adott nap mellett 0 szerepelt.
2. Finomítottam a skálázást és most negyed óránként vannak az időintervallumok.
Előnye: szinte az összes ügylet szerepel benne, mert alig van 0 visszatérési érték. Ellenben még mindig nem tudok mit kezdeni a csaló userekkel, akik 15 percen belül vigégifuttatnak egy ügyletet az egész rendszeren. Ilyenkor nem tudok rá lekérdezést készíteni...
Hátrány: Iszonyat számolásigényes és egy 2500+ Bartonon is másodpercekig vacakol. Az irodai gépemen kb 20-25 másodperc, amíg lefut a lekérdezés.
Nincs erre valami humánusabb megoldás?
Szerk.: a 3. pont javítása hogyan történhet?
Ha már SQL Szerver lesz az alap és VB-s felületekkel dolgozunk, akkor is közvetlenül a táblákba fogunk írni... vagy szükség lesz átmeneti tárolókra? Igazából a technikáját nem értem a dolognak.
[Szerkesztve] -
Gh0sT
addikt
Nos, akkor részletesen:
Jelenleg kb. 300 rekord található a táblákban, ami véleményem szerint nem sok. Az adatszerkezet sajnos közel sem optimális. Teszt jelleggel készítettem az egészet és az igények növekedésével csak toldozgattam, javítottam rajta így magát az eredeti adatszerkezetet egy idő után már nem mertem bántani. Valóban lehetne ez az egyik probléma, és aláírom hogy ez nagy hiba volt, de nem fér a fejembe, hogy ami egyik nap működik, az másnap miért nem. Alapvető hibák nincsenek az adatbázis szerkezetében, ebben egészen biztos vagyok. A normalizálást pedig meg lehetett volna jobban is csinálni...
Jelenleg kb. óránként mentem az egész adatbázist és ha probléma van, akkor helyreállítom. Viszont ezen a héten semmi ilyesmit nem észleltem. Annyi korlátozó intézkedést hoztam, hogy azon az üzleti területen, ahol sejtettem a hiba okát csak egy gépet engedek be egyszerre az adatbázisba. Kicsit kényelmetlen, de így legalább nincs probléma.
Működés:
1. Az egész adatbázis egy hálózati meghajtón van, amihez az érintettek hozzáférhetnek. A konfigok különböznek sajnos.
2. Míg az NT-s gépeken semmi probléma nem volt soha, addig Win2000 alatt már korábban is voltak fagyások. Az Access verziószáma az összes gépen megegyezik.
3. A userek az űrlapokon keresztül közvetlenül az adatbázisba írnak, nincsenek köztes táblák és ellenőrzés.
4. Az adott területen annyi történik, hogy egy legördülő menüből kiválasztanak egy nevet, beírnak pár értéket és klikkelnek egy gombra, ami megváltoztatja az ügyletek státuszát. Ezen kívül van egy rakat ellenörző rutin, ami az adatok töltöttségét és helyességét vizsgálja.
Igazából annak az esélye, hogy szándékosan rossz adatot írjanak be, gyakorlatilag egyenlő a nullával.
Közben elgondolkodtam egy teljesen más rendszeren és éppen most sajátítom el az alapjait. Úgy gondoltam, hogy megcsinálom ismét az egészet az alapoktól, most már maximálisan odafigyelve a táblákra és a normalizálásra is. Az adatbázishoz MS SQL Servert fogok használni és VB-n keresztül hívnám meg a lekérdezéseket, illetve magát a felületet is így készíteném el. Ezzel az ACCESS-t sikerülne teljesen kiküszöbölnöm. Remélem össze fog jönni... -
Gh0sT
addikt
Sikerült rájönnöm, hogy a munkafolyamat bizonyos fázisában törétnik a probléma. Úgy tapasztaltam, hogy két olyan user és gép van, ami szétbarmolja az adatszerkezetet, de nem értem, hogy miért. Most pl. egy olyan rekord halt meg, amihez hozzá sem nyúlt senki jó ideje. Egyszerűen csak krikszkrakszok lettek az összes mező helyén adatok gyanánt. Ennek eredményeként a hivatkozási integritást a kapcsolatok nem tudták fenntaratni és elszállt az egész, mint a győzelmi zászló. Már csak azt nem értem, hogy ha fenn van tarta a kapcsolt mezők között a hivatkozási integritás, akkor egyáltalán hogyan lehet más adatot bevinni a mezőbe. Mert itt az történik és ez okozza a problémát. Egyáltalán mitől jelennek meg ezek a ŁłäđĐ karakterek a mezőkben? Hiszen űrlapokkal dolgozunk és abban a fázisban egy csomó zárolt cella van, amit nem is lehetne módosítani. Olyan az egész, mintha elcsúszna valamitől az adatszerkezet...
Mit csináljak?
-
Gh0sT
addikt
Kínom van megint:
Adott az általam készített adatbázis, amit használunk jó sokan. A mai nap folyamán érdekes jelenség ütötte fel a fejét: sok esetben megsérül az adatbázis és helyre kell állítanom. Namost ez a helyreállítás úgy történik, hogy mondom az Access-nek, hogy csinálja meg, mire jó is lesz, viszont a mérete a felére csökken ezáltal.
Értetlenül állok a probléma előtt. Most megpróbálom kideríteni, hogy kinél sérül meg, de ez a méretcsökkenés igencsak aggasztó a számomra. A múlt héten belekerült egy olyan rekord valami hiba folytán, ami mindenféle idióta jeleket jelenített meg és törölni sem tudtam. A sérülést követően a kapcsolatok megszűntek a táblák között, így a rossz rekordtól végleg megszabadultam, a kapcsolatokat pedig felépítettem. De hogy most mi van vele, azt végképp nem értem... -
Gh0sT
addikt
Megköszönném a segítséget, mert teljesen meg vagyok lőve.
Az a baj, hogy nem ismerem a VB-s függvényeket, és a VB-hez sem értek, csak hellyel-közzel. Ha van valami alap, akkor azt talán át tudom írni, de többre nem vagyok képes.
A formátummal a következő a problémám: itt nálunk kötelezően év.hónap.nap.óra.per.másodperc formátumot használunk a pontosság érdekében. Két dátumérték kerül rögzítésre:
1. Beérkezés időpontja
2. Döntés időpontja
Na most nekem átfutási időket kellene számolni. Eddig úgy oldottam meg, hogy egyszerűen kivontam a két értéket egymásból és kaptam egy közelítőt, de ez ugye a hétvégék/ünnepek miatt pontatlan volt. Említette valaki itt a topicban, hogy be lehetne rögzíteni az egész éves naptárat és máris minden jobb lenne. Nade:
A naptár rögzítése a következő formában történne ugye:
2006.01.01 0
2006.01.02 1
2006.01.03 1
stb... Ezzel viszont az a baj, hogy az én dátumértékeimet valahogyan meg kellene feleltetni a fenti táblában szereplő értékeknek. Tehát a 2006.01.02 15:31:11-et hozzá kellene rendelnem a 2006.01.02-höz és így tovább... Na ez nem megy nekem... Bár igazság szerint azzal sem tudom, hogy mire mennék... A fenti táblából lövésem nincs hogyan lehet különbséget képezni... Az még OK, hogy az érkezési dátumot megfelelettem a tábla egyik dátumának, aztán a döntési dátumot is. Viszont mi van a közte lévő idővel?
Váááá, hülye vagyok én ehhez...
[Szerkesztve] -
Gh0sT
addikt
Kérdés:
Még mindig le vagyok ragadva a dátumkezelésnél. A következőt találtam ki:
Felviszek egy táblát, aminek az első oszlopában szerepelnének 2006. napjai január 1-től december 31-ig. Mellé a következő oszlopba rögzítek egy 0-t, vagy 1-t annak megfelelően, hogy munkanapról, vagy egyébről van szó.
Namost van nekem minden egyes esetben két dátumértékem, amikkel kellene kezdenem valamit. A baj az, hogy a dátumok tarlatlmazzák az aktuális óra:perc:mp adatokat is. Gondolom ezt valamilyen függvénnyel el tudom távolítani, hogy év.hónap.nap formátumot kapjak. Ha képzem a két érték különbségét, akkor megkapom a köztük lévő eltelt napok számát, de ezt hogyan hozom össze a dátumos táblámmal?
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. 
Kevertem a radio buttonnal... 
Új hozzászólás Aktív témák
Hirdetés
- Windows, Office licencek kedvező áron, egyenesen a Microsoft-tól - Automata kézbesítés utalással is!
- MS SQL Server 2016, 2017, 2019
- PC Szervizeket, Gépépítőket keresek B2B szoftver partnerségre (E-számlával)
- Eredeti Microsoft termékek - MEGA Akciók! Windows, Office Pro Plus, Project Pro, Visio Pro stb.
- Számlás!Steam,EA,Epic és egyébb játékok Pc-re vagy XBox!
- Apple iPhone 13 Pro Max 128GB, Kártyafüggetlen, 1 Év Garanciával
- iPhone 13 Pro 128GB 100% (1év Garancia) - ÚJ EREDETI AKKUMULÁTOR
- Eredeti DELL 240W töltők (LA240PM160)
- HIBÁTLAN iPhone 14 Pro Max 256GB Space Black -1 ÉV GARANCIA - Kártyafüggetlen, MS4370
- BESZÁMÍTÁS! Gigabyte G27F 27 FHD IPS 144Hz Gaming monitor garanciával hibátlan működéssel
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest