- Xiaomi Smart Band 8 - folyamatosan
- Android alkalmazások - szoftver kibeszélő topik
- Google Pixel 8 Pro - mestersége(s) az intelligencia
- iPhone topik
- Samsung Galaxy S21 FE 5G - utóirat
- Yettel topik
- Apple Watch Sport - ez is csak egy okosóra
- Fotók, videók mobillal
- Samsung Galaxy A54 - türelemjáték
- Samsung Galaxy Watch (Tizen és Wear OS) ingyenes számlapok, kupon kódok
Hirdetés
-
A Video AI lehet a One UI 6.1.1 ütőkártyája
ma Vagy hogy fogja a mesterséges intelligencia manipulálni a mozgóképeket?
-
Rossz üzlet az EV-kölcsönzés
it Küszködik az EV-kölcsönzés miatt a Hertz Global, még több EV-t adnak el.
-
Lenovo Essential Wireless Combo
lo Lehet-e egy billentyűzet karcsú, elegáns és különleges? A Lenovo bebizonyította, hogy igen, de bosszantó is :)
Új hozzászólás Aktív témák
-
Zoltán
őstag
válasz VladimirR #65 üzenetére
Begépeltem betűről-betűre, le is fut, csatlakozik is az adatbázishoz (mint eddig mindig) viszont tovább most se jut, ezt írja ki:
Sikerült a kapcsolat létrehozása
Sikerült kiválasztani a db_ak48 adatbázist
Hiba a tabla létrehozásánál: You have an error in your SQL syntax near ''probatabla' ( 'id' int(10) not_null, 'nev' varchar(8) not null, 'jelszo' varc' at line 1 -
Zoltán
őstag
válasz VladimirR #67 üzenetére
NOT NULL-t kijavítottam, de még mindig ezt írja ki:
Sikerült a kapcsolat létrehozása
Sikerült kiválasztani a db_ak48 adatbázist
Hiba a tabla létrehozásánál: You have an error in your SQL syntax near ''probatabla' ( 'id' int(10) NOT NULL, 'nev' varchar(8) NOT NULL, 'jelszo' varc' at line 1
Idézőjelek-aposztrófok persze ki lettek rendesen cserélve. Az általad linkelt oldalakat pedig sajnos nem tudom elérni.
Már arra is gondoltam, hogy ilyen nevű tábla esetleg már létezik, azért nem tudom létrehozni. Hogyan tudom ellenőrizni, hogy milyen táblák vannak?
[Szerkesztve] -
Zoltán
őstag
válasz VladimirR #67 üzenetére
Na most fogtam magam és egyszerűen becopypastéztem a Te kódodat (és persze kicseréltem az aposztrófokat) és most jó! Csak azt nem értem, hogy ha Én írom be pontosan ugyanezt (szintaktikai hiba nélkül, hisz lefut, nem szól a php, hogy ebben és ebben a sorban hiba van), akkor miért nem jó? Meg 2 könyvet is megnéztem, hogy hogyan kell pontosan mit-hova írni és úgy csináltam. Nem értem. Örülök, hogy végre jó, csak bosszant, hogy nem tudom, hol volt a hiba. (Az meg mégsem mehet, hogy minden egyes mysql ténykedésemkor rohanjak ide, hogy írd le légyszi helyettem, mert csak úgy megy )
Köszönöm szépen!!
MOD: Most vettem észre, hogy az általad írt aposztróf máshogy néz ki, mint az általam írt! A tied döntött, az enyém (1-es fölötti shiftel) meg egyenes. (Összehasonlítottam a két kódot, (két notepadot egymás után gyorsan kapcsolgatva) így vettem észre). Ez meg mi a szösz lehet? Fontosak az aposztrófok vagy elhagyhatók, esetleg idézőjellel helyetesíthetők?
Köszi
[Szerkesztve] -
Zoltán
őstag
válasz VladimirR #71 üzenetére
Oké , köszi, akkor ez most rendben van. Letöröltem a 2 táblát és kezdtem előről. Most van egy ''probatablam'' , abban benne van az első sor (az Annás), autoincremant van, így id -t nem adok meg. Aztán az alábbi kóddal be akartam tenni a következő sort is, úgy tűnik bele is rakta, de nem tudja kiválasztani a ''Belapapa'' -s sort. Így próbáltam:
<?php
$database=''db_ak48'';
$sqlhost=''localhost'';
$sqluser=''ak48'';
$sqlpass=''37Ws8wHH2QdRg'';
$ujtabla = ''CREATE TABLE `probatabla` (''
. '' `id` INT(10) NOT NULL AUTO_INCREMENT, ''
. '' `nev` VARCHAR(8) NOT NULL, ''
. '' `jelszo` VARCHAR(10) NOT NULL, ''
. '' `email` VARCHAR(250) NOT NULL, ''
. '' `datum` VARCHAR(20) NOT NULL, ''
. '' `ip` VARCHAR(250) NOT NULL, ''
. '' PRIMARY KEY (`id`)''
. '' )'';
$nev = ''Belapapa'';
$jelszo = ''rugoka'';
$email = ''berugos@franconmail.hu'';
$datum = ''2004.11.27. - 18:10'';
$ip = ''111.222.333.444'';
$parancs = ''INSERT INTO `probatabla` ''
. ''(`nev`, `jelszo`, `email`, `datum`, `ip`) ''
. ''VALUES ''
. ''('$nev', '$jelszo', '$email', '$datum', '$ip')'';
$kapcsolat = mysql_connect($sqlhost, $sqluser, $sqlpass) or die(''Nem lehet csatlakozni: ''.mysql_error().''<br>'');
print ''Sikerült a kapcsolat letrehozasa<br>'';
mysql_select_db($database) or die(''Nem lehet megnyitni az adatbázist: ''.mysql_error().''<br>'');
print ''Sikerült kiválasztani a ''.$database.'' adatbázist<br>'';
mysql_query($parancs, $kapcsolat) or die(''Hiba a lekerdezes kozben: ''.mysql_error().''<br>'');
print ''Sikerült beilleszteni az adatokat az adatbazisba<br>'';
$nev = ''Belapapa'';
$sorlekerdez = mysql_query(''SELECT * FROM `probatabla` WHERE nev like `$nev` '') or die(''Hiba a lekerdezeskor: ''.mysql_error().''<br>'');
print ''Sikerült lekerdezni az adatokat az adatbazisbol<br>'';
$sorok= mysql_num_rows($sorlekerdez) or die(''Itt a bibi, valami nem jo'');
print ''Sorok szama: ''.$sorok;
mysql_close($kapcsolat);
?>
Erre ezt írta ki:
Sikerült a kapcsolat letrehozasa
Sikerült kiválasztani a db_ak48 adatbázist
Sikerült beilleszteni az adatokat az adatbazisba
Hiba a lekerdezeskor: Unknown column 'Belapapa' in 'where clause'
Tehát úgy tűnik bele tette a 2. sort, de Belapapa nevűt nem talál.
MOD: biztos, hogy betette a 2. sort, mert a sorok számát jól le tudom kérdezni, de Belapapa-t sehol sem talál. Hogyan keressem? Illetve tudnál ajánlani egy rendes mysql (elektronikus) könyvet, mert úgy tűnik semmi sincs jól abban amit én találtam. Köszi!
[Szerkesztve] -
Zoltán
őstag
válasz VladimirR #82 üzenetére
Akkor most jól megy, ha olyat írok be ami nem létezik, de ha létező nevet, akkor nem ír ki semit, sőt a később jövő sorok sem futnak le. Most így áll:
$ilyennincs=''g'';
$lekeres2 = mysql_query(''SELECT * FROM probatabla
WHERE nev= '$ilyennincs' '');
if (mysql_num_rows($lekeres2) != 0)
{
while ($row = $result->fetch_assoc())
{
print ($row[''nev'');
}
}
else
{
print ''<br>nincs még ilyen név0'';
}
''g'' nevű emberke van és semmit sem ír ki. Meg az ezek utáni sorok sem futnak le (egy másik lekérdezés, ami eddig jól ment, meg akkor is jó, ha olyat adok meg $ilyennincs -nek, ami nincs.
Most mé' nem jó ? -
Zoltán
őstag
válasz VladimirR #92 üzenetére
Helyzet így is ugyanaz, mint a #91-ben. Nem írja ki a nevet és a progi sem fut tovább, tehát nem listázza ki az egész táblát (az jönne ezután). Ha nemlétező nevet írok be, akkor jól kiírja, hogy ilyen nincs és fut tovább a progi, tehát egy táblázatban kiírja, hogy mik vannak a táblában.
MOD: Na, rájöttem, így a jó a while:
while ( $row = mysql_fetch_array( $lekeres2 ) )
{
print $row[''nev'';
}
Most jó, örülök. Köszi mindhármótoknak!
[Szerkesztve] -
Zoltán
őstag
-
b14
senior tag
válasz VladimirR #169 üzenetére
Ezt a php könyv így írta:
$keres = ''SELECT * FROM apro'';
$eredmeny = mysql_query( $keres, $kapcsolat );
$i=0;
while($egy_sor = mysql_fetch_assoc( $eredmeny ))
{
$i++;
print $szamlalo.''. sor: ''
.'' ''.$egy_sor['apro_id']
.'' ''.$egy_sor['apro_felado']
.'' ''.$egy_sor['apro_eler']
.'' ''.$egy_sor['apro_mettol']
.'' ''.$egy_sor['apro_meddig']
.'' ''.$egy_sor['aprohirdetes']
.'' ''.$egy_sor['link'].''\r\n'';
}
[Szerkesztve]''...de a konfigjából kiindulva, nem hiszem, hogy 40 éves családos ember lenne...'' -- by Slax
-
Szalma
őstag
válasz VladimirR #175 üzenetére
(Ha dump import volt és nem db file másolás, akkor valószínűleg a db és tábla karakterszetek a default utf-8-ra álltak be... Nem bonyolult állítgatni! Itt nézelődj -> Bővebben: link (MySQL doksi. ))
Szeretettel:
Szalma -
Rici
tag
válasz VladimirR #180 üzenetére
Amit a mysqld súgója ír ki, az valószínűleg távol áll az igazságtól. A phpmyadmin által megadott értékek már jobban néznek ki. Igazából azt kellene tudni, hogy milyen program is akar hozzáférni valójában az adatbázishoz, gondolom egy php alapú site-ról van szó, a phpmyadmin csak karbantartasra van, ha jól gondolom.
Röviden összefoglalom, hogy hogyan is működik ez a karakterkészlet dolog: amikor a szerver eltárol egy sztringet, azt egy bájtsorozatként tárolja el, és a szerver / adatbázis / tábla / oszlop szintjén meg lehet határozni, hogy az eltárolt bájtsorozatot hogyan is kell értelmezni (milyen karakterkódolásban van). De ez igazából csak a mysql szerver számára fontos, hogy pl. hogyan hasonlítsa össze a bájtsorozatokat rendezéskor. Tehát ez a tárolási kódolás, ami pl. a character_set_server vagy a character_set_database változó értéke, ill. a táblákhoz és oszlopokhoz rendelt tárolási kódolást a SHOW CREATE paranccsal lehet megnézni. Ennek a tárolási kódolásnak a kliens felé menő lekérdezések szempontjából sok jelentősége nincs, legfeljebb annyit érdemes tudni, hogy a latin_ kezdetű dolgoknál 256 féle-karaktert lehet tárolni, az ucs2- és utf-8 kódolással pedig a Unicode kódtábla alsó 65536 karakterét.
Amikor a mysql kliens felé jönnek sztringek vagy a kliens küld sztringeket, akkor ugyebár azok is egy bájtsorozat formájában léteznek, és hozzájuk is tartozik egy karakterkódolás, hogy hogyan is kell értelmezni a bájtsorozatot. Itt jön a lényeges, a kliens számára is érdekesebb rész. A kliensnek meg kell mondania, hogy mi is legyen ez a bizonyos kódolás, amivel szeretné a sztringek bájtsorozatát megkapni. A konverziót a szerver automatikusan elvégzi. Elméletileg tehát mindegy, hogy miben van tárolva a sztring, a szerver mindig azzal a kódolással küldi, amivel a kliens kéri. Persze a konverziónál bekerülhetnek kérdőjelek a sztringekbe, mert pl. egy utf8-ban tárolt arab betűt nem lehet egy 256 féle karaktert támogató latin2 karakterkódolással ábrázolni. És persze az ő/ű betűk is ebbe a kategóriába tartozhatnak, ha pl. utf8-ról latin1-re kell konvertálni, de pl. utf8-ról latin2-be már menniük kell. Gyakorlatilag persze nyilván érdemes abban tárolni a sztringeket, amiben le lesz kérdezve, mert akkor nem kell a szervernek állandóan konvertálgatni.
Ezek a kliens oldali dolgok a character_set_client, character_set_connection, és character_set_results változókban vannak tárolva, amiket a megfelelő paranccsal a kliensnek be kell állítania, mert alapból nem számíthat rá, hogy a szerver pont abban küldi, amiben a kliens gondolná.
Általában itt szokott lenni a gond. Pl. ha egy .php oldal iso-8859-2 kódolással küldi az oldalakat a böngésző felé, de az adatbázisból utf8-cal kéri le a sztringeket, akkor ott gáz lesz. (feltéve ha nem használ maga a php karakterkonvertálást az iconv_ vagy a mb_ függvényekkel.)
Tehát a lényeg: a kliensnek kapcsolódás után pl. egy SET CHARACTER SET latin2; és SET NAMES latin2; parancsot kell kiadnia, és akkor már latin2-ben érkeznek a válaszok.
Egyébként ez az egész karakterkódolás téma _nagyon_ összetett, de ha tényleg át akarod látni, akkor nagyon ajánlom, hogy nézz utána, hogy pl. mi is az a Unicode, az utf8 kódolás, a latinX kódolások stb. -
Jester01
veterán
válasz VladimirR #305 üzenetére
delete from posts where topicid not in (<halmaz>)
Szerintem semmi baj nincs ezzel a megoldással. Gondolom a <halmaz> egy al-select, jelen esetben tehát valami ilyesmi lesz a parancs:
delete from posts where topicid not in (select topicid from topics)
Alternatív módszer:
delete from posts where not exists (select * from topics where topics.topicid = posts.topicid)
Az explain parancs által adott infók alapján nekem úgy tûnik, hogy az elsõ a gyorsabb. Ha van index a topics.topic_id mezõre, akkor azt mind a két verzió kihasználja.Jester
-
VladimirR
nagyúr
válasz VladimirR #311 üzenetére
meg egy kerdes:
ha van ket tablam van-e kulonbseg sebessegben, memoriahasznalatban az alabbi ketto kozott:
1:
select id from tabla1 where name = 'nev';
ezt bepakolom egy valtozoba
select count( id ) from tabla2 where tid = valtozo;
2:
select count( id ) from tabla1 inner join tabla2 on tabla1.id = tabla2.tid where tabla1.id = 'nev';
azert kerdezgetek ennyi hulyeseget, mert nem egy kimondott izomgep-re keszulok attenni az adatbazist, ahol szamitani fog, hogy igazan jol legyenek belove maga az adattarolas is es a lekerdezesek is
segitsegeteket elore is koszonom -
Jester01
veterán
válasz VladimirR #311 üzenetére
egy up a kesonkeloknek
mi a kulonbseg a varchar es a text adattipuxok kozott
varchar -nak a rekordban van foglalva hely (a maximális hossznak), text esetén csak a hossza és egy pointer van eltárolva. Ez utóbbi egy külön területre mutat. A text ezért lassabb, de kevesebb helyet foglal.
mi az az index prefix length
Az index csak ennyi karaktert használ. Az olyan értékeket amik ezen hosszig megegyeznek azonosnak tekinti. A lekérdezéskor a látszólag egyező értékekre még egy szűrés fut.
mi a kulonbseg szoveges (varchar, text) mezo eseteben a sima index es a fulltext index kozott?
Fulltext indexben mindenféle vicces módon lehet keresni (MATCH ... AGAINST), sima indexben csak összehasonlítás van (kisebb-nagyobb-egyenlő).
hogy jobb index-et kesziteni? melyiknek mik az elonyei, hatranyai?
-a) alter table tablanev add index ( mezo1, mezo2 );
-b) alter table tablanev add index ( mezo1 ).|. table tablanev add index ( mezo2 );
Ez a két eset nem ekvivalens. Az első esetben mezo2-re nincs index (ha az adott adatbáziskezelő jobbról használja az összetett indexeket - ellenkező esetben mezo1-re nem lesz index). Ha mindig mind a két mezőre van szűrés, akkor az első módszer jobb lesz. Ha viszont a két mezőre külön-külön is akarsz keresni akkor a másodikra van szükséged. Plusz ha UNIQUE feltételed is van, akkor az első esetben a (mezo1, mezo2) pároknak kell egyedinek lenni, míg a másodikban a mezo1 és mezo2 értékeknek külön-külön.
MOD: szóval az összetett indexet (az adatbáziskezelőtől függően jobbról vagy balról) tetszőleges hosszig lehet használni. Pl. a (mezo1, mezo2, mezo3) indexet lehet (mezo1), (mezo1, mezo2), (mezo1, mezo2, mezo3) indexként is használni.
ha van ket tablam van-e kulonbseg sebessegben, memoriahasznalatban az alabbi ketto kozott:
Ránézésre nincs (feltéve, hogy van index mind a 2 lekérdezéshez). De az első a biztosabb.
Ha valahol hülyeséget írtam, javítsatok ki
[Szerkesztve]
[Szerkesztve]Jester
-
Jester01
veterán
válasz VladimirR #318 üzenetére
A biztosabbat úgy értettem, hogy így csak kisebb mértékben bízod a query optimizer-re a döntést. A két egyszerû lekérdezésnél (RedAnt javaslatával) valószínû, hogy 2 index lookup lesz az egész. Elvileg az optimizer is ezt adja és úgy megtakaríthatsz egy parancsfeldolgozást. Persze csak ha bízol benne
Ami a varchar-t illeti valóban igazad van. Mondjuk egy ilyen utalást találtam azért a leírásban: ''Remember that MySQL may treat VARCHAR columns as if they're CHAR columns, in which case the fixed format is used.'' De fogalmam sincs mire céloz.Jester
-
emitter
őstag
válasz VladimirR #329 üzenetére
köszi
lenne egy újabb kérdésem, hogyan tudom a mysql-daemont más user nevén indítani? root-ként akarom, de ezt írja:
emitter@LAPTOP:/var/www$ mysqld --user=root
070121 21:34:07 [Warning] Ignoring user change to 'root' because the user was set to 'mysql' earlier on the command line
és mysql névvel indítja.. -
Lortech
addikt
válasz VladimirR #360 üzenetére
Korán van még, lehet ezért nem világos.
Egy hash esetén miért kéne hogy átkódold, és helyesen jelenjeg meg az adatbázisban, vagy bármi átalakítást végezz rajta? Ezesetben szvsz az a legjobb, ha nem csinálsz vele semmit, úgy rakod az adatbázisba, ahogy legeneráltad, így kivételkor sem kell odafigyelni, hogy visszaalakítsd, mert (gondolom későbbi összehasonlítás céljából tárolod el a hasht) az összehasonlítandó hash is ebben a kódolásban van.Thank you to god for making me an atheist
-
VladimirR
nagyúr
válasz VladimirR #362 üzenetére
ehh, naszoval tenyleg koran van meg
szoval az a gond, hogy ha egy lekerdezesben akarok adatbazisba illeszteni egy usernevet es egy jelszohoz tartozo binaris sha1 hash-t, akkor az egyik nem fog latszani, attol fuggoen, hogy a kapcsolategyeztetes be van-e allitva utf8-ra -
Jester01
veterán
válasz VladimirR #365 üzenetére
A mező collation legyen BINARY. Ha ez még mindig nem elég, akkor add be hexában.
mysql> create table t(hash char(20) BINARY);
Query OK, 0 rows affected (0.01 sec)
mysql> insert into t values (0xC3A9);
Query OK, 1 row affected (0.00 sec)
mysql> select hex(hash) from t;
+-----------+
| hex(hash) |
+-----------+
| C3A9 |
+-----------+
1 row in set (0.00 sec)Jester
-
cucka
addikt
válasz VladimirR #556 üzenetére
Ha csak annyit kell eldönteni, hogy kell-e frissíteni, akkor miért nem számolod meg egyszerűen a topikokat és a hozzászólásokat mindkét szerveren?
Gondolom mindent kell szinkronizálni, tehát ha a hozzászólások száma különbözik, id szerint meg fogod tudni mondani, mely sorokat kell áthozni..
Új hozzászólás Aktív témák
- Gitáros topic
- Politika
- Autós topik látogatók beszélgetős, offolós topikja
- Milyen SSD-t vegyek?
- Xiaomi Smart Band 8 - folyamatosan
- Győr és környéke adok-veszek-beszélgetek
- gban: Ingyen kellene, de tegnapra
- CASIO órák kedvelők topicja!
- Kerékpárosok, bringások ide!
- Android alkalmazások - szoftver kibeszélő topik
- További aktív témák...