Az „Excel” fórum célja, hogy keretet adjon az Excel felhasználók széles táborának tapasztalataik megosztására, és lehetőséget a segítséget kérőknek. Az alábbi összefoglaló azért készült, hogy segítse a helyes kérdésfeltevést.
– Írd le szabatosan a problémát. Úgy fogalmazz, hogy ne csak te magad, de a szakértő is megértse, mire szeretnél választ kapni.
– Írd le, hogy milyen verziójú Excellel dolgozol. (Vagy ha nem – ill. nem csak – Excel, akkor micsoda?)
– Írd le, hogy milyen úton indultál el, és hol akadtál el rajta.
– A kérdés megértése szempontjából sokat segíthet, ha feltölteszt egy képet, amin látszik, hogy mit szeretnél, vagy illusztrálja azt.
– Még jobb, ha feltöltesz egy minta munkafüzetet valahová (pl. data.hu). Feltöltés előtt távolítsd el belőle a nem publikus adatokat.
– Ha a feladat jellege olyan, célszerű az "előtte" és "utána" állapotokat bemutatni. (Miből kellene csinálni mit?)
– Ha VBA kódon kell javítani, másold be a releváns kódrészt. Rövid kód mehet hozzászólásba, hosszú kód inkább ide: http://pastebin.com/
– Ha valami nem úgy működik, ahogy kellene, add meg a rendellenes viselkedés jellemzőit, a hibaüzenetet, és a hibát okozó programsort.
De nem időhatárhoz, hanem célhoz köti a jogszabály az adattárolást. Tehát addig tárolható, amíg a cégnek a feladatai ellátásához szüksége van rá, és ezt igazolni is tudja, és a mérlegelés során az derül ki, hogy nagyobb érdek fűződik a megtartásához, mint a törléséhez.
Bár nem a megoldáshoz kapcsolódik, de azért én megnézném ezt a célkitűzést GDPR szemüvegen keresztül. Szerintem kizárt, hogy a GDPR engedi több évtizedre visszamenőleg, kvázi határozatlan ideig a személyes adatok tárolását/nyilvántartását. Így még az is kiderülhet, hogy nem kell megoldani a feladatot, vagy nem ezt a feladatot kell végül megoldani.
Ez a ChartObject szembe jött már korábban, csak amennyire tudom, .NET 4.8 kell hozzá, és kétséges, hogy ez elérhető lesz ott, a hová a program készül. Amúgy VB.NET-ben készül.
Viszont a kérdésre a cikk részben választ ad, ha jól látom. (A C# kottaolvasás még nem megy folyékonyan, de majd kibogarászom.) És akkor már csak a form méretváltozás lekövetését kell még valahogy kezelni.
A legegyszerűbb az, hogy a születési dátumot és a nevet összekapcsolod - mivel ettől egyedivé válik egy-egy dolgozó.
Ezt megteheted egy segédoszlopban (tehát név&szüeltési dátim, vagy jó az összefűz fgv is), ami aztán az fkeres függvényed keresési (első) oszlopa lesz, a keresési feltétel pedig szintén összefűzve, hogy egymásra találjanak.
Fentieken kívül még meg kéne nézned, hogy nincs e esetleg egy olyan ID, ami a dolgozót azonosítja egyedileg - ez lehet akár egy adószám is. Ha van ilyen, akkor ezzel már lehetne keresni fentiek nélkül is.
Ha a Kártyák tábla tartalmazza a dolgozó nevét is akkor abban a táblában szűrj rá a kártyatípusra és megkapod a kívánt listát. Persze ha a néven kívül nincs más azonosító a kártyák táblában, akkor sajnos azonos nevek esetében nem tudhatod, hogy melyik kártya melyik dolgozóhoz tartozik !
Ha a Dolgozók táblában szeretnéd jelölni, hogy ki milyen kártyával rendelkezik - kvázi kereszttáblás módon -, akkor ugyanez a probléma áll fenn. A név nem megfelelő egyedi azonosító. Kell valami más kulcsot találni, ami egyedi azonosító. Cégeknél ilyen szokott lenni a törzsszám pl.
Ezt az egyedi azonosítót kell mindkét táblára applikálni. Utána készíthetsz összekapcsolt listákat.
A problémám amelyhez segítséget kérnék nekem bonyolult és kevés a rutinom egy jó megoldáshoz.
Lényeg: -Van egy cég, ahol dolgoznak 7000-en (Dolgozók tábla)
-Van egy szigorúan sorszámozott belépőkártya nyilvántartás (Kártyák tábla), visszamenőleg több évtizedre személyre kiadva
A Kártyák tábla több tízezer soros, mert többféle kártya van, továbbá aki elmegy a cégtől és visszajön, az ismét új kártyát kap, tehát ebben a listában ugyanaz a személy akár 6X is előfordulhat (több féle kártya, elmegy-visszajön...)
Listáznom kéne azokat a (Dolgozók) táblából, akik rendelkeznek ilyen kártyával
Fkeres függvénnyel kezdtem (A dolgozó nevét összevetette a kártya tábla "név" oszlopával), de nagyon sok név ismétlődik (Nagy János, Tóth Gábor...) és többen születtek egy napon is, ez bonyolítja a listázást.
(570 alkalommal ismétlődő név)
(236 alkalommal ismétlődő születési dátum)
Egy pozitívum van, hogy nincs olyan egyező nevű, aki egy napon született volna a másikkal :)
Van valami ötletetek, hogy milyen logikai úton lehetne áthidalni ezeket a dolgokat?
Felvetném az alábbi kérdést, mert szerda az ötletgyűjtő napom.
Dolgozom egy programon, amelynek van egy olyan része, amely grafikonon ábrázolja egy bizonyos mennyiség változását az idő függvényében. Nem Excel program, tehát nem az Excel beépített grafikonjait használom, hanem - jobb híján - nekem kell gondoskodni a teljes ábra kirajzolásáról, beleértve az X és Y tengelyeket, meg magukat az adatsorokat is. Egy-egy adatsor több tízezer vagy akár százezer pontból is állhat, ezért be kell építenem egy zoom funkciót, amivel a finomabb részletek is megjeleníthetők. Mindez azért lényeges, mert zoom közben változik mindkét tengely nullpontja és a befoglalt értéktartományok is.
A tengelyeket természetesen feliratozni kell, mellé- illetve alátenni a skálát, nagyobb és kisebb beosztásoknak megfelelő kis vonalkákat behúzogatni, hozzájuk tartozó értékeket kiírni. Ennek favágó módja az, hogy fogom a tengely elejét meg a végét, felosztom pl. 10 egyenlő részre, kiszámolom, hogy az egyes osztásokhoz milyen érték tartozik, megrajzolom, és kiíratom a számokat. És így kapok egy időtengelyt, pl. ilyen osztásokkal:
7,7658
8,2327
8,6996
9,1665
9,6334
10,1004
10,5673
11,0342
11,5011
11,9680
12,4350
Aztán ember legyen a talpán, aki erről bármit leolvas. Ezért én egy nem-favágó módszert szeretnék, ahol a tengelyek intelligens módon követik az aktuális zoom-ot, és a lehető legkerekebb értékeknél vannak a beosztásjelek elhelyezve. A fenti példánál talán úgy lenne optimális, ha 7,8-tól kezdve 0,1 percenként helyeznék el számozott osztásjeleket, 0,02 percenként pedig nem számozottakat. Vagy esetleg 0,2 percenként számozott, 0,05 percenként nem számozott osztásokat. Vagy nem tudom. De fontos, hogy az eredmény jól nézzen ki.
Hab a tortán, hogy a grafikon (természetesen) egy form-on van, és a form átméretezhető. Ha átméretezik, akkor a grafikon mérete is változik. Nagyobb grafikon tengelyein több karakter fér el, pl. egy teljes képernyős grafikon X tengelyén el tudok helyezni akár 20 vagy több feliratozott beosztást is. De ha ugyanezt a form-ot lekicsinyítem mondjuk 400x100 pixelre, akkor az X tengely által befoglalt értéktartomány ugyanaz marad, de a 400 pixel helyen nem fér el 20 felirat, csak egymás hegyén-hátán.
A kérdés tehát a következő:
milyen algoritmussal lehetne meghatározni, hogy
- az aktuális, pixelben mért grafikonméret, és
- az aktuálisan befoglalt értéktartomány
mellett mi lenne az - esztétikai és leolvashatósági szempontból - optimális tengelybeosztás?
Másodsorban: Ez egy jó hely a segítségre szorulóknak
Harmadsorban: Ez egy jó hely a vállveregetést, elismerést($) más fáradtságán bezsebelő, tudást nélkülöző kollégáknak.
Negyedsorban: Ez egy jó hely a játékhoz, a fejlődéshez, feladatok megoldásához - azzal az eszközzel, amit szeretünk.
Ha a kereslet(kérdés) és a kínálat(válasz) megfelelő szinten találkozik, működik. De van amikor:
Ahogy JTH írta: "...meghaladja a jótékonysági keretemet...."
Ennél az embernél nincs jótékonysági keret, elfogadom - "Harmadsorban" gondolkodik. Persze lehet, hogy itteni másodnick és majd itt kérdezi meg, ha kap valakitől "cash" típusú feladatot ;)
...és tényleg nem egy ilyen közösségben kéne szpemmelni...
Pont azon töprengtem, hogy megkeresem ezt a Tamást egy szaftos kis problémával, hogy oldja meg nekem.
Meg azon is, hogy vajon ki lesz az első, aki a fórumon elérhető ingyenes tanácsadás helyett az ő fizetős megoldásait választja majd. Anélkül, hogy egyébként bármit bizonyított volna itt.
Borsos Miklós szobrász a tihanyi háza elé kőoroszlánokat faragott, és alájuk ezt véste: "Nem haragom, alakom Őrködik e falakon"
Mivel az oroszlánok inkább hasonlítanak kutyákra, a szobrász barátja, Szedő Dénes írt egy kétsorost, ami annyira megtetszett Borsosnak, hogy ezt is bevéste. "Ülök napszám, áloroszlán, ebül vésett ki a gazdám."
Figyu, ezt egy nappal és 5 hozzászólással ezelőtt írtad be utoljára, még félig se süllyedt el. Ez agy nagyon nem lesz jó! És fogadni mernék, hogy nem tartottad be a netikettnek azt az ajánlását, hogy olvass vissza, és ismerd meg a szokásokat, és nem olvastad el a fórumszabályzatot sem.
Ez itt egy segítő fórum, nem egy ingyenes reklámfelület. Az első beírásodért nem szólt senki, elfért. De ez már sok így. Ha idejössz közénk fórumozni, és 100 alkalommal ingyenesen segítesz másoknak, és a 101. alkalommal azt mondod, hogy bocs, de ez már pénzes meló, megint nem fog szólni érte senki. De azért nézz körül, hogy mások mekkora munkát tesznek bele, amit még jófejségből csinálnak, pl. mekkora makrókat írnak meg. Bizonyára nem kerülte el a figyelmedet baloldalt a nicked alatt a Maga itt mit reklámoz? link, ahol a legális reklámozás feltételeiről tájékozódhatsz.
Excel megoldások területén (is) dolgozom, szívesen ajánlom fel szolgáltatásaimat szakdolgozatok excellel összeállítandó részeinek (kimutatás, diagram, pivot, vizuális megjelenés-tervezés stb.) kreatív előállításában. Vállalom továbbá munkahelyi rutinfolyamatok automatizálását, prezentációk összeállítását, összefoglalva: bármilyen excel alapú feladat megoldását. Bármilyen jellegű excel problémába ütközöl, kérlek, keress az alábbi elérhetőségen, találunk rá megoldást!
A LibreOffice-t nem írtam fel, mert még a szabad szoftver elszánt hívei is elismerik, hogy az adatbázis-kezelő egy gyengén sikerült rész benne. Nem olyan önálló, egységes program, mint az Access, hanem egy felület + egy motor, a motor régebben kénytelen volt MySQL lenni, mert a sajátja csapnivaló volt, most már a sajátja is kezd felzárkózni, de én egyelőre nem tudom jó szívvel ajánlani, addig még sok víznek kell lefolyni a Dunán.
A 3. pontod kicsit másképp fogalmazva: az Excelben vészesen összekeveredik az adattárolás az eredményekkel, számított értékekkel. Egyszerű esetekben ez nem okoz problémát, ilyen bonyolult esetekben káoszhoz is vezethet.
Ha cél oldalról közelítjük, akkor a főnökök és egyéb steak holderek kötözködését csak profi rendszerrel lehet kivédeni, és ha profi rendszerről beszélünk, akkor az Excelt felejtsük el. A nyugdíjas mami bevezetése is ezt a vonalat erősíti (kivéve, ha nyugdíjas informatikusról van szó). Viszont ezt feladatot profi és laikus-barát módon megoldani nem kis munka. Nekem biztosan meghaladja a jótékonysági keretemet. Arról nem beszélve, hogy bármennyire is profi egy rendszer 1. verziója, mire eléri végleges formáját, számos új igényt és módosítást kell utólag beleépíteni, tehát a leszállítás után még terméktámogatás is kell 1-2 évig. Szerintem ez nem megy ingyen. Szóval itt a vezetőségnek első körben arról kellene döntést hoznia, hogy hajlandó-e megfizetni egy profi rendszer árát.
Valamiért az a gyanúm, hogy nem lesz hajlandó. Akkor viszont, mint szerencsés nyertesnek, neked kell eldöntened, hogy hogyan tovább. Én az alábbi 3 utat látom:
1) adatbázis-alapú megoldás:
Ehhez kell vagy Access, vagy az SK által felsorolt rendszerek bármelyike, de szerintem az ingyenes LibreOffice adatbázis-kezelője is jó lehet, bár én ez utóbbival sosem dolgoztam, de legalább magyar nyelvű a kezelőfelülete. Kell továbbá az a bizonyos adatbázis-szemlélet, amely lehetővé teszi, hogy az adatbázisod felépítését jól tervezd meg. Merthogy lehet rosszul is tervezni, ami legalább akkora szívás, mint ha nem adatbázissal oldod meg. Ha viszont jól tervezed meg, akkor viszonylag kevés erőfeszítéssel bármilyen szükséges információt ki tudsz nyerni belőle.
Ha még ilyesmivel sosem foglalkoztál, akkor az már rövid távon jó sok tanulást jelent, illetve annak elfogadását, hogy ez nem könyvből bemagolható, hanem tapasztalati tudás, más szóval: gyakorlat teszi a mestert.
2) Excel-alapú megoldás adatbázis-szemlélettel:
Ez lényegében ugyanaz, mint az 1), csak az adatbázis-kezelést nem egy erre dedikált alkalmazásban, hanem Excelben valósítjuk meg. Az Excel munkalapokat adatbázis-tábláknak tekintjük, megtervezzük a felépítést, létrehozzuk a kapcsolatokat, lekérdezéseket, stb. Az Excel - bár nem való, de - alkalmas erre, és vannak különösen jól használható részek, mint pl. MS Query, vagy újabban Power Query. De egy csomó olyan dolgot, ami egy adatbázis-kezelő alkalmazásnak magától értetődő, itt kézzel kell megcsinálni, nem ritkán VBA programozással. Úgy gondolom, nulláról indulva ez nagyobb kihívás, mint megtanulni az Access használatát, ezért ez az út lényegében csak akkor ajánlható, ha az 1) valamiért nem járható. Ami jelenleg nem áll fenn, ha jól értem.
Ez az, amivel eddig is próbálkoztatok. Nehéz szabatosan leírni, de talán úgy fogalmaznám, hogy az adattárolás nem normalizált táblákban történik, hanem olyan formában, aminek egy normál adatbázisban lekérdezésnek vagy riportnak kellene lennie. Rögtön látszik belőle az az egy információ, aminek a szemléltetésére ki lett találva. De ha bármi mást be akarsz mutatni, akkor kiderül, hogy - rosszabb esetben - a keresett információ nem nyerhető ki az adatokból, de - jobb esetben - transzformálni kell a meglévő adatokat egy új formába, amiből látszik a válasz az új kérdésre. És ezt gyakran annyiszor meg kell csinálni, ahányszor szükség van az új adatra, pl. hetente, havonta, mígnem a kezelő megunja, és azt mondja, hogy jó, akkor gondoljuk újra az egészet. Nem beszélve az adatnormalizálás elmaradásából adódó problémákról.
Ennek az útnak előnye, hogy viszonylag hamar, kevés szakmai tudással is meg lehet valósítani. Hátránya a rugalmatlanság, a sok hibalehetőség, és hogy jó strapabíró ülep kell az üzemeltetéséhez.
Excel megoldások területén dolgozom, szívesen ajánlom fel szolgáltatásaimat különböző pl. munkahelyi rutinfolyamatok automatizálására, prezentációk összeállítására, vagy akár szakdolgozatok kimutatásainak kreatív előállításában.
Bármilyen jellegű excel problémába ütközöl, kérlek, keress az alábbi elérhetőségen, találunk rá megoldást! :)
Durván így nézne ki táblákban, de nagyon sok a nyitott kérdés. A sorrenden variáltam.
Terem lista a befogadóképességgel. OK, ez így egy tábla, mindegyiknek lesz azonosítója. Klub lista az aktuális klubvezetövel és az aktiv létszám számával, szintén most már havonta (a vezetőségnek kell havi statisztikához) Egy táblában a klubok, a vezető azonosítója az emberek közül, a létszám lekérdezés eredménye. Terem lista heti naptárban, mikor melyik klub foglalja - havi változat kell, igy évente 12 kell belöle (a vezetőségnek kell havi statisztikához) Nem stimmel, a hetek és a hónapok átfedik egymást. Egy terem hétfőtől vasárnapig egy klubé? Akárhogy is, ez nem tárolandó adat, hanem lekérdezés.
Klublista havonta, melyik termekben a hét mely napján és mikor vannak es mennyi a tagsági díj (mert az új jelentkezőket ezek érdeklik) Az eleje lekérdezés, a tagsági díj tárolható a klubok táblájában, ha mindig csak az aktuális kell, és visszamenőleg nem, de kötve hiszem, hogy ne akarja egyszer valaki visszamenőleg is tudni. Klubok taglistája a belépés havi dátumával Egy ember ugye több klubban is lehet tag? Kiléphet és beléphet többször is? Az emberekből kéne egy tábla, aztán egy kapcsolótábla: klubazonosító, belépési dátum. Klubonkent az aktív és passzív tagok listája (aki tagdíjat fizet, az aktív, de most már havonta van tagdíjfizetés, igy havi lista kell) Helyett egy tábla, az ember azonosítója, a klub azonosítója, fizetés dátuma, ebből a többi lekérdezhető. *
Szintlén most akarnak egy új listát is, hogy melyik teremben melyik klub mikor okozott kárt és mennyit fizetett érte (hátralék soha nincs, a könyvelőnek kell) Ez egy külön tábla, teremazonosító, klubazonosító, dátum, összeg.
Most akarnak olyan személyenkénti listát is, hogy ki melyik klubban mikortól tag és mikor fizetett tagdíjat és mennyit (vezetőségnek, illetve a program kezelőjének és a könyvelőnek is kell) Lásd fent a * részt, ugyanaz, másik lekérdezés.
Ja, az Sqlite nem angol, mivel senki nem fogja direktben konzolról használni, aki nem informatikus. Ahhoz kell írni egy programot, ami olyan nyelvű lesz, ahogy megírják. Ugyanez a helyzet a MySQL-lel és a PostgreSQL-lel is. A nyelv egyedül az Accessnél szempont, de egy nyugdíjas néni is tudhat angolul, vagy megtanulhatja azt a pár szót, vagy készíthet neki valaki egy sillabuszt. Az űrlapok már lehetnek magyar nyelvűek.
Egy dolog nem fog menni akkor sem, ha a vezetőség nagyon szeretné: a gyakorikerdesek.hu-stílusú megoldás, hogy a) azonnal b) ingyen, c) házilagos módszerrel, szakember nélkül, és még jó is legyen.
Ha most belefeccölsz egy csomó munkát egy működő táblázatba, akkor hamar fognak jönni az újabb kívánságok, amikre nem tudsz reagálni.
Access2003, Sqlite, MySQL, PostgreSQL is jó lehet.
Sok mindent meg lehet oldani Excelben, csak nem biztos, hogy célszerű. Különösen akkor, ha az idők során újabb kívánságok merülnek fel. Ezeket egy adatbázisos megoldásba könnyebben be lehet építeni, Excelben újra és újra szenvedés lesz vele. Szóval ez így valóban adatbázisos feladatnak tűnik, és ha komolyan szükség van rá, érdemes pénzt áldozni rá.
A D2 cellába beírom az = jelet, rákattintok az A2-re, megjelenik a [@név]. Folytatom a képletet & " " & , majd rákattintok a B2-re. Ha jól emlékszem, a 2007-es verziótól kezdve írja automatikusan így a táblázatok képleteit, hogy a címsorra hivatkozik. Személy szerint nekem szimpatikusabb a rongyos régi =A2 & " " & B2 forma.
Bocsánatot kérek mindenkitől, most egybe írom, mert múltkor nem engedett a fórum többet írni, így nem tudtam pimrének is megköszönni a javaslatokat, nagyon sokféle tábla van és kell még.
Jimmy kérdésére válaszolva az igazi cél az, hogy végre béke legyen.
Órákig tudnék írni, csak amit hallottam, hogy a könyvelőktől kezdve a különböző cserélődő kisfőnökökig ki mibe kötött bele és milyen balhék voltak. A legújabb mánia az, hogy a teremfoglalást havonta lehessen változtatni.
Ami biztosan kell: Terem lista a befogadóképességgel. Terem lista heti naptárban, mikor melyik klub foglalja - havi változat kell, igy évente 12 kell belöle (a vezetőségnek kell havi statisztikához) Klub lista az aktuális klubvezetövel és az aktiv létszám számával, szintén most már havonta (a vezetőségnek kell havi statisztikához) Klublista havonta, melyik termekben a hét mely napján és mikor vannak es mennyi a tagsági díj (mert az új jelentkezőket ezek érdeklik) Klubok taglistája a belépés havi dátumával Klubonkent az aktív és passzív tagok listája (aki tagdíjat fizet, az aktív, de most már havonta van tagdíjfizetés, igy havi lista kell)
Szintlén most akarnak egy új listát is, hogy melyik teremben melyik klub mikor okozott kárt és mennyit fizetett érte (hátralék soha nincs, a könyvelőnek kell)
Most akarnak olyan személyenkénti listát is, hogy ki melyik klubban mikortól tag és mikor fizetett tagdíjat és mennyit (vezetőségnek, illetve a program kezelőjének és a könyvelőnek is kell)
Ahogy nézegettük, lényegében négy adatsort kell egymással variálni, de többnyire egyszerre csak három kell belőlük egy táblában: Klubok, Nevek, Termek, Hónapok (évek szerint)
Arra jöttünk rá, hogy a Klubok és Nevek és Hónapok és a fizetett tagdíj együtt kezelésével jön az aktív Klubtagok listája, és máris megvan rögtön havi bontásban.
Delila megoldása jónak tűnik, hogy kettőt (klubok és nevek) összevon és egy harmadikkal összekapcsolja, csak kellene egy kis tanfolyami okítás, hogyan csinálta és hogyan működik.
Ha lehet valahogy definiálni, hogy vannak termek, és vannak klubok és vannak emberek, akik vagy klubtagok vagy nem, illetve aktívak vagy passzívak, és lehet ezeket úgy kezelni, hogy nincsen véletlen törlés vagy felülírás, és másik lapon is az a név jelenik meg, ami az elsőn és a többin, az nagyon jó lenne.
Vártam eddig, de sajnos Delila nem válaszol egy ideje, hogy hogyan csinálta és nem jövök rá magamtól, a szögletes zárójeleknél semmi kapcsolatot nem találok mással. Ha valaki tudna segíteni, miért és hogyan működik, örömmel megvilágosodnék.
És valóban fontos kérdés az is, ha sok név lesz, hogyan lehet őket használni, főleg, ha egy nyugdíjas nénire fogják bízni a kezelést, ahogy a legújabb ötletet hallottam.
Utána kérdeztem, van 2003 Access is egy külön gépen, de angol nyelvű Professional csomagban, adomány volt, eddig senki se használta, most a nyakamba akarják varrni, ha excelben nem lehet megoldani.
Valamint valaki említette a Sqlite-ot is, de az nemcsak angol, hanem ahhoz már programozó is kell, hogy működjön.
De amúgy ha ezen bukik el a keresés, azon tudunk segíteni. A Workbooks.Open utasításnak van egy ReadOnly paramétere, ha azt beállítom Igaz-ra, akkor nem fog rákérdezni az írásvédelmi jelszóra. A keresést meg írásvédett módban is el lehet végezni.
Később a nap folyamán módosítom a kódot, aztán posztolom az új verziót.
A Mentés Másként ablakban a Mentés gombtól balra van egy Eszközök feliratú lenyíló, abban a Beállítások menüpont. Itt tudsz megadni két egymástól független jelszót, egyiket a fájl megnyitásához, másikat az írási jog megszerzéséhez. Illetve itt tudod törölni is őket, ha be vannak állítva.
