Új hozzászólás Aktív témák

• #5500 baracsi tag bambano #5498

  Új Válasz 2022-05-04 14:32:22 #5500

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  baracsi

  tag

  válasz bambano #5498 üzenetére

  ja igen, a temp tábla a függvény futásának idejére létezik csak, lehet ez nem volt számodra érthető

• #5499 baracsi tag bambano #5498

  Új Válasz 2022-05-04 14:21:44 #5499

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  baracsi

  tag

  válasz bambano #5498 üzenetére

  igen, az egyikbe legyűjtőm a bevételezéseket, a másikba az eladásokat, pontosan mi a kérdésed?

• #5496 baracsi tag bambano #5495

  Új Válasz 2022-05-04 14:09:49 #5496

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  baracsi

  tag

  válasz bambano #5495 üzenetére

  mire gondolsz pontosan?

• #5493 baracsi tag pch #5492

  Új Válasz 2022-05-04 08:16:52 #5493

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  baracsi

  tag

  válasz pch #5492 üzenetére

  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.

• #5491 baracsi tag pch #5490

  Új Válasz 2022-05-03 19:28:54 #5491

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  baracsi

  tag

  válasz pch #5490 üzenetére

  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.

• #4984 baracsi tag Ablakos #4983

  Új Válasz 2021-05-26 16:14:47 #4984

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  baracsi

  tag

  válasz Ablakos #4983 üzenetére

  nem szükségesek a mentéshez ezek a sémák

• #4389 baracsi tag Petium001 #4388

  Új Válasz 2019-12-13 08:08:32 #4389

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  baracsi

  tag

  válasz Petium001 #4388 üzenetére

  Ebben én nem fogok tudni segíteni, mert ez már linux-szal kapcsolatos, más topic-ban talán tudnak ez ügyben segíteni.

  Átnevezni sem engedi? Mert akkor menthetnéd my.cnf-ként, csak egy ötlet.

• #4387 baracsi tag Petium001 #4384

  Új Válasz 2019-12-11 08:45:28 #4387

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  baracsi

  tag

  válasz Petium001 #4384 üzenetére

  Nem tudom menteni a my.cnf-et mert azt írja, csak olvasható....
  root-ként sem szerkeszthető?

  /etc/init.d mysql restart ezt hol
  parancssorban, természetesen root-ként

• #4378 baracsi tag kw3v865 #4377

  Új Válasz 2019-12-05 13:46:08 #4378

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  baracsi

  tag

  válasz kw3v865 #4377 üzenetére

  nem vágom a PostgreSQL-t, de Oracle-ben a dinamikus SQL-eket EXECUTE IMMEDIATE-tel kellett futtatni

• #4375 baracsi tag Male #4374

  Új Válasz 2019-12-04 12:37:34 #4375

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  baracsi

  tag

  válasz Male #4374 üzenetére

  köszi, mert linux fájl-rendszer dologban én spec nem tudok segíteni

• #4372 baracsi tag Petium001 #4368

  Új Válasz 2019-12-02 08:19:25 #4372

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  baracsi

  tag

  válasz Petium001 #4368 üzenetére

  Szia,

  ha ezt a vinyót berakod egy másik gépbe, akkor fájl szinten lehet látni a dolgokat? Mert akkor meg lehetne szerkeszteni a my.cnf-t utána visszatenni az eredeti gépbe

• #4366 baracsi tag Petium001 #4365

  Új Válasz 2019-11-23 16:49:57 #4366

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  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 bores sé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

  

• #4364 baracsi tag Petium001 #4363

  Új Válasz 2019-11-22 08:10:13 #4364

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  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 a skip-grant-tables szö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 a skip-grant-tables miatt nem fog foglalkozni a jelszó ellenőrzésével
  5. írd be ezt use bores majd üss egy ENTER-t, a hibaüzenet a bores séma tetel nevű táblájára vonatkozik
  6. írd be ezt REPAIR TABLE tetel; majd üss egy ENTER-t

  Ha működik a szoftver ezt követően, akkor szedd ki a skip-grant-tables részt és ismét indítsd újra a MySQL szolgáltatást

• #4362 baracsi tag Petium001 #4359

  Új Válasz 2019-11-21 09:01:39 #4362

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  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-tables beá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 a repair 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

• #4357 baracsi tag Male #4356

  Új Válasz 2019-11-20 08:50:11 #4357

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  baracsi

  tag

  válasz Male #4356 üzenetére

  Én nem írtam arról, hogy melyik gépen van az adatbázis, a kérdésem az volt: MySQL van alatta? Azaz MySQL-hez csatlakozik?

• #4355 baracsi tag Petium001 #4353

  Új Válasz 2019-11-20 08:40:11 #4355

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  baracsi

  tag

  válasz Petium001 #4353 üzenetére

  MySQL van alatta (a hibaüzenet alapján annak tűnik)? REPAIR TABLE-t kell ráengedni.

• #4189 baracsi tag kem #4188

  Új Válasz 2019-07-24 11:37:30 #4189

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  baracsi

  tag

  válasz kem #4188 üzenetére

  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