Hirdetés
- Notebookosított mini PC-t leplezett le az AOOSTAR
- Vélemény: más cég lenne az Intel, ha korábban nevezik ki Lip-Bu Tant
- Barátságot teremtene az ARM és az Anti-Cheat rendszere között az Epic Games
- Hamarosan foghatja a kezét a Copilot a játékosoknak
- Az NVIDIA szerint a nagyobb készletek stabilizálják majd az új GeForce-ok árait
Új hozzászólás Aktív témák
-
baracsi
tag
Szóval nekem nincs két táblám
Nincs jelentősége annak, hogy bizonylatokból veszi az ember az adatokat vagy egy készletmozgás-történet táblából. Ezért kell valamilyen procedurális megoldás, hogy fel tudd dolgozni az adatokat.
Én úgy csináltam, hogy a függvény csinál 2 temp táblát fifo_bevet_vt és fifo_eladas_vt, az egyikbe legyűjtőm a bevételezéseket (leltárt és gyártást is figyel, de az jelen esetben lényegtelen és még egyszer mondom mindegy, hogy honnan vesszük az adatokat, bizonylat vagy mozgástörténet), a másikba az eladásokat adott termékre, mindkét tábla dátum, db és ár mezőket tartalmaz. Az adatok legyűjtése után elkezdem bejárni az eladásokat dátum szerint sorba rendezve majd veszem a mennyiségét és nézek hozzá egy bevétet, itt is mindig a legkisebb dátumú rekordokat figyelem és maximum az eladás mennyiségével csökkentem a fifo_bevet_vt db adatát (már ha van rajta annyi, mert ha nincs, akkor nulla lesz és nézem a következő bevét rekordot). Ha egy fifo_bevet_vt rekord mennyiség elfogy, akkor törlöm. Miután az eladásokat teljesen bejártam és elfogyasztottam a bevét rekordokat, a bevétes táblában csak azok a tételek maradnak, amelyek még nem lettek eladva a saját mennyiségével és árával és ebből már kiszámítható a FIFO átlagár.
A termék FIFO ára pedig egy egyszerű select-tel lekérhető
SELECT get_FIFO_ar(tkod) FROM cikk WHERE ...
Ezért mondom hogy ezt simán SQL-lel elég macerás megcsinálni.
A te esetedben bevét oldalra a 100-as kód a nyitókészlet, az mindenképpen kell, és kellenek hozzá 101-199 mozgások, eladás oldalra pedig mehetnek az eladások és igen, ha nincs olyan táblád, (pl. leltár), ami megmondja, hogy január elsején (vagy tetszőleges dátumra) adott termékre mennyi volt a FIFO ár akkor minden esetben az elejétől kell venni mindent. Ezért jó ha leltározás funkció van a programodban, mert akkor elég csak onnan nézni a bizonylatokat (leltár [mennyiség, ár] és leltár utáni bevétek, eladások) feltételezve azt, hogy a leltárban FIFO árral vannak letárolva az adatok.
-
baracsi
tag
De mi a kérdés, tehát akkor a FIFO működését érted, de nem tudod lemodellezni a működését? Szerintem csak simán nem fogod tudni SQL-lel megoldani, én legalábbis MySQL függvénnyel oldottam meg, mert a beszerzéseket szépen el kell fogyasztgatnod az eladások alapján, és ami marad készlet és beszerzési ár, abból kell meghatározni a FIFO-átlagárat.
-
baracsi
tag
válasz
Petium001
#4365
üzenetére
Szia,
lehet kívülről, de csak akkor ha ez nincs benne a my.cnf-ben, vagy ki van kommentezve:
bind-address=127.0.0.1, ugyanis ha benne van, akkor csak localhost-on lehet csatlakozni (web-szervereknél van értelme, nem lehet kívülről támadni a MySQL-t)Tölts le egy MySQL GUI Tools-t, ez egy régi program, annak a MySQL Administrator programjával próbálj meg csatlakozni a linux által kapott IP-címre, szerencséd van, akkor a port-ot nem változtatták
ha az sem megy és nem tudod szerkeszteni a my.cnf-et, akkor aki írta, az a sírba vitt magával minden info-t, ami szükséges
ha sikerült, akkor az alábbi módon tudod javítani
1. bal oldal válaszd ki a
boressémát a Schemata rész alatt
2. táblán jobb klikk Maintenance \ Repair table, egyébként piros lesz ez a tábla a listában, mert sérült szegény
-
baracsi
tag
válasz
Petium001
#4363
üzenetére
Ennek semmi köze a szoftverhez, SHIFT meg recovery menü feltételezem a szofftver szolgáltatása, azt biztos, hogy nem a MySQL-é. A cél a MySQL-ben található sérült tábla rendbetétele.
1. keresd meg a linux-on a MySQL konfig fájlját, ez alapból
/etc/mysql/my.cnf, de lehet, hogy azon a gépen máshol van, ezt neked kell kideríteni
2. szerkeszd a konfig-fájlt és keresd meg a [mysqld] részt és alá írd be askip-grant-tablesszöveget
3. indítsd újra a MySQL szolgáltatást:/etc/init.d mysql restart
4. csatlakozz a MySQL-hez:mysql -u root -püss egy ENTER-t, jelszónak írjál be valamit, mindegy, hogy mit, mert askip-grant-tablesmiatt nem fog foglalkozni a jelszó ellenőrzésével
5. írd be eztuse boresmajd üss egy ENTER-t, a hibaüzenet aboressématetelnevű táblájára vonatkozik
6. írd be eztREPAIR TABLE tetel;majd üss egy ENTER-tHa működik a szoftver ezt követően, akkor szedd ki a
skip-grant-tablesrészt és ismét indítsd újra a MySQL szolgáltatást -
baracsi
tag
válasz
Petium001
#4359
üzenetére
el tudod indítani a MySQL-t úgy, hogy nem fog kérni autorizációs adatokat, illetve kér, de bármit megadhatsz
skip-grant-tablesbeállításnak nézz utána, ezt lehet parancssorosan is megadni, de be tudod állítani az /etc/mysql/my.cnf részben is (írtad, hogy linux-ról van szó, de lehet, hogy ott máshol van a config fájl), utána újra kell indítani a mysql service-t, ezt követően bármilyen login névvel / jelszóval be tudsz lépni, rá tudod engedni arepair table-t, után szerintem érdemes kivenni a beállítást, hogy ne tudja más hack-elni[mysqld]
skip-grant-tables
port=3306 -
baracsi
tag
Semmi extra, készít egy tömeges SQL-t,amit neked kell lefuttatni, sok ALTER TABLE [séma.táblanév] FORCE; sort fogsz kapni. Azon táblákra, amelyekben van time, timestamp, vagy datetime típusú mező. InnoDB-s perzisztens táblákra vonatkozik, nyugodtan le lehet futtatni a query-t, max nem kapsz semmit vissza.
Új hozzászólás Aktív témák
Hirdetés
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest