bubu

nesapratu? Kas ko atgriezīs? insert'am nekas nav jāatgriež.

Neiet runa par IE vispārīgi, bet gan IE 5-to versiju.

Un ko jaunās rindas atrisinās, tāpat jāskaita būs.. Bet galā piemest jau tiešām nav problēmu (pilnīgi tas pats jau ar to SET x=y veidu notiek - galā jāpiemet, pa vidu jau nebīda).

Tu laikam īpaši neattapīgs pagadījies.. viss_kedaas jau tev priekšā pateica, kas tur trūkst.

Pirmais ir MySQL specific.

popup ir ie specific, bet uz citiem browseriem, kur nav popup, tur tie select bokši normāli ievēro z-index. Bet vai tad tiešām ir tik aktuāli atbalstīt IE <6 browserus?

Tā jau domāju..

Nevis lieks, bet negaidīts (unexpected). Varianti divi - vai nu kā flasherr teica, lieks {, vai nu par ātru uzlikts, jo kautkas pirms tā aizmirsts uzlikt.

Autors varētu mūs apgaismot un atklāt, kādiem nolūkiem bija paredzēts dabūt to maģisko nākamo skaitli, ne?

Parse error nozīmē sintaktisku kļūdu, t.i. tu php interpretatoram padevi skriptu, kas neatbilst php valodas konstrukcijām. Nu, piemēram, kautvai ierakstot php failā kauto šādu, lai tas tiktu izpildīts: {(*@)#*$}@}!P#L noteikti būs parse error, jo php vienkārši nesapratīs, ko tu ar to prasi.

A kas tos meilus klasificē kā spamu? Saņēmēja mail-serveris, vai provaidera SMTP serveris

SkaKri, a moš nevajag bezjēgā quotēt? Citādi topiks izstiepjās kilometriem garš!

ļoti izsmeļošs problēmas apraksts... Būtu pats atvēris savu lapu un izlasījis kļūdas aprakstu. Manuprāt ļoti skaidri pateikts, kas 5-tajā rindiņā par kļūdu.

Tā var protams, tas strādās, bet tā nav labi - jo no mysql tiek izvilkta visa tabula (nu dati), bet saglabāti tikai 10 ieraksti. Lieka datu pārraidīšana no mysql->php. Vajag uz LIMIT keywordu paskatīties mysql dokumentācijā (kurš nodrošina tikai fiksētu ierakstu skaita atgriešanu) un palasīt vecākus foruma ierakstus: http://php.lv/f/index.php?showtopic=1396&hl= http://php.lv/f/index.php?showtopic=1396&hl= http://php.lv/f/index.php?showtopic=765&hl= http://php.lv/f/index.php?showtopic=1205 http://php.lv/f/index.php?showtopic=2062

Rindu savākšana ir nekorekta. Ja kverijs neatgriezīs nekādas rindas, tad pirmais $row=mysql_fetch_assoc($result); izsaukums iekš $row ieliks false. Un tad do ciklā $row['name'] nebūs definēts! Pareizi būtu lietot while ciklu, jo tad jau tā false pārbaude notiks pie paša sākuma un cikls vairs neizpildīsies. while ($row = mysql_fetch_assoc($result)) { echo $row['...']; } mysql_free_result($result);

Protams, ka ir.

Palīdzēt tev palīdzēs jebkurš, bet galvenais pašama arī kautko domāt un taisīt. Vai arī noformulēt savu jautājumu citā veidā - kurš man uztaisīs to un to. A ja gribi lai palīdz, tad uzdod konkrētus jautājumus, nevis - man vajag to un to, kā lai uztaisa? Prasi konkrētas lietas!

Nu atšķirība aloritma ziņā ir nekāda. Pie tam tavā kodā nedara to, ko prasīja cilvēks - neiekļauj citu php skriptu.

Robi, kāda jēga atkārtoties?

optionu daudzumam nevajadzētu būt problēmai. Esmu darbojies ar sarakstu, kurā ir virs 500 ierakstu. Un tas formāts nesaucās ascii, bet gan html entītes. :) Ascii ir cp1257 formāts.

Nesapratu kas ko nespēj sagremot? Kur tur mysql vispār kāds sakars? btw, iesaku pāriet uz UTF-8.

Viņam vajag tikai šodienas ierakstus, nevis šīs dienas jebkura gada ierakstsus!

haha, un tue neesi iedomājies, ka DAYOFYEAR() arī pagāšgada 19. augustam, ir tāda pati kā šīgada 19.augustam?

Tāpēc ka tavs jautājums ir galīgi nesaprotams, tāpēc arī nebija aktivitātes. Cik nu es sapratu, tad Kristabs jau tev atbildēja pareizo atbildi, kā dabūt refereeru. A JS kods te pričom, man nav ne mazākas saprašanas..

$visikopaa = $_GET['nezkas']; $vars = explode(' ', $visikopaa); // tagad $vars[0] == 'jaanis' // $vars[1] == 'iet' // ... Atstarpes URLī btw ir ļoti ieteicams nelietot, bet tā vietā likt %20. php galā tās automātiski pārkonvertēsies uz atstarpju simboliem.