mySQL query ciklusban
Sziasztok!
Eléggé érthetetlen problémával állok szemben és már minden kombinációt kipróbáltam, mégsem jövök rá a megoldásra.
Adott az alábbi nagyon egyszerű kód:A problémám az, hogy bár a ciklus rendesen lefut (a kimenetnél ez látszik is), azonban a táblába folyamatosan több rekordot tesz be a PHP, mint amennyit kellene. Gyakran van az, hogy elmegy szépen százig, aztán újrakezdik az iterációt 1-től és még bepakol 50-60 rekordot. Kipróbáltam OOP nélkül, simán mySQL-lel, mindig hibázik. Érthetetlen.
A tábla egy sima kétmezős tábla, egyikben auto_increment, primary key, a másik pedig int típusú.
Van tippetek?
Köszi.
(Tudom, hogy meg lehet csinálni ezt prepared statementtel és multiquery-vel is, de szerintem így is működnie kellene.)
■ Eléggé érthetetlen problémával állok szemben és már minden kombinációt kipróbáltam, mégsem jövök rá a megoldásra.
Adott az alábbi nagyon egyszerű kód:
$connect = new Mysqli('localhost','root','****','test');
for ($x = 0; $x <= 100; $x++) {
$q = "INSERT INTO users VALUES('','".$x."')";
$connect->query($q);
echo $x.'. rekord beszúrva<br />';
}
A tábla egy sima kétmezős tábla, egyikben auto_increment, primary key, a másik pedig int típusú.
Van tippetek?
Köszi.
(Tudom, hogy meg lehet csinálni ezt prepared statementtel és multiquery-vel is, de szerintem így is működnie kellene.)
Nem indokolt
Más: az insert parancsnak lehet több rekordot is megadni, nem kell külön queryben beküldened.
Folyamatosan ürítem
Olyan, mintha a cikluson belül elvesztené a fonalat, hogy éppen hol is jár. Próbáltam mysqli_free-t alkalmazni, de nem segített.
Csak tippelek:
- Nevezd meg előbb (a VALUES előtt) a mezőket, aztán adj értékeket, így biztos, hogy abba a mezőbe kerül, amelyikbe szánod. (Bár elvileg ha nem adod meg, akkor a táblában levő elhelyezkedési sorrendben kellene mennie.)
Nem próbáltam, nekem még ilyen esetem nem volt...
Hmm...
Megpróbáltam másik adatbázis másik tábláján, az eredmény ugyanaz.
Akkor még egy,
- Én nem ismerem az adatbázismotort sem és a php értelmezőt sem eléggé ahhoz, hogy megítéljem, de arra (is) tippelnék, hogy a foreach ciklus "lehagyja" az adatbázismotort és a zűr valahol a folyamatok "naplózásánál" van. Pl. dolgozik az első INSERT, mire végére ér, a php az 5.-nél tart. Ezt rögtön átveszi MySql, de a közöttük lévők várakoznak. ... És ott a hiba, hogy a végén nem tudja, mennyi amit már megcsinált, hova kell visszamenni. Ebben bezavarhat neki az autoincrement cucc is, amiatt nem volna szabad 1. után 5.-et kezelnie, vagy akkor tudnia kell, hogy az az 5.
Igazából nem tudom, én még a BDE-vel voltam jobb ismeretségben.
Szerk.: lehet, hogy nagy hülyeséget írtam ide, ha igen: remélem valaki felhomályosít.
nem aszinkron
Köszi!
PHP
Ezt gondoltam
mod_rewrite?
szokott olyan lenni, hogy ugye bejön az index.php, egy get paraméterben a lekért path-tel ha a file nem létezik...
a chorme pl. mindig két lekérdezést indít, a másikon lekéri a favicon.ico-t ugyanabból a mappából mint az url (és ha ilyen nincs, a mod_rewrite lefuttatja az index.php-t), lehet hogy ez zavar be?
(bár ekkor 2x100 db sor lenne, nem 1x100 + 50-60 db, bár attól függ hol a truncate)
csak tipp, ötlet, lehet hülyeséget mondok :)
Nincs mod_rewrite
Egyébként az a hihetetlen, hogy amennyiben csak egy iterációt csinálok, akkor is két rekordot szúr be a táblába!
Ha van valakinek ideje, akkor esetleg megnézhetné, hogy nála is ugyanezt csinálja-e.
Kivettem az auto_increment mezőt, akkor is rossz.
Kipróbáltam, és nálam úgy
A MySQL-ben valahol van egy bináris vagy query log, azt, ha lehet, nézd meg szerintem, hogy milyen lekérdezések futnak le egymásután.
SQL
Hol találom ezt a logfile-t?
MySQL Server Logs
commit?
Illetve B tipp: nem kísérleteztél triggerekkel és felejtettél ott egyet?
Egyik sem
Most alakítottam a táblán, egyik mezőbe mennek az X. értékek, másikba egy timestamp, az eredmény pedig valami ilyesmi 10 iteráció után:
1 1328434599
2 1328434599
3 1328434599
4 1328434599
5 1328434599
6 1328434599
7 1328434599
8 1328434599
9 1328434599
10 1328434599
1 1328434600
2 1328434600
3 1328434600
4 1328434600
5 1328434600
6 1328434600
7 1328434600
8 1328434600
9 1328434600
10 1328434600
--------------------
20 rows in set (0.00 sec)
Rejtély vagy rejtély?:)
timestamp másodperc alapú
elv ez úgy néz ki mintha 2x futna a php-d, inzertálj a legelejen és a végén is vmit h biztos legyen.
interaktív PHP?
Ha utóbbi, akkor próbáld ki az interaktív verziót is, kihagyva az egészből az apace-t (vagy amilyen web szervert használsz)!
Érdekes fejlemény
Úgyhogy akkor valóban az lesz a gond, amit írtál: a mod_rewrite. A kérdés az, hogy ez miért van egyáltalán, mikor nem index.php a file neve, hanem teljesen más, ráadásul semmilyen paramétert nem kap a file, amiben a lekérdezés van.
Ahogy nézem, ez nem is igazán webszerver probléma lesz, mert az eredeti problémám is megoldódott azzal, hogy Safariban szúrom be a rekordokat. A kérdés az, hogy a Chrome-mal mit lehet kezdeni, hogy ne csináljon ilyet?
Úgy saccolom, ennek nem sok
Amennyire tudom, a chrome-ban van valami olyan funkció, ami gyorsítani próbálja az oldalak betöltődését azzal, hogy az oldalon lévő linkek tartalmát előre letölti. Inkább arra tippelnék, hogy ez a funkció kavar be neked, mert nincs a lapon tisztességes session management, viszont van mondjuk egy link önmagára.
Persze hangsúlyozom, ez csak tipp.
Annyi van a lapom, amit
errordocument esetleg?
Ha be van kapcsolva a
Másrészt az azért jól érzem,
Gondolom ez azért gyorsabb is, másrészt alapból jobb választásnak tűnik egyben odaadni a teljes adagot a mysql-nek, mint folyamatosan hívogatni (pl. a user leállítja a lekérést és akkor a maradék query - gondolom én - elveszik).
igen, de
egy gyors google ezt dobta: elv kliens (php) és szerver is állítja a max_allowed_packet változót, a default 16M.
http://dev.mysql.com/doc/refman/5.0/en/packet-too-large.html
16M