MYSQL adat frissítési hiba PHP-n keresztül

MYSQL adat frissítési hiba PHP-n keresztül
2012-03-19T18:54:20+01:00
2012-03-20T08:25:13+01:00
2022-10-25T11:45:36+02:00
  • Rossz a címzett, de egyetértek.

    sorry
    Mutasd a teljes hozzászólást!
  • Az lesz, próbálkozni fogok mostmár mindennel, ami eszembe jut, csak azért gondoltam, hogy feldobom ide a témát, hogy hátha valaki tud még ötletet adni, hogy mivel lehetne még próbálkozni. Lentebb említem, hogy egy friss fájlról van szó, lehet elkezdem újragépelni az egészet 0-ról, hátha benne van valami nem látható piszok, ami gátolja a dolgot vagy nem tudom... túl sok ötletem egyelőre nincs :D
    Mutasd a teljes hozzászólást!
  • Én ezt úgy értelmezem, hogy a mysql parancssorban _sem_ írja át az otthon-t. Utána azonban a phpmyadminra azt írja igen. A két dolog mintha ütné egymást.


    Úgy értelmezd, hogy mind2 helyen hiba nélkül lefut a parancs, de phpmyadmin parancssorban lefuttatva átírja az értéket 1-re, míg php kódban lefutva nem írja át sem 1-re, sem 2-re sem 3-ra csak 4-től felfele.

    Egyébként ezt az értéket összesen 2 php fájlból próbálom módosítani. az egyik fájl nagyon friss, a másikkal viszont eddig soha nem volt gond és most sincs, abban gyönyörűen megcsinálja ugyan ezt a módosítást. Illetve nem tök ugyan ez a módosítás, hanem olyan módosítás, amiben ezt az értéket is meg akarom változtatni.
    Mutasd a teljes hozzászólást!
  • Rossz a címzett, de egyetértek.
    Mutasd a teljes hozzászólást!
  • mi csak akkor tudunk wsegíteni ha megfelelő inputokat, tesztelési riportokat,
    esetleg teszt linket mutatsz.

    táblastruktúra, PHP kód amivel kezeled a táblát.

    ami eddig nekem ilyesmi problémát okozott:
    register globals , merevlemez tönkrement, írásvédetté vált egy fájl ami adott táblát kezelte, programozói baki, egy fájl szinkronizációs programot bekapcsolva hagytam, így nem a megfelelő verziót frissítette, így nem változott a programom, annyira sokszor írtam egy táblába egy tömeges módosítóval, hogy a szolgáltató lekorlátozta a MYSQL usert, támadási kísérletnek titulálta a programom!

    próbából hozz létre egy otthon2 INT mezőt, és azon próbálkozz. Futtass MYSQL tábla diagnosztikát, mi van ha valami oknál fogva egyedi kulcsot tettél az otthon mezőre...
    Mutasd a teljes hozzászólást!
  • Nincs gond a paranccsal, mondom mysql parancssorból lefut, mint a katonatiszt és a kódban is lefut mert mindent átír szépen pontosan az "otthon" kivételével.


    Én ezt úgy értelmezem, hogy a mysql parancssorban _sem_ írja át az otthon-t. Utána azonban a phpmyadminra azt írja igen. A két dolog mintha ütné egymást.

    Sőt, ugye a phpmyadmin maga is php-s, vagyis ha ott menne, akkor mennie kellene másik php-ból is.

    Tehát akkor egy kérdés: bárhonnan futtatva megváltoztatható az otthon értéke 2-re?
    Mutasd a teljes hozzászólást!
  • Igen, nagy valószínűséggel a kódban lesz a hiba, másra én se tudok már gondolni, csak ez zavar be, hogy 2-t és 3-at se enged beírni, pedig azokkal ennél a mezőnél nem is dolgozok sehol, ha pedig a 4-et és az fölöttieket engedi, akkor a későbbi nem észrevett visszaírás lehetőségét is kizárnám, mert akkor azokat is visszaírná... legalábbis az én logikám szerint de már nem bízom magamban se :D Úgyhogy egyelőre ha megvakulok se találom, hogy mi a fene lehet...
    Mutasd a teljes hozzászólást!
  • mindig fölé kell lőni a mezőtípussal hogy tutira beleférjen, utána lehet beállítani a szükségletekhez igazodva


    mysql-nél az egész szám mezőknél a zárójelben megadott hossz csak a kijelzésnél játszik szerepet, már ha a zerofill tulajdonsága a mezőnek true, nincs befolyása arra, hogy milyen adat tárolható a mezőben.

    Egyébként ha phpmyadmin-ból megy a frissítés, akkor trigger-ről nem nagyon lehet szó és a mysql hiba is kizárható. 99,99% hogy a php kódban kell keresni a hiba okát.
    Mutasd a teljes hozzászólást!
  • Triggerrel pont ilyet lehet elérni. Hiába adsz meg egy értéket, a trigger felülírhatja a régi értékével. Akár úgy, hogy a 2-3-4-et nem engedi, de a 20-at igen.

    És ha a tesód ismeri, akkor ő szivat téged
    Mutasd a teljes hozzászólást!
  • Na, valamit az előbb elnéztem, mégsem megy így se. Akkor a kérdés még mindig nyitott, hogy tud-e valaki ilyesmiről és hogy mi lehet az oka.
    Mutasd a teljes hozzászólást!
  • Hát ez hihetetlen... 11 hossz/értékes INT típussal megy

    mindig fölé kell lőni a mezőtípussal hogy tutira beleférjen, utána lehet beállítani a szükségletekhez igazodva.

    mysql_Error() -nak nincs köze a triggerekhez. Ennek a PHP függvénynek a hibakezeléshez van köze.

    És phpmyadmin parancssorból miért ment?

    nem tudom.
    Mutasd a teljes hozzászólást!
  • Egyébként eléggé az elején vagyok a php rejtelmeinek, ezért sok minden fogalom még új nekem, pl ez a trigger dolog is, és ha a mysql_error() az, akkor használok triggert... minden parancs mögött ott van.

    Mutasd a teljes hozzászólást!
  • Hát ez hihetetlen... 11 hossz/értékes INT típussal megy. Na ezt majd valakitől megkérdezem, hogy akkor az most hogy van, mert amióta ezzel elkezdtem foglalkozni, ezzel még soha nem volt gondom, hogy 1 hosszú TINYINT típust használtam. Egyébként a vicces az, hogy alapértelmezett 10 hosszú INT típussal is ki lett próbálva és azzal se ment. Akkor ez most mi alapján "válogat"?

    És phpmyadmin parancssorból miért ment? Elég sok itt a miért attól függetlenül, hogy a 11 hosszú INT típussal működik.

    De jár a megoldásért a pont, köszönöm!
    Mutasd a teljes hozzászólást!
  • adj neki INT(11) típust , és akkor nézd meg jó-e.
    Aztán ha úgy beírja csökkentsd a megfelelő típusúra a mezőt.

    ugyanis TINYINT(1) igencsak szűk keresztmetszet ha 1-5 ig akarsz tárolni benne.

    mysql_error() -t azért használhatnád legalább.
    '' -t pedig szöveges mezők köré szoktak csak tenni.
    Mutasd a teljes hozzászólást!
  • Nincs, de tesóm programozó, ezt már ő is felvetette, úgyhogy utánajárok, hátha okosabb leszek tőle.
    Mutasd a teljes hozzászólást!
  • Gondolom triggered sincs.
    Mutasd a teljes hozzászólást!
  • Nincs gond a paranccsal, mondom mysql parancssorból lefut, mint a katonatiszt és a kódban is lefut mert mindent átír szépen pontosan az "otthon" kivételével.


    mysql_query("UPDATE users SET penz_taskaban = '0', arany_taskaban = '0', otthon = '1', kocsma = '0', korhaz = '1', korhaz_kezd = '$unixtime', hazaerkezes = '$unixtime', fizikai_allapot = '0' WHERE user_id = '$dest_user_id'");
    Mutasd a teljes hozzászólást!
  • Gondoltam, hogy ez így ennyi infó mellett nem lesz megoldva, nem is ez volt a lényege a hozzászólásomnak, a kérdésem továbbra is az, hogy valaki találkozott-e már ilyesmivel.
    Mutasd a teljes hozzászólást!
  • Írd le az sql parancsot.
    Mutasd a teljes hozzászólást!
  • TINYINT 1 hosszal unsigned
    Mutasd a teljes hozzászólást!
  • Milyen típusú a mező?
    Mutasd a teljes hozzászólást!
  • Ez így túl kevés, kéne olyan kód és db struktúra, ami alapján a hiba reprodukálható. Konkrét mysql, php és oprendszeri verziók megjelölése mellett. Abban ugyanis biztos vagyok, hogy ha van is ilyen hiba a mysql-ben vagy a php-ban, az csak valamilyen spéci felállás mellett lehetséges, mert azért ezt egy tesztnek el kéne kapnia!
    Mutasd a teljes hozzászólást!
  • Napot!

    Van egy konkrét problémám, és egyszerűen képtelen vagyok rájönni a hibára. Elég furcsa a dolog, kíváncsi vagyok valaki találkozott-e már ilyesmivel.

    Tehát... Van egy PHP scriptem, változóba beteszem a MYSQL parancsot és végrehajtatom. A parancsnak kb 4-5 mezőt kéne módosítani, ebből 1 kivételével mindet szépen meg is csinálja. Amit nem tud módosítani, az egy egyszerű 0-ról 1-re történő átírás. Végignéztem már kb 20x az egész kódot karakterről karakterre, bemásoltam sql parancssorba, onnan tökéletesen működik, tehát maga a parancssor jó. Végignéztem már vagy 8x az egész utána következő részt, hátha valami utána vissza akarja írni, de nincs ilyen. Ezt még idáig valahogy meg is érteném, gondolom valamit elqrtam a kódban, ha még 13x átnézem biztos meglesz. VISZONT: nem engedi átírni ugye 1-re a 0-át... nem engedi átírni 2-re se, 3-ra se. Viszont 4-től felfele igen (nem próbáltam mindent, a 4-et, 5-öt, 20-at beírta) Nem is igazán értem azért se ezt az egészet, mert pl. 2-vel és 3-mal gyakorlatilag önmagában nem is dolgozom (itt ugye az 1=igen, 0=nem) csak igaz-hamis állapotot jelölök vele. Szóval ha valaki tud valami hasonló anomáliáról és esetleg tud rá megoldást, azt megköszönném. Igazából annyira nem nagy a baj, mert végig úgy dolgoztam, hogy úgy ellenőrzöm ezt az értéket, hogy nagyobb-e 0-nál, tehát ennél az egy résznél nem gáz, ha mondjuk 5-re módosítom 1 helyett. Egyszerűen csak az agyamra megy, hogy miért nem enged 4-nél alacsonyabb értékre módosítani.
    Mutasd a teljes hozzászólást!
Tetszett amit olvastál? Szeretnél a jövőben is értesülni a hasonló érdekességekről?
abcd