Grey_Wolf

Kaa nav nav UTF-8 kodejuma ?? un tabula tas utf8_unicode_ci ir colation -> faktiski kartosana ... Tas ka neradas korekti LR simboli ir nevis tabulas strukturas vaina, bet gan vaina: a) tavaa skriptaa b) PHPMyAdmin nepareizi iestatijumi c) Brauzera iestatijumi (islekta automatiska kodejuma mainja un uzlikts kds cits kodejums) d) dati nekorekti nodampoti vai uzlikti atpakalj (ar ieslegtu kodejuma mainju), ttieciigi vinji sobriid nav UTF formata bet kautkaada xxx kodejumaa --- DB ir pilniigi vienalga ko un ka saglabat, pati DB datus (baitus) nemaina un nekonvertee, ja vien shamai to nepaprasa -- P.S. SET NAMES UTF-8 IR JABUT !! svadak PHP skripts&SQLs vr nekorekti panjemt/addot datus (kodejuma zinja)

bubu -> Es nekur nemineju par UTF8 bet gan par nacionalajiem simboliem .. zinot ka shamos var dabuut vairakos veidos (dazados kodejumos), tad iespejami taadi briinumi kaa mineeju .. Taapec labak no taa izvairiities ... P.S. teiksim shdi gadijumi noverojami kad failu kopee no citas sistemas , ts ir nevis pats izveido, bet teiksim iekopee no CD etc. (un rid only tur neprichom), kur kaads gudritis faila nosaukuma izmantojis nac simbolus ..

Es runāju tieši par pashu win .. netceros kurš no simboliem bija, bet zinu toch ka problemas bija ar failu izdzesanau (attieciigi arii nevar parvietot ) artii ar failu kopesanu uz servera ir bijushas problemas ...

Saglabat faila nosukumu ar nacionaliem simboliem ir 'sekretares' stils.. jo shadi faili 1. ir slikti parnesami uz citam sistemam 2. dazu labu nacionalo simbolu win. nemak nodzeest ( ir filmenegeri kas to lieliski prot, bet win ar shamo ir problemas)

briedis -> es to sapratu, bet shadiem merkjiem ir labak izmantot areejos tuuljus, kuri ir simtiem .. kuri normali visu sagatavo, ieskaitot DB backupu, un parsuuta uz citu kompi.. PHP, shaja gadijumaa nebuut nav labakais risinajums, protams var bet nu tas buus caur '@&%*#%*'.. Piedevam pasham viss jaraksta etc... Ja izmanto gatavus risinajumus,tad var izmantot 'Daliito sistemu', tas ir ka viena dalja atrodas uz servera otra dalja ir sanjemeejs, kas normali pieregistree sanjemto backupu etc.. P.S. man gan skjiet ka shitais ir kartejais megjinajums 'pazagt' datus..

taadam backupam nebuus nekaada jeega ;) Ja serveris nobruks tad backups tachu pazudiis taapat.. a ja grib automatizeet backuposanu, tad ir ir gana daudz tuulju ko izmantot... Shdiem merkjiem PHP nu galiigi garaam ...

Norekjinajies esmu arii Paypal, pilniigi bez probleemam, kaa arii dazos arzemju I-veikalos .. Skjiet ka daudzkas ir atkariigs no bankas... (kautgan teoretiski bankas jau neveic karshu norekjinus ) edit: aa atieciibaa uz Paypal tur jaizvelas pareizais levelis, ja tas ir pirmais tad ar Electron norekjinaties nevar, piedevam viss atkariigs no summas, ja sakraj noteiktu uzticiibas koificentu , tad arii summa atieciigi aug ...

nu nez man SEB un neko nekur nesmu pieteicis.. gan bnka mineja ka buushot kruti, ja panjemshot Clasic tad vareshot nopirk arii AirBaltic biljetes (i-netaa) bet taa kaa biju jau pircis ar Electronic un izmantojis PyPal tad protams nenjemu ... (papildus izmaksas etc .. ) vismaz ar SEB izdotajam kartem nekaadu problemu ...

pilniigi piekriitu, ne paarak lielaam suumaam der arii 'VISA Electronic' , papals panjem tiiros sikumus saliidzinot ar LR bankam .. no 10$ kutkaadi paris centi, sliktk ir tad ja ir Latu konts, un shmais tiek nokonverteets uz USD -> bankaam kurrs sadam operacijam ir vienkarshi darstisks .. -- Piedevam to paypal naudu var arii nenjemt araa, bet pirkt uzreiz preces ;) buus krietni izdeviigak ...

Kaada pieteiksanas & apmaksas kartiiba? vai par sannjemto suumu REALI cheki buus? ( prieks VID ) ?

Versijas ?

tik tiesham abas ir bazeetas uz SQL (arii MSsql un ORACLE ) taa ka Fundementalas atskjiribas nav .. Mazam projektam izveletos MySQL kaut vai tadel ka PHP krietni labak sadzivo ar shamo ( vesturiski ta izveidojies ) arii ljoti daudzi forumi etc. skripti netbalsta citas DB... Ja projekts ir liels, tad varbuut uzreiz jdomaa par ko citu -> teiksim ORACLE ... bet ja smeraa vienkarsha lapinja (neliels projekts), tad /me personigi izveletos MySql ... kautvai taa vienkarsha iemesla delj, ka 99,99% hostetaju piedavaa Mysql jau pamat paketee ... piedevam ar sameraa labu 'editoru' -> PHPMyAdmin ... prieksh P.SQL vinsh ir mazaak eerts (kad pierod tad ir OK., bet iesacejam sameraa neerts)

izdomaa patsC.. laikam nekad nesi saskaries ar 'arzemju' klientiem .. :( shamiem parbaude ir uz IE6 ... (IE5 nu gan var staigaties 'talam kaajam' )

validators protams ka nebljaustaas, bet ja njem dziljak tad XML standarta izmanto dubultpedinajs, attieciigi XHTML jadara tapat ..

tieshi otrais varjants ir optimalaks, jo izvada validu HTML kodu (id vertiba ir Dubultpedinajs) Piedevam mazak noslogo PHP dalju, jo netik parbaudits vai starp izvadamajam vertibam nav kaads PHP mainigais ...

normalaa situacija (ja serveris preizi nokonfigurets) tas nav iespejams ..

ja tiek izmantots PHP tad var shaadi <script> var JS_mainigais='<?php echo $_GET['id'];?>'; </script>

Parastaam web lapam tik tiesham nav jegas glabat shdus datus, bet ir situaacijas kur tas var buut ljoti noderiigs, piemeram veikals, (vai jebkada lapa kas saistiita ar finanseem ) Arii CMS nenak par ljaunu Logs, vismaz var parbaudiit vai kads nav ko lieku 'savarijis'...

kur problema? $var1=GET['var1']; $var2=GET['var2']; $var3=GET['var3']; $lapas_links='lapa.php?var3='.$var3.'&var1='.$var1.'&var2='.$var2; echo '<a href="'.$lapas_links.'">Jaunais sakartojums</a>';

Ja, PHP kodu ir iespejams nokompileet, tikai pectam redigetgan vinju nevaresi (ja nu vieniigi parzini masiinkodus ) Skatiesh ieks ZEND -> tas gan ir maksas produkts (kompiltors ) cena cik atceros bija ap ~~`600$ PHP kompiltori P.S. pasham laikam bija slinkums pamekleet

Papildus WHERE nosacijums galiigi nav stulbi ... Stulbi buutu katram veikalam veidot atseviskju tabulu .. Piedevam ko noziime Liels ? Ja visi dzivojas uz viena Domena...

Ja vajg klientiem pazinjot teiksim kadus jaunumus (pienacis pasts utt tad var dariit sekojoshi) 1. pastastiit klientam lai norada SMS notifikacijas noteikumus , labs piemers ir Inbox.lv 2. talak jau izmanto klienta noradiito varjantu (tel Nr, identifikators) Vispar jau shii ir laba (erta lieta prieksh klienta, -> faktiski vinsh norada kur parsuutiit datus (tas arii var buut e-mails )

principa Logi ir ljoti laba lieta, Bet Es personiigi izveletos DB Kur pieglaba visu kaspasham skjiet vaajdzigs parasti kaa minimums : Datums, Usera ID, Usera IP, Darbiba (var arii pieglabat pashu Queriju,tas dazkart pat ir vitali nepieciesams, lai varetu atjaunot kadus datus) DB prieksrocibas pret text failu ir samera lielas. 1. var erti notiiriit vecos ierakstus (daudz atrak un vienkarsak ka kjidat text failu ) 2. atrast VISUS dota usera izdaritos labojumus, vai nu pec ID vai IP , 3. vakt statistiku, teiksim noskaidrot ko useri viesbiezak dara nu vel daudzas prieksrocibas .. Piedevam ja tet fails buus liels, tad ierakstisana vinja buus lenaka neka DB. nerunasim jau par to ka liela faila buus lielas problemas atskjirot vajadzigos datus... -- Text failu izveletos, lai piefiksetu kdus errorus, ja viss staisits kurati, tad sadi ieraksti buus ljoti maz, vai vispar nebuus, tad text failam ir krietni lielakas prieksrocibas neka DB -> uzreiz var redzet kur un kada kljuda .. (tiri vizuali redzot ka vinsh virs neaiznjem 0 baitus ..) -- Bet ja tiek veidot Log failu kontrole, tad arii eroorus var mest tabula.. teiksim kontroles modulii, parada cik kura tabula ir ieraksti, un teiksim ja erroru tabula ir neparbaudiits(nesi paskatijies) ieraksts, atd izmet kadu pazinjojumu ... -- Nu kautkaa taaa..

innodb_buffer_pool_size ??? nepaliidzeja palielinat vinju Ntas reizes? vai arii, updeitot pa mazaam porcijam ( izmantot LIMIT ... ) Pedejais jau protams marazmatiski, bet nu varbut tomer risinajums..

Un no tiem pari par trissimtiem skriptu neviens nedereja?