Tetszőleges lapméretet a jelentésnek be tudok állítani? Nem a nyomtatási lapra gondolok, hanem magára a jelentés szélességére. Az Access specification szerint 55,87 cm a maximális szélesség, viszont nekem több mint 60 cm-es lap kéne. VBA programozás kell vagy van más megoldás is? Ha előbbi, akkor mit kéne állítani. A neten nem találtam eddig használható megoldást.
Ez azért erősen túlmutat egy egyszerű nyilvántartáson, nem kevés tábla és logika, amit fel kell építeni, lépésről lépésre, értve minden egyes kapcsolat jelentését (1:1, 1:n, n:m, stb.).
Vagy, ha külön eseményeket csoportba akarsz foglalni, akkor kell egy projekt/téma tábla ahol minden témát fel kell venni, vagy más megoldás kell, a feladat dinamikájától függően (például: kivétel-e, hogy néhány esemény "összekapcsolódik", vagy van egy fő téma, és egy ilyen témához sok esemény kapcsolódik).
Minden ilyen rész adatot elemezni kell ilyen szemmel és az alapján megtervezni hozzá a táblákat, a kezelt adatokat és a kapcsolódásokat.
Tranzakciós táblának auto increment kulcsot érdemes választani.
Minden, más táblához kapcsolódó mezőt érdemes indexelni.
Modellezz le minden lehetőséget fejben. A kész DB-ben átstuktúrálni valamit nagyon gáz, ha már felépítetted a logikát. Arra is készülj, hogy több lépésben lesz meg az optimális szerkezet.
Ha megtervezted, akkor gondold végig, hogy mindenre alkalmas-e, amit látni szeretnél. Kb az, amit leírtál, de legaprólékosabban belemenve a részletekbe is. Mert igaz, hogy mindenkinek 2 telefonja van, de a "Józsinak 3, mert...".
AMi nekem hiányzik, az az "esemény" tábla, ahol ezek a dolgok összekapcsolódnak (vagyis, az adat, amit gyűjtenél).
Ez lett volna a következő kérdésem.;) Az esemény több eset lehet. Az eseteket tudom kezelni a 2-es eset táblában és van hozzá kód is, pl. személyes találkozó, vagy üzleti megbeszélés, stb. de az esemény az több esetből állhat. Ezt még nem tudom, hogyan lehet kezelni.
A másik: fontos a személyek és cégek viszonya.
A személy lehet magánember, amikor csak a személye számít, de lehet kétféle céges kapcsolata, egyik, amikor valahol alkalmazott, a másik, ha saját cége van. Ez a három sajnos gyakran jellemző, de el kell különíteni őket.
A telefonszámok, címek is érdekes kérdés
Az embernek jellemzően két telefonja van, az egyik a lakásához (lakcim) tartozik, a másik a mobilja. A cégnek jellemzően van központi telefonszáma, és annak mellékeiről lehet az alkalmazottat hívni, tehát ott az egyén-cég-beosztás -hoz tartozik a mellék. De olyan is van, hogy az adott szobához tartozik közvetlen telefonszám, az is egyén+cég+beosztás -hoz tartozik. Ha van céges mobilja, akkor az az adott egyén+cég -hez van rendelve.
Háromféle címet kell kezelni: Az egyénnek van lakcíme és postacíme, vagy ideiglenes címe, ahol üzenetet lehet hagyni. A cégnek van székhelye, és vannak telephelyei, és van postacíme. Ha az egyénnek van saját cége, a cég címe lehet az ő lakcíme is egyben. Valamint a "hol" táblához is tartozik egy cím, ahol az események történnek.
AMi nekem hiányzik, az az "esemény" tábla, ahol ezek a dolgok összekapcsolódnak (vagyis, az adat, amit gyűjtenél).
A másik: fontos a személyek és cégek viszonya. A személyek a céghez tartoznak, vagy a cégekkel állnak kapcsolatban - azaz, partner vagy saját?
A telefonszámok, címek is érdekes kérdés: egy céghez több cím is tartozhat? (telephelyek?), HA igen, azt külön kell venni.
Annak nincs értelme, hogy egy telefon kódot teszel hozzá a személyhez és külön táblába teszed a telefonszámot. Két dolognak van értelme:
- vagy a telószámok mennyisége korlátozott és akkor több telefonszám mezőt veszel fel (Magán1, magán2, céges, fax.. stb.),
- vagy lehet sok, akkor viszont NEM a telefon táblát kell a dolgozónál/cégnél meghivatkozni, hanem a telefon táblában kell egy olyan mezőt felvenni, hogy mely dolgozóhoz, céghez kötődik, így lehet több telefon (tetszőleges számút) egy céghez/dolgozóhoz rendelni.
Innen jön az is, hogy fontos a cég és a dolgozó viszonya. HA ugyanazon adatok kellenek (kb, kis eltéréssel) a dolgozónál és a cégnél, akkor lehet érdemes egy táblába tenni és egy választó mezővel megkülönböztetni, hogy cég van dolgozó (és pl, a cégnév mezőt nem kell dolgozónál /személynél kitölteni).
HA a személy céghez rendelt, akkor a személy listában kell egy cég azonosító, KIVÉVE, ha egy személy több céghez is rendelhető (Ha így van, bonyolódik a dolog, akkor kell egy segéd tábla - dolgozó-cég összerendelés, VAGY, duplán kell felvinni a dolgozót a dolgozó táblába - ez utóbbi akkor járható, ha kevés ilyen eset van - kvázi kivétel - ha sok, akkor káoszos).
A cím tábla szintén ilyen, ugyanezzel a logikával kezelhető.
Ha táblát tervezel, nagyon fontos, hogy az össze tartozó adatokat együtt, a nem összetartozókat külön kell kezelni. Például, nincs értelme a címet, telefont külön táblába venni, ha egy személyhez csak egy ilyen rendelhető, akkor bele kell tenni a megfelelő táblába.
Ami még fontos, az adatfüggetlenség, olyan adat, ami változik, nem vonhatja magával azt, hogy egy másik adatnak is változnia kell, ez alól is lehet kivétel, de csak ésszel és kivételként.
A gyakorlatban nem biztos, hogy mindig le kell teljesen normalizálni minden táblát, mert nagyon összetett (feleslegesen összetett) táblaszerkezetet kaphatsz.
Alap szabály, hogy amit sima user-ek töltenek, kezelnek, azt le kell normalizálni.
Amit Te - mint admin - töltesz - azt nem feltétlen, hiszen ismered az adatbázist és tudod, hogy mihez, hogyan kell nyúlni. Ezt egyébként nem is árt leírni, mert 1-2 év távlatából macera kitalálni, hogy mit is akartál és miért, akkor...
Nem voltam benne biztos, hogy olvassa ezt valaki.;)
A négy csoport kevés, kellenek kiegészítő csoportok, a kapcsolatokhoz kérek segítséget, mert nekem rossznak tűnik az 1:n kapcsolatsor.
Az adatrögzítés logikája alapján a mikor a kezdet, amihez rögtön kapcsolódik a miért és a hol, végül a ki, csakhogy mindegyiknek vannak egyéb kapcsolódásai. (ki-nek van magán telefonja, lakcíme és cége, a cég-nek is van céges telefonja és céges címe, és hol-nak is van címe, tehát cég, tel es cim kell még) (A "-hoz" végzodesuek jelzik a kapcsolatot a masik tabla id-hoz)
Eddig jutottam:
1 mikor id_mikor datumidokezd datumidovege esettipus (lista) mierthez
A 3. normálformáig mindenképp érdemes átnézni, az fölött kezdő szinten nem kell.
Másrészt, ha segítséget kérsz, mindenképp kellenek az adatok pontos tulajdonságai, ez alapján lehet tervezni. Amit leírtál, ehhez nagyon kevés, több infó kell.. például mik a kulcsmezők, hogyan kapcsolódnak az adatok egymáshoz, pontosan milyen infókat akarsz nyilvántartani és azoknak mik a jellemzőjük (például: a mikor az egy időtartam vagy egy időpillanat) stb.
És, ez még csak a szerkezet, utána az adatkezelő felületeket is meg kell írni...
Ha valaki tudna segíteni egy vénembernek létrehozni Acces2007-ben egy adatbázist, ahol négy adatot, (ki, hol, mikor, miért) egyben lehet kezelni, nagyon hálás lennék.;)
Az alapadatokból négy táblát létrehoztam, de az összekapcsolásoknál már el is akadtam.:-(
Úgy tűnik, több kiegészítő adat kell, de kicsit trükkösnek tűnik.
Dátum problémára megvan a megoldás. Azokon a gépeken, amin nem volt jó a dátum, az adatbázis megnyitásakor a következő dll-t kereste: emodelviewer.dll.
Nem tudom ez miért kell, de ha ezt odamásolom a gépre, akkor működik a dátum...!?
Technikailag valószínű megoldható (alapértelmezett értéket kell átírni mindig), de nem tartom jó ötletnek.
Az adatbevitelnél fontos dolog, hogy a tévedés lehetőségét csökkenteni kell, és egy dinamikus alapértelmezett érték ilyen szempontból nagyon nem jó, mert téves adatbevitelt okozhat.
Ezért, ezt úgy oldanám meg, hogy a fejlécbe tennék egy mezőt, ami nincs táblához kötve ("fejlécadat"). Ha a felhasználó ezen - az elkülönített - területen beír egy értéket, akkor ezt már be lehet tenni alapértelmezettként (ha a fejléc mezőt írod, akkor frissítés után eventbe ("adat" - a táblához kötött beviteli mező, "fejlécadat" - táblához nem köthető, kitölthető mező):
adat.defaultvalue ="'" & fejlécadat & "'" )
Az idézőjel fontos a "defaultvalue" értéknél.
Ja, és úgy illik, hogy a form.open eseményben: adat.defaultvalue ="", azaz megnyitáskor (amikor a nem táblához kötött mező értéke üres, ne legyen alapértelmezett érték).
Segítségeteket szeretném kérni hogy lehet azt megoldani, hogy Űrlapon adatbevitelnél pár mező tartalmát "megjegyezze" az ACCESS a következő új rekordra ugráskor, mivel ismétlődő adat, ne kelljen mindig kiválasztani a Beviteli Listából.
Irányított szűrés segítségével kellene megjelenítenem egy táblából,egy születési dátumból [szuletett], akiknek júliusban van vagy volt a születésnapjuk! Sajnos nem jövök rá, hogy kell, pedig házi feladatom,
Megpróbálom, de azt hiszem kezdek rájönni, hogyan tegyem manuál szerkesztésként.
Van a jelentésben fejléc, törzs, oldalláb és dokumentum láb terület.
Szerintem úgy kell tagolnom, hogy a fejléc a fix mezők az elején, utána a törzsbe a változó méretű terület, utána az oldalláb pl. oldalszám (ez el is hagyható) és a dokumentum lábba tenném az ajánlat lábrészét az aláírással és az egyéb fix záró mezőkkel.
Ha jól gondolom, így a törzset addig fogja nyomtatni, ameddig minden sort kitol és utána rak mögé csak dokumentum lábrészt, ami az ajánlat vége, aláírás, stb.
Ha nem adsz meg semmilyen területet, csak készítesz egy jelentést a varázslóval, akkor mi történik? Szerintem magától kell annyi oldalra tördelnie, ahogy kifér.
Csak nagyok apróka alkalmazásokat készítettem Access-ben, de a mostani feladathoz hasonlót soha.
Access bibliában sem találok megoldást, vagy rossz helyen keresem.
Kicsit hosszú a leírásom, de remélem érthető, mit szeretnék megoldani.
A feladat egy nyomtatás előkészítése, ennek a formátuma, jelentés elkészítése.
Készítettem egy ajánlatkészítő alkalmazást.
A rögzítés, keresés, szűrés szépen megy.
A feladat, hogy egy rögzített árajánlatot ki tudjak nyomtatni (papírra, vagy pdf formában).
A jelentésen elhelyeztem a megjelenítendő mezőket, amik fixek.
Pl. a fejlécen a cégünk adatai, feladó, mellette a címzett, ajánlat kelte, iktatószám, bevezető rizsa, stb.
Ez után kellene megjeleníteni az ajánlati sorokat.
Ez olyan, mint egy számla.
Soronként cikknév, mennyiség, egységár, nettó, bruttó, stb.
Ez lehet akár 50 sor is, vagyis 50 táblasor.
Ennek a táblának a hossza ezért kilóghat abból a "területből", amit megadok az A4-es méretű oldalon.
Ezt az elemet követné a lábrész, amin aláírás, fizetési feltétel, érvényesség, stb. van, ami szintén fix mezők, nem listák.
A kérdésem, hogy azt a bizonyos táblát, ami sok sorból is állhat, adja a tételeket, azt hogyan tudom a sorok számának megfelelően megjeleníteni és hogy amikor az utolsó tétel is megjelenik, az után kerüljön a lábrész megjelenítésre?
Jelenleg az történik, hogy annyi sort látok nyomtatva, ami ebbe a jelentésben megadott területbe belefér, az látszik, a többi sor nem.
Gondolom, ide egy lapdobás kellene. ... vagy nem. :-D
Köszönöm a segítségeteket, vagy a kérdéseket, hogy mit írtam baromi értelmetlenül. :-D
Új vagyok a forumon. Elöször vagyok itt. Ajánlom segitségemet (tudasomat, tapasztalatomat, ...) bárkinek aki rászorul. Nagy gyakorlattal rendelkezem: Access adatbazisok-és minden ami még hozzá tartozik.
Az Access-ben nincs nézet, készíts egy lekérdezést és az jó lesz annak.
Ha fontos, hogy ne lehessen módosítani (ha egyébként módosítható), akkor a lekérdezés tulajdonságok között állítsd be a típusnál, hogy "Pillanatfelvétel" (az "eredményhalmaz" helyett).
Accessben minden lekérdezés tulajdonképpen view, tehát nem csak táblára, hanem minden lekérdezésre tudsz újabb lekérdezést építeni, ezért a lekérdezések nagyon jól és átláthatóan strukturálhatók. Olvass utána az Access leírásban. Sokkal többet tud, mint egy "mezei" view.
(SQL szerver View-et természetesen fel lehet csatolni táblaként, de ekkor - talán?? - a kulcs mezőt kézzel kell megadni).
