Roze

Man gan skjiet ka tas viss jau ir uzrakstiits.. driizak atkal "jaapacelj" jautaajums un probleema par php.net tulkoshanu.

A par to (pierashanu) es neko nesaku.. tapeec quoteet manu postu nebija jeegas :) Jaa attieciigie masiivi tiek veidoti vienmeer. Taakaa ja ir veeleeshanaas un nepiecieshamiiba vinjus var izmantot neatkariigi no register_globals parametra. Piem ljoti parociigi ir izmantot $_SESSION lai nebuutu papildus jaalieto session_register() un tad jaaskataas kur kas tiek pieregjistreets un kur mainiigajam tiek pieksjirta/mainiita veertiiba iisti.. taapat arii $_COOKIE

Vispār jau RTFM, bet īsumā masivs['id'] ir asociatīvā indeksēšana --> masīvs, kuru var indeksēt, gan normālā veidā masivs[0], masivs[1] utml, gan asociatīvi (kā "asociācija" darbojas teksta birkas kā masivs['id'], masivs['kolonna'] utt). mysql_fetch_array - rezultātā dod masīvu, kuru nevar indeksēt asociatīvi, bet tikai veidā masivs[0], masivs[1] utt mysql_fetch_assoc - rezultātā dod masīvu, kuru var indeksēt asociatīvi, pie kam "asociācijas" atbilst atgriezto kolonnu nosaukumiem vaicājumā. Vispaar jau nedaudz nepareizi.. mysql_fetch_row() dod masiivu kuraa lauki ir indekseeti peec kaartas tieshi taadaa seciibaa kaadaa tie ir selectaa.. Ja piemeeram ir $result = mysql_fetch_row("SELECT lauks_a, lauks_b FROM tabula .. "); $row = mysql_fetch_row($result); tad $row buus $row[0] = 'lauka a veertiiba'; $row[1] = 'lauka b veertiiba'; Lai arii shii ir teoreetiski visaatraakaa no visaam datu fetchoshanas funkcijaam jaauzmanaas ja kaut kas tiek mainiits pashaa selectaa tad jaaskataas vai pie izvadiem ir tieshi taa kaa paredzeets.. mysql_fetch_assoc() atkal atgriezh masiivu kuraa elementu nosaukumi sakriit ar mysql tabulas lauku nosaukumiem (jebshu pashaa selectaa pieksjirtajiem) $row[lauks_a] = 'lauka a veertiiba'; $row[lauks_b] = 'lauka b veertiiba'; Priekshrociiba ir taada ka nav vairs svariiga lauku seciiba selectaa un vai vinji vispaar tiek noselecteeti.. Jaanjem veeraa ka shii funkcija ir saakot no php 4.0.3 versijas (lai gan arii maz ticams ka buus kaut kur vecaaka) pasham ir naacies saskarties ar to ka uz servera veelaizvien staav 4.0.1 un naacaas norepleisot ieprieksh uzrakstiitajaa kodaa (uz citas vides rakstiitu) mysql_fetch_array() ir abu ieprieksheejo funkciju apvienojums un gala rezultaataa $row masiivs buus $row[0] = 'lauka a veertiiba'; $row[lauks_a] = 'lauka a veertiiba'; $row[1] = 'lauka b veertiiba'; $row[lauks_b] = 'lauka b veertiiba'; t.i. gan asociatiivais gan numuriskais.. Kas biezhi vien nav vajadziigs jo shaa vai taa izmanto tikai vienu no vinjiem. Liidz ar to ja ir daudz un lieli datu apjomi sanaak ka masiivaa tie ir dubulti kas nav vajadziigs.. .. mysql_fetch_array gan ir papildus flagi noraadot mysql_fetch_array($result, MYSQL_NUM) ieguusi pirmaas funkcijas analogu mysql_fetch_array($result, MYSQL_ASSOC) ieguusi fetch_assoc analogu pie kam defaultais nokluseetais ir MYSQL_BOTH kas noziimee ka tiek atgriezti abi varianti - ko Aleksejs nepareizi teica ka mysql_fetch_array atgriezh masiivu kuru nevar indekseet/lietot asociatiivi

Imho baisi taals datums.. Ko var zinaat kas veel pa meenesi notiek.. Kad naak tuvaak vaig teiksim hotj bi tepat forumaa/ircaa lai cilveeki kuri veelas ierasties iebaksta ka vinji buus atstaaj kaut kaadu kontaktinfo.. etc

Nu ja taa runaajam tad Delphi ir pieejams arii PHP frameworks kas ljauj executeet php scriptus kaa rii nolasiit mainiigos delphi (softiskaa videe) :) un pat izmantot kaa scripting valodu softu buuveeshanaa.. :)

Warning: mysql_fetch_array(): supplied argument is not a valid MySQL result resource Pavisam vienkaarsho noziimee ka saformeetais SQL kverijs ir nepareizs uns MySQLAM nepatiik.. Risinaajums 1. Uztaisiit pasham kverijam echo (izvadiit) un uzmest aci vai tieshaam ir pareizis pirms tiek atdots mysql_query() - parasti vai nu truukst kaadas peedinjas, semikola.. rakstiibas kjuudas vai arii kaads mainiigais netiek nodots pareizi piemeeram $table un sanaak "SELECT * FROM WHERE.." 2. Advanceetaak: peec attieciigaa kverija debugeeshanas noluukos iemest echo mysql_errno() . ": " . mysql_error() . "\n"; Un tad jau tev MySQL/PHP pateiks priekshaa kur visa probleema..

No paaudzes paaudzee :) Tikai muusu laikaa veel googles nebija.. Tagad jau viegli jauninjajiem.. Lai gan laikam ejot paliek slinkaaki un bez lasiitprasmes..

Principaa preteeji.. Normaalu (maksas) hostinga provaideri mazaakas kjeskas deelj parasti iesleedz visu globaaljus etc fiichas.. Izsleegti vinji uz freehostinga projektiem kur parasti kaadam vienmeer rodas veelme urkjeeties.. Kas attiecas uz droshiibu tad ja jau reiz ir mainiigais ja reiz tu autorizaaciju balstiisi uz vienu mainiigo $authorized tad tevi neglaabs un buutiski nemainiis fakts vai lapa staavees uz servera ar register_globals On vai Off proti: jo principaa jebkaadus iznjemot sesijas ($_SESSION) paareejos mainiigo masiivus $_GET $_POST $_COOKIE es varu lapai iebarot nesankcioneeti (neparedzeeti no izstradataaja puses) shaa vai taa..

Shaubos ka php.lv buutu jeedziigi njemties ar kaut ko citu nevis webiskaam lietaam/risinaajumiem piem Delphi.. Variant svareetu buut python, perl kursh vai ja piemiedz acis pat VB (asp) kuri var tikt izmantoti kaa serverside analogi php.. Bet nu tu vari ierosinaat taadu sadalju ieksh http://www.sarunas.lv tur diskusiju teemu loks ir krietni plashaaks..

Svariigi ir paskatiities .err failos kas parasti ir izskataas [boxhostname].err taatad vareetu buut slackware.err Tur ganjau viss buus pateikts..

Nu jaa DNS serveris principaa ir taads pats serveris kaa citi (piem db, web, mail) tikai vinsh ar savu programmatuura pilda savus specifiskus uzdevumus. Proti zinaamaa meeraa ir db serveris kas uztur/izsniedz informaaciju par to kaadi domeeni noraada uz kaadaam ip..

Imho delayed izmanto tad kad klientam nav jaagaida (nav vajadziiga/veelama) atbilde no servera par kverija izpildi. Abus kverijus reizee jau netaisa shaa vai taa un taa "maisiishanaas" nav korekta. Delayed katram kverijam taisa savu threadu un pilda to atseviskji. Principaa taisni sheit var rasties kjeska ja serveris pie daudz threadiem aiziet ljur ljur.. Bet visaadaa zinjaa tas ir aatraak no clientu puses un ja ir pieejami sisteemresursi.

http://php.lv/f/index.php?showtopic=646&st=0

http://php.lv/f/index.php?showtopic=649&hl=

Kameer vien attieciigais kverijs atgriezh taadus pashus datus.. ar FLUSH QUERY CACHE; un RESET QUERY CACHE; attieciigi vari "refreshot" vai izmest vispaar visu keshu..

Paexperimentee ar fontiem.. SHitaadi jau principaa manupraat redzami tikai ar dosiskajiem (system) ne truetype

Repleisot visus splitojamos (atdalaamos) simbolus par vienu (piem . , uz | ) un tad explode..

Manupraat ne vienu reizi vien links posteets: http://www.mysql.com/doc/en/Query_Cache.html http://www.mysql.com/doc/en/Query_Cache_How.html Iisumaa kaa jau lielaakoties visos keshoshanas pasaakumos: dati tiek glabaati atminjaa kurai piekljuve ir krietni aatraaka nekaa veershoties pie uz diska izveitotas tabulas + izpildot veel pashus atlasiishanas nosaciijumus..

Parasti tas ir ja mysqld nokillojas/nokreshojas briidii kad tiek rakstiits/ir atveerta attieciigaa tabula vai arii pie HDD probleemaam. Tad vainu nu palaist shaadu SQLu REPAIR TABLE tablename; (shajaa gadijumaa REPAIR TABLE ip; ) Vai arii var externaali ar myisamchk http://www.mysql.com/doc/en/Repair.html p.s. un domaat par kaut kaadu balancingu: 1. Raids (hardware vai software) 2. Vairaaki MySQL serveri ar replikaacijaam..

A browserim cookiji ir atljauti/enableeti? (skatiities pie Inet settingiem/Security) Jo to vai cepums tiek vai netiek izveidots nosaka paarluuks..

1. Nu tev jaaapstraadaa attieciigais lauks ar kaadu no stringa funkcijaam (mysql vai php) Piem lai noselecteetu pirmos 100 simbolus: Mysql gadijumaa pie kverija piem: SELECT SUBSTRING(tekstalauks,100) AS tekstalauks ... php jau analogi: substr($lauks,0,100) http://lv.php.net/substr 2. Nu tad tev attieciigi vairs nav jaiezmanto pirmaas divas metodes.. Proti vari chekot teiksim ja ir atveerts attieciigais materiaals/raksts .. if($id) { //tad vairs netaisam substringus .. } 3. Nu uztaisi jaunu tabulu kuraa glabaajas attieciigaa materiaala/raksta id un komentaars (u.c. dati) un forminju kurai teiksim ir hidden lauks ar atvertaa raksta ID.. Tas arii viss.

Nu ja liekam zem curentaa usera tad by default ir rw attieciigajam failam.. Ja liekam zem /etc cron direktorijaam tad crons runojas zem roota kas overraido liidz ar to ir vienalga.. buutiski ir lai fails ir executabls

Uztaisam mazu shel scriptinju #!/bin/sh DM=`date +%d-%b-%Y` mysqldump -A -u root --password=somepassword > /home/backups/mysql/datubaze-$DM.sql parole protams jaanoraada tad ja no localhosta rootam ir vajadziiga parole.. -A flags noziimee ka dumpojam pilniigi visas DB, bet nu tu vari noraadiit (lasiit augstaak ieprieksheejaa postaa noradiitajaa linkaa) tikai atseviskjas datubaazes vai pat tabulas.. Un iemetam kaut vai /etc/cron.daily vai weekly folderiiti sho scriptinju (protams chmod +x failam vispirms), vai arii ar crontab -e pieliekam kaadam juuzerim..

Vispaar jau domaaju ka vinji neko nemaina apache configaa (lai gan kas zin), jo tas principaa daraas savadaak.. Vai nu tiek customizeets pats webserveris (mainiita source utt) vai arii teiksim izmantotas taa iespeejas. Apache gadijumaa tas ir mod_rewrite http://httpd.apache.org/docs/misc/rewriteguide.html : Taa kaa saits pats uz briidi bija down (noslodze) (vismaz es netiku normaali klaat) tad paarposteeshu attieciigo sample risinaajumu sheit: Vaia rii Google keshaa var palasiit http://66.102.11.104/search?q=cache:rvesIf...&hl=en&ie=UTF-8 Virtual User Hosts Description: Assume that you want to provide www.username.host.domain.com for the homepage of username via just DNS A records to the same machine and without any virtualhosts on this machine. Solution: For HTTP/1.0 requests there is no solution, but for HTTP/1.1 requests which contain a Host: HTTP header we can use the following ruleset to rewrite http://www.username.host.com/anypath internally to /home/username/anypath: RewriteEngine on RewriteCond %{HTTP_HOST} ^www\.[^.]+\.host\.com$ RewriteRule ^(.+) %{HTTP_HOST}$1 [C] RewriteRule ^www\.([^.]+)\.host\.com(.*) /home/$1$2 Taalaak jau jaaskataas kaada ir DNS konfiguraacija: 1) var teiksim pielikt visus *.domeens.lv lai resolveetos uz muusu webserveri (manupraat vienkaarshaakais) 2) attieciigi ar php (vai vienalga ko citu) mainam savu zone failu un rehashojam dns serveri..

Veel papildus http://www.mysql.com/doc/en/Show_database_info.html