andrisp

Nezinu vai pareizi sapratu, bet $_SERVER['QUERY_STRING'];

Ievieto kā parasti ievieto. Tikai norādi tam iframe id. Un iekš tā JS arī izmaini uz pareizo id.

Nu parādi, ko tu esi tur sastiķējis.

Laukiem pēc kuriem kārtosi, vajag kolāciju pareizu uzlikt. http://dev.mysql.com/doc/refman/5.0/en/charset-column.html PS. Vispār vajadzēja veidot jaunu topiku nevis celt augšā pusgadu vecu.

pamēģini šādu: echo "lala"asda"; un šādu kodu: echo "lala\"asda"; Kurš strādā un kurš nestrādā ?

KillerBean, autors skaidri un gaiši pateica, ka sīkāka informācija runājot privāti e-pastā.

HEREDOC syntakse.

Tāpēc, ka tu ar echo ".."; mēģini izdrukāt stringu, kas pats satur ". Vienkāršākais veids izlabot šo ir eskeipojot visus iekšējos ".

zaadjis, uz topika datumu paskatījies ? Un vispār, kāpēc tik dīvains piemērs ?

Nu, protams, var jau visādi. :)

Delfins, tā īsti arī nav. Tādejādi es varētu nodalīt, piemēram, obligātos laukos, kas obligāti ir visiem produktiem definēti (liekot tos produktu tabulā), no opcionālajiem/specifiskajiem elementiem, kas tiek realizēti ar papildus tabulas palīdzību. (Godīgi sakot es nezinu kā īsti autoram viss ir realizēts, jo to #9 mistrojumu nesapratu. No offence, protams.)

Es jau neteicu, ka prove nav raksturojošs. Es tikai saku, ka ja elements attieksies uz visiem produktiem un tam var būt tikai viena vērtība (kā piemēram zeltlietu katalogā, kur visiem produktiem ir prove), tad kāpēc gan to neglabāt galvenajā tabulā ?

Delfins, nu skaidrs kā tu to domāji, bet tad gan drīzāk tas ir nevis "raksturojošs elements", bet gan elements, kas var neattiekties uz visiem produktiem. Cena un cita finansiālā informācija jau arī ir raksturojošs elements. Tāpat arī, piemēram, ja man ir zeltlietu veikals, tad būtu tikai normāli, ja galvenajā tabulā būtu papilduslauks "prove". Enīvei, tas viss ir atkarīgs no situācijas.

Es pieņēmu, ka autoram vajadzēs tikai par vienu kvīti datus (tipa vēl WHERE id = klāt)

Vebers, ja es pareizi sapratu topika autoru, tad tev ORDER BY lauks nepareizs.

Delfins, ko nozīmē "raksturošs parametrs" ?

Iespējams, ka risinājums tāds pats kā tu esi izdomājis, bet vienkāršāku nezinu: SELECT k.*, b.* FROM kvitis k LEFT JOIN darbibas b ON ( k.id = b.kvits_id ) ORDER BY b.id DESC LIMIT 1

Neredzu jēgu glabāšanai atsevišķa tabulā, tikai liekas klapatas.

Neredzu īsti sakarība starp tevis uzdotajiem jautājumiem un darba interviju c4 kantorī. Tas ir - neredzu, kā mūsu atbildes uz tevis uzdotajiem jautājumiem varētu jebko ietekmēt tavā darba intervijā (vai arī darba gaitās).

Kam tev šo informāciju ? Bet nu labi, nav jau grūti: 1) Web izstrādes kompānijā ;) 2) Jā 3) - 4) Neatceros, droši vien kaut kas ļoti vienkāršs. Tipa varētu būt include() vienu html otrā. 5) Man liekas, ka nevienu. JS vēl diezgan labi pieprotu. 6) Hmm, no apt. 20. 7) Nē, kaut gan pašā sākumā "piespiedu kārtā" ar to arī nodarbojos :) 8) Reizēm (kaut gan nesēžu tikai pie pc) 9) Nē.

Mikijs, spams nav tikai reklāma ;) http://en.wikipedia.org/wiki/Forum_spam

mjā... vēl grudrāka izvēle...

Jā, tev taisnība.

Delfins, strādās, bet vai pareizi ?

Tā arī raksti, tikai nevis 2007-05-1 bet 2007-05-01. Arī uz MySQL tas pats attiecas.