Természetesen már próbáltam, de nem sikerült, különféle hibákat jelzett a phpmyadmin. Az egyértelműnek látszik számomra (nem nagyon értek hozzá), hogy szövegfájlt vár az importhoz. Próbáltam simán átírni a kiterjesztést txt-re, átírtam/kitöröltem problémásnak látszó sorokat az sql elején, de semmi eredmény.
Van valami speciális módszer, amivel txt-t lehet csinálni az sql fájlból? Vagy ennek semmi köze nem lehet a gondokhoz?
Az extra.hu napok óta tartó bénázása miatt szeretném átimportálni az oldalam MySQL adatbázisát egy másik ingyenes szolgáltató rendszerébe. Sajnos csak egy - hibátlanul lementett - sql fájlom van, az Extra jelenleg halott, új mentésre nincs lehetőség, ezzel kéne gazdálkodni.
Hogyan lehetne megoldani, hogy hiba nélkül végbemenjen az importálás az új helyen? Az sql fájlt konvertálni kell előbb txt-be?
akkor gyorsan rakj a tablaba egy datetime mezot es amikor felviszel egy rekordot, akkor add meg a now() erteket:) vagy add meg a mezonek, hogy not null default now() es felvitelkor ne adj erteket a mezonek, azaz ne is szerepeljen a mezo felvitelkor (de modositaskor se;) )
attol felek arra gondol, hogy neki nincs a tablaba datum oszlop ami tartalmazna az utolso modositas idejet, hanem azt feltetelezi hogy az adatbazis azt neki eltarolja :)
Sziasztok! PHPMyAdmin felületen szeretnék egy olyan lekérdezést futtatni, hogy egy tábla azon rekordjait listázza, amik egy bizonyos dátum után lettek módosítva. Lehetséges ez, és tudnátok segíteni a parancs összerakásában? Előre is köszi!
Maradjunk annyiban, hogy néha többször is le kellett írni valamit, hogy észrevedd :-)
Ha hatékonyan szeretnél dolgozni, akkor jó tudni kérdezni és kezelni a válaszokat. Semmi baj azzal, ha nem értesz valamit, de olyankor nem az a megoldás, hogy végtelenségig ismétled a kérdést, hanem írd le, hogy mit értesz a válaszból, mit próbáltál ki belőle, és mi nem működött. Meg nem árt emlékezni a válaszokra sem (legalább a saját kérdésekre kapottakra), lásd pl. hogy hányszor kellett hivatkozni a HTTP header válaszra, míg használni kezdted (még a 1655-ben is rákérdezel, pedig nézd meg előtte hányszor van leírva). Az sem baj, ha nem értesz angolul (viszont célszerű megtanulni) és emiatt nem érted pl. a MySQL dokumentációt, de akkor ne hallgass erről, hanem írd meg, hogy ugyan láttad a 1627-ben levő linket, csak nem érted (konkrétan az az oldal van belinkelve, amelyik elmagyarázza hogy melyik beállítás mire való és hogyan lehet állítani - pl. set names). A linkeket azért találták fel, hogy ne kelljen másolgatni egyik oldalról a másikra, elég linkelni.
linuxuser elolvasta a válaszokat, de csak szépen sorjában javította a dolgokat: - adatbázisba SET NAMES utf8 /crockl/ - statikus oldalak utf8 kódolással újra mentése _ÉS_ http header-be utf8/ digicat/ - .htaccess be utf8 /locsemege/
linuxuser elolvasta a válaszokat, de csak szépen sorjában javította a dolgokat: - adatbázisba SET NAMES utf8 /crockl/ - statikus oldalak utf8 kódolással újra mentése /digicat/ - .htaccess be utf8 /locsemege/
Jól van, látom, mindenkit jól kiosztottál. :) Amúgy ez a .htaccess azért merült fel, mert a kérdező megoldotta a problémát már, csak írta, még a statikus oldalban is vacak néhol a kódolás.
"amikor baromira nem is ez volt a kerdes sem, es a problema sem" Pedig te tévedsz, pont az volt a gond, hogy a DB, a fájlok és a http header kódolása nem egyezett meg.
Eredeti kérdés: 1626, válasz 1627, megerősítések: 1638, 1642, 1659.
Azért lett ilyen hosszú, mert linuxuser nem olvasta el a válaszokat, crockl kis késéssel ismételte a korábbi válaszokat (mivel még mindig nem tudja mi volt a kérdés, a hiba és a megoldás), locsemege pedig kötekedett, mert szerinte a szolgáltatóváltás a megoldás mindenre, mivel más megoldásoknak utána kell olvasni :-)
de az egesz abbol indult ki, hogy adatok bejonnek, elmentodnek db-be majd visszaolvasodnak. Nem beszeljetek mar osszevissza legyszi,h hogy file kodolasa mi meg a header mi, amikor baromira nem is ez volt a kerdes sem, es a problema sem:) Csak vki megfarkalta a temat es jol elvitte a thread-et...
Nem baj, csak az már nem tisztán html, mondhatnám, utána kell olvasni a php-nak, meg ugye kell szerver oldali php script futtatási lehetőség. Jó, persze, gyakorlatilag mindenütt van.
BTW: Néha az is segít, ha az ember szól a szolgáltatójának, elmondja, hogy mit szeretne, és a sok jószándék egymásra talál, és már működik is a .htaccess-ben a DefaultCharSetName. (Saját tapasztalatom az t-axelerónál).
És az miért baj? Vagy minek mond ellent? Hogyan másképpen lehetne használni egy php függvényt? De ez it nagyon off, ha gondolod folytathatjuk a php vagy a Weblap-készítés topikban.
"Ezt nem teljesen értem. Kifejtenéd? Ha csak html-t használ valaki, mitől fut a php script? Vagy mi van?" Pl. módosítja a fájlkiterjesztést htm/html-ről php-re. Majd mindegyik fájl elejére beszúrja a <?php header('Content-Type: text/html; charset=KEDVENC_CHARSETEM'); ?> sort. Vagy csinál egy index.php-t, amelyik a megfelelő ellenőrzések után megnyitja és visszaküldi a paraméterben kért fájlt. Egy szolgáltatóváltás nem mindig gyors és olcsó, jól jöhetnek az alternatív megoldások.
a browserek szeretik figyelmen kívül hagyni a html head-ben jelzett kódolást, és helyette a HTTP response-ban levőt használják
Én is ezt tapasztaltam, csak nem tudom, miért van ez így.
Egyébként ha a szerveren van php akkor semmi akadálya a statikus fájlokat php-ből küldeni vissza a kliensnek, így azok is módosíthatják php-ből a HTTP headert, akik amúgy csak html fájlokat használnának.
Ezt nem teljesen értem. Kifejtenéd? Ha csak html-t használ valaki, mitől fut a php script? Vagy mi van?
De, mert a browserek szeretik figyelmen kívül hagyni a html head-ben jelzett kódolást, és helyette a HTTP response-ban levőt használják. Tehát könnyen előfordulhat, hogy egy webszerver a HTTP fejlécben ISO-8859-1-et jelez, de a html tartalom ISO-8859-2, UTF-8 vagy akármi más, és ha a browser a HTTP-ben jelzett kódolással jelenít meg, akkor bizonyos karakterek hibásan jelennek meg.
Jellemzően ingyenes szervereken nem lehet módosítani a HTTP-ben jelzett kódolást, ezeknél egy megoldás van, olyan kódolással kell elmenteni a html fájlokat, amit a szerver előír. Ha van lehetőség a konfig módosítására (pl. .htaccess), akkor nem kell a html fájlokat módosítani (sok fájlnál időigényes lehet). A fentiek statikus fájlokra érvényesek, dinamikus tartalomnál vannak más lehetőségek is. Egyébként ha a szerveren van php akkor semmi akadálya a statikus fájlokat php-ből küldeni vissza a kliensnek, így azok is módosíthatják php-ből a HTTP headert, akik amúgy csak html fájlokat használnának. Az pedig már nagyon ritka (szerintem, ami nem egy reprezentatív minta), hogy egy szerveren ne legyen php, asp, jsp, Asp.Net vagy valami hasonló, vagyis aki megoldást akar, az általában talál is, nem kell egyből megfutamodni :-)
"De meg is tilthatja a .htaccess használatát. Persze ha ezt teszi, akkor szolgáltatót kell váltani." Nem föltétlen, attól függ milyen célra kell. Sok opció beállítható másképpen, pl. a charset a header függvénnyel, a php beállítások az ini_set függvénnyel, szerintem egy HTTP header állításért nem éri meg váltani. Még a rewriteengine is szimulálható .htaccess nélkül (az igényesebb szoftverek anélkül is működnek).
Végső soron ezzel azt konfigurálod. Tulajdonképpen arról van szó, hogy néhány szerveropciót a weblap tulajdonosa is állíthat. A tényleges konfigurációs állományban a rendszergazda meghatározhatja, mely paraméterek - pontosabban mely csoportba tartozók - módosíthatók. De meg is tilthatja a .htaccess használatát. Persze ha ezt teszi, akkor szolgáltatót kell váltani.
