Zdarte vsici, kdyz zadam tento prikaz na databzi, tak mi to hodi chybu. Na localhostu to funguje v pohode. Dekuji za rady, pomoc!
SELECT id FROM firma WHERE id IN
(SELECT DISTINCT id_firma FROM firma_pobocky WHERE
MATCH(nazev) AGAINST('super' IN BOOLEAN MODE)
ORDER BY (MATCH(nazev) AGAINST('super' IN BOOLEAN MODE)) DESC)
http://dev.mysql.com/doc/refman/5.0/en/gone-away.html
No, dobrá, strýčka gůgla používat umím též, aloe v tom, co jsi našel odpověď není. Podle mě se jedná o bug, protože když zkusim tohle, tak to funguje...
SELECT id FROM firma WHERE id IN
(SELECT id_firma FROM
(SELECT DISTINCT id_firma, MATCH(nazev) AGAINST('super' IN BOOLEAN MODE) AS relevance FROM firma_pobocky WHERE
MATCH(nazev) AGAINST('super' IN BOOLEAN MODE)
ORDER BY relevance DESC) AS pobocky)
Možna mi tam chybi zavorky. Dvě různé verze MySQL si s prvním dotazem poradi/neporadi a s tim druhym si poradí obě.
V jistých situací jde o bug. Co jsem prostudoval spolu se strejdou, tak problém může dělat podmínka.
Jde o to, jestli není pro server velká zátěž použít fulltext. Zkuste když tak použít LIKE a zjistit, zda není lepší nebo spolehlivý.
http://www.dpriver.com/pp/sqlformat.htm
SQL dotaz1 mi hlasi chybu
AGAINST(3,14) expected token:; * + - / = > AND OR NOT IN IS LIKE ) HAVING GROUP ORDER UNION MINUS INTERSECT
SQL dotaz2 mi hlasi chybu
((3,48) expected token:; . ) , WHERE HAVING FROM GROUP INTO ORDER UNION MINUS INTERSECT FOR WITH LOCK
Odpověď tam je, jen není na první pohled zřejmá. Základ problému je ten, že SQL server nestihne odpovědět v daném časovém limitu. Důvodů k tomu může být vícero:
asi nejčastěji se to stává když zrovna server zpracovává víc dotazů zaráz, potom to může být i nějaký bug. Pokud jde o bug, tak se to asi nikde nedočeteš (aspoň já jsem tuhle chybu ve spojení s bugem MySQL serveru nikde nenašel)
Zase je otázka, nastavený timeout mám na localhostu stejně, jako na servru a verze SQL je v obou případech 5 a liší se v dalším označení... Holt, bug to bude a je mi to v celku jedno. Vyřešit jsem to vyřešil a s rukou na srdce. Kolikrát hlášená chyba programu není pravdivá, protože se na to programátor "vykašlal" a prostě to tam spadne, stejně jako s vyjímkami... Navíc, SQL není komerční (prosím, netahejte mě za slovo), tak si to též může dovolit...
pro petu: nejak jsem nepochopil, co si tím chtěl říci, možná jsem příliš opilý, ale co to má s tím dělat formátování? tu chybu ti to hází, protože nemáš správně zadaný výstupní formát... ;)
bedna: Tak můžete mít stejnou verzi, stejné kódy, stejná data, stejné nastavení, ale zapomněl jste na jednu zásadní věc - jiné železo a jiné provozní podmínky. U Vás doma na localhostu nejste bombardován tisíci dotazy za sekundu.
A mysql server zde na WZ je pověstný nepřetržitým přetíženým. Prostě dělá co může a musí často odmítnout nějaký ten dotaz. U složených dotazů je toto velké riziko. Stačí, aby odmítl zpracovat vnitřní dotaz a celý dotaz selže. Toto je právě ta chyba "Lost connection".
Kdysi jsem tento problém řešil. Na chybu "Lost connection" skript reagoval nejprve čekáním 1s, při dalším neúspěchu 2s a teprve pak to vzdal. Úspěšnost se rapidně zvýšila.
Nyní MySQL na WZ nepoužívám, takže netuším, zda by to dnes pomohlo nebo by to jen ještě víc přetížilo server.
bedna (sklopimeto.wz.cz)
1 - zkus do toho vlozit nejaky obycejny SQL, formatovani projde.
2 - pak zkus tento, rekni, co jsi tam navolil a neprojde. Ja tam navolil MySQL
Proc to neprojde? Protoze tam je MOZNA chyba. Ten program krome formatovani dela take validaci sql dotazu. Coz se hnedtak nevidi. A uz mi parkrat vyresil problem treba s Oracle, kde chybove hlasky v PHP stoji za houbec.
Mozna chyba, ja ten program nezkoumal a tak slozite dotazy nedelam, takze nemam proverene pro tuto kombinaci. Na dotazy tu mame cloveka. Jeho posledni dilko melo asi 10k jen samotny text dotazu :)
Zvolim databazi MySQL, Output SQL(text)... Projdou oba dva... A ze by se jednalo o slozity dotaz v porovnani s 10 Kb textem?
A mohu mit jeste otazku k tomu jeho psolednimu dilku? 10Jb je jen samotny text dotazu a zbytek dotazu je jako co?
tak ja to nechal v default na tusim SQL:font a MySQL a pise to chyby. Cili muzu predpokladat, ze tam jsou realne chyby, kdyz se mu to nepodarilo parsovat. Samozrejme je to jen predpoklad, uz jsem rikal, ze tohle je konstrukce, kterou jsem jeste nepouzil a moc o ni nevim.
Ten jeho SQL je kolem 10.000 znaku, vcetne mezer novych radku a tak. V podstate je to jednoduchy dotaz slozeny ze 4 a propojeny na 6 tabulek, vytahovalo se asi 15 promennych (proto to ma tolik)
SELECT ... LEFT JOIN ...
UNION
SELECT ... LEFT JOIN ...
UNION
SELECT ... LEFT JOIN ...
UNION
SELECT ... LEFT JOIN ...
Ja bych to bliz nerozebiral, neresi to tvuj problem a navic nejsem ten, co ten dotaz zplacal :)