Aktív témák
-
#2129
Sk8erPeter
nagyúr
arisu
#2128
Sk8erPeter
nagyúr
Hát azért, mert localhoston, a MySQL-szerveren nem hoztad létre az "xyz" felhasználót, vagy nem adtál hozzá jelszót, vagy rossz jelszót adtál hozzá, vagy csak nem rendelted hozzá az engedélyeket a webshop táblájához... ezek valamelyike. Tehát ugyanaz a felhasználónév+jelszó páros legyen meg localhoston is, mint az éles MySQL-szerveren.
Ha nem lenne jelszó, az gáz lenne.
-
#2126
Sk8erPeter
nagyúr
Peter Kiss
#2123
Sk8erPeter
nagyúr
válasz
Peter Kiss
#2123
üzenetére
Tehát az eredeti állításom, miszerint a query-k konkatenálását az IN-jellegű lekéréseknél nem úszod meg, igaz.
A megvalósítás viszont megint más kérdés, ez is tény. A "behelyettesítés" meg valóban úgy a "biztonságos", ahogy írod. Bár ha valakinek van némi fogalma az adatbázis-lekérésekről, az remélhetőleg nem fog így se-úgy se escape-eletlenül hozzáfűzögetni semmit. -
#2122
Sk8erPeter
nagyúr
Peter Kiss
#2121
Sk8erPeter
nagyúr
válasz
Peter Kiss
#2121
üzenetére
"közben kiegészítem a query-t ?-ekkel (nem használok nevesített paraméterek), majd elrakom a tömböt. Végrehajtáskor már megvan a kész query"
Tehát akkor kénytelen vagy konkatenálni a query-t, ugye? -
#2120
Sk8erPeter
nagyúr
Peter Kiss
#2119
Sk8erPeter
nagyúr
válasz
Peter Kiss
#2119
üzenetére
Hogyan használod? Pont erre lennék kíváncsi.
Nálam a sima implode-os prepared statementes átadás rosszul működik, nem adja vissza azt az eredményhalmazt, amit várok, és amit akkor ad vissza, ha simán lefuttatom a query-t, megadott id-kkel. -
#2118
Sk8erPeter
nagyúr
Peter Kiss
#2117
Sk8erPeter
nagyúr
válasz
Peter Kiss
#2117
üzenetére
Ki is próbáltad az IN-nél?
Én csak kerülő megoldásról tudok, ahogy itt írják:select users.id
from users
join products
on products.user_id = users.id
where find_in_set(cast(products.id as char), :products)Itt a
find_in_set(cast(products.id as char), :products)
a lényeg, feltételezem, ez jóval lassabb, mint egy "rendes" IN...localhoston gyorsan tesztelve az előbbi 0.0276 másodperc, míg a "normál" IN 0.0008 másodperc, ami azért igen jelentős különbség azt tekintve, hogy összesen 4 sor van a teszttáblámban. Óriásira nőtt adatbázisnál szerintem ez elég durva különbségekhez vezethet!
==
"Egyébként szerintem van értelme pl. PDO köré is wrapper-t írni, mert nagyon ocsmányul néz ki."
Mi a baj vele?"Főleg akkor hasznos, ha ismeretlen számú paraméterekkel kell dolgozni."
Array-t is átadhatsz az execute()-nak. -
#2113
Sk8erPeter
nagyúr
papa019
#2110
Sk8erPeter
nagyúr
válasz
papa019
#2110
üzenetére
Akkor bocsánat, nem szóltam, csak ugyanúgy nézett ki a dolog, mint korábban, konkatenáltad, ugyanaz a változónév, stb., ezért hittem azt, hogy ugyanazt a saját osztályt használod, mint korábban.
Ha PDO-t használsz, akkor onnantól - szerencsére - a mysql_ kezdetű függvények megszűntek létezni!! Thank God!
Tehát pl. a mysql_fetch_row() használatát felejtsd el innentől örökre.
Ahogy az is megszűnt létezni, hogy összefűzögesd a query-ket, azt NEM SZABAD. Azt is felejtsd el. Csak NAGYON ritkán van rá szükség, pl. az IN(...) jellegű query-knél.Tehát pl.:
$result = $DB->query("SELECT * FROM places WHERE id = '$parent_area')");
$result->setFetchMode(PDO::FETCH_COLUMN);
while($row = $result->fetch())
{
$has_parent=$row['parent_has_parent'];
}HELYETT
$sth = $DB->prepare('SELECT * FROM places WHERE id = :id');
$sth->bindParam(':id', $parent_area, PDO::PARAM_INT);
$sth->execute();
$myResults = array();
while($row = $sth->fetch(PDO::FETCH_ASSOC)){
// do something with this row....
$has_parent=$row['parent_has_parent'];
if($has_parent){
// ...
}
else{
// ...
}
$myResults[] = $row;
}===
(#2111) Briganti : rossz helyre címezted.
-
#2099
Sk8erPeter
nagyúr
FlashPlayer
#2098
Sk8erPeter
nagyúr
válasz
FlashPlayer
#2098
üzenetére
Hát ez vicces, ha az ember elkezd érdemben foglalkozni a PHP-val, lehetetlen, hogy ne botoljon bele a HIVATALOS oldalba...
Bocs, de ez arra enged következtetni, hogy azelőtt kérdeztél, mielőtt megpróbáltál volna kicsikét normálisan utánanézni. -
#2094
Sk8erPeter
nagyúr
1NT1M3
#2093
Sk8erPeter
nagyúr
Másik topicban már megvolt a hirdetés, elég lesz egy helyen.....
-
#2092
Sk8erPeter
nagyúr
wolandino
#2091
Sk8erPeter
nagyúr
válasz
wolandino
#2091
üzenetére
Mivel nem konkretizáltad a dolgot, magunktól nehéz kitalálni, hogy ha egyszer a felhasználó töröl, akkor mindenhonnan törölnie kellene a dolgokat, vagy pl. az összekapcsoló táblában mondjuk csak be kéne rakni egy NULL-t az egyik mezőhöz, jelezvén, hogy pl. az adott elemnél hiányzik egy "párosítás", még a hozzákapcsolásnak csak az "egyik fele" van meg, és lehetne még pár lehetséges változatot kitalálni.
Nem egyértelmű tehát, hogy miket jelölhet törlésre... olyan eset is elképzelhető, hogy a bejegyzéseket egyszerűen csak az összekapcsoló táblából kellene törölni, tehát akkor egyedül az összekapcsoló táblában nyilvántartott id-k közül kellene választania a júzernek (nyilván a hozzátartozó felhasználóbarát adat segítségével, ne id-k közül válogasson). Akkor meg egyértelmű: szűkíted a törlést arra az id-re a kapcsoló táblából, amit a júzer kiválasztott, és megvagy. De mondom, nem specifikáltad a problémát. -
#2080
Sk8erPeter
nagyúr
coco2
#2078
-
#2076
Sk8erPeter
nagyúr
coco2
#2074
Sk8erPeter
nagyúr
Ezek a "szanaszét külön fileokba pakolt script állományok" mind külön adatbázis-dumpfájlok MySQL-ben írva?
Vagy mi?
Nem igazán konkretizáltad.
Önmagában a fájlok összefűzésére lehetne írni egy batch-fájlt is, aztán ezt .gz-ben tömörítve fel lehetne küldeni a szerverre egyben, dehát ki tudja, a Te változatodhoz ez megfelel-e, számomra legalábbis nem derült ki a hsz.-edből. -
#2069
Sk8erPeter
nagyúr
SektorFlop
#2068
Sk8erPeter
nagyúr
válasz
SektorFlop
#2068
üzenetére
SELECT `id` FROM `test_table`
ORDER BY RAND()Ezt felhasználva csináld meg, amit szeretnél. Nem fejtetted ki bővebben, mit értesz azalatt, hogy "5 db sort szeretnék lekérni id alapján véletlenszerűen."
-
#2034
Sk8erPeter
nagyúr
cAby
#2025
Sk8erPeter
nagyúr
Az a baj, hogy már maga az adatbázis struktúrája rossz ebben a formában. Úgy kellene, hogy itt azonosítókat kapcsolsz össze, ami kiadja egy szállodaentitás tulajdonságait.
Az összes tulajdonsághoz tartozna egy azonosító (pl. magához az ellátás típusához is tartozik egy számszerű azonosító (pl. 666)), és a tulajdonságok konkrét értékeihez is tartozna azonosító (pl. a reggeli típusa 1, a félpanzió 2, a teljes ellátás 3, stb.), stringekkel ilyen esetben nem nagyon érdemes dolgozni, vagy legfeljebb egyetlen táblában legyen, amit összekapcsolsz az összes többivel, hogy megtudd, melyik tulajdonságról van szó - pl. nyilván a tulajdonságnak (ellátás) van egy neve is, ezt egy külön táblában jelezni kell; de van a tulajdonságokhoz tartozó értékeknek (reggeli, stb.) is neve, de ezek legyenek elkülönítve. Aztán INNER JOIN-olod őket...
Bocs, de most kissé késő van, ha holnap lesz energiám, ennél egy kicsit bővebben is kifejtem... Ez nagyjából ahhoz hasonlóan működik, mint egy társkereső, ott is vannak paraméterek, amik szerint keresget az ember mondjuk partnereket, nekem kellett hasonlóval dolgoznom már adatbázisszinten, na ott a fenti elképzelés szerint csináltam, elég összetett lett, de nagyon jól szűrhető, és elég konzekvens, de ami leginkább előnye, hogy könnyen bővíthető újabb paraméterekkel a meglévő struktúra megborítása nélkül.
Gondolom ez most így csak bonyolult fostengernek tűnik így elsőre, de annyira nem is az, majd megpróbálom jobban kifejteni, ha érdekel. -
#2033
Sk8erPeter
nagyúr
SektorFlop
#2030
Sk8erPeter
nagyúr
válasz
SektorFlop
#2030
üzenetére
Na ne már....
Most komolyan azt javaslod, hogy minden adatot kérjen le adatbázisból, és majd utána szűrjön? Akkor gondolj bele, mi van, ha feltételezzük, hogy többmillió adata van, amik közül keresgélni kellene... akkor először az ÖSSZESET tök feleslegesen lekéri, és ezek után szűr? NEM, ilyet soha ne csinálj.A fórum-hozzászólásoknál meg különösen illene szűrni, ott ugyanis még dinamikusabban nőhet az adatbázis mérete. És erre nem lehet válasz az, hogy "ugyan már, az én oldalamon úgysincs olyan nagy forgalom", ez a hozzáállás nagyon rossz, mi van, ha valamilyen oknál fogva mégis az lesz? Vagy mi van, ha akarsz egy következő alkalmazást fejleszteni, majd azt is úgy készíted, mert jól működött az előzőnél?
Amit itt írtál, az ilyesmi jellegű változónak átadás:
$tipus = $sor['tipus'];
az idők során rá fogsz jönni, hogy egy nagyon rossz szokás.
Ilyen módon nem bejárhatóak a későbbiekben az érintett adataid ciklussal, nem tudod őket könnyedén, egyértelműen kezelni, nem tudsz köréjük egy wrapper osztályt írni, vagy nehézkesen, és egyéb problémák is felmerülhetnek ezzel kapcsolatban.
Érdemes inkább kigyűjteni tömbökbe vagy objektumokba ezeket az adatokat, amik egy helyre tartoznak.
pl.
$hotels = array();
while($row = ............){
$hotels[] = $row;
}egy leegyszerűsített példával élve. Ezután egyszerűen bejárhatók a hotelek adatai pl. egy foreach-csel.
-
#2024
Sk8erPeter
nagyúr
SektorFlop
#2021
Sk8erPeter
nagyúr
válasz
SektorFlop
#2021
üzenetére
Tehát magyarul van egy forum_msgs táblád, és azonbelül a datum mező neve nem simán datum, hanem forum_msgs.datum?
Hát eléggé felesleges, hogy az adott nevű tábla mezőit kiegészíted a táblanév+mezőnévvel, és magunktól nehéz lett volna kitalálni, hogy ilyen rossz szokásokat alkalmazol, amíg le nem írod.
Én azt javasolnám, inkább erről szokj le, de persze egyéni döntés.
Nincs mit!(#2023) wolandino :
szívesen, de mire jutottál? -
#2019
Sk8erPeter
nagyúr
SektorFlop
#2016
Sk8erPeter
nagyúr
válasz
SektorFlop
#2016
üzenetére
A lekérdezésed jó. (már amennyiben létezik a "datum" mező a forum_msgs táblában, de feltételezem, létezik)
A PHP-kódnál viszont nem kell oda a forum_msgs, tehát ehelyett:$hozzaszolt=$sor['forum_msgs.user'];
$datum=$sor['forum_msgs.datum'];
$uzenet=$sor['forum_msgs.msg'];
$nev=$sor['forum_msgs.topic'];próbáld ezt:
$hozzaszolt=$sor['user'];
$datum=$sor['datum'];
$uzenet=$sor['msg'];
$nev=$sor['topic']; -
#2015
Sk8erPeter
nagyúr
bLaCkDoGoNe
#2014
Sk8erPeter
nagyúr
válasz
bLaCkDoGoNe
#2014
üzenetére
Na igen. Ha így csinálná, akkor nem lenne kérdés, mi legyen a flag arra vonatkozóan, hogy munkanapról van-e szó, vagy sem. Szerintem is ez lenne a jó, erre el is felejtettem előbb válaszolni.
-
#2013
Sk8erPeter
nagyúr
wolandino
#2009
Sk8erPeter
nagyúr
válasz
wolandino
#2009
üzenetére
1.) itt a százalék helyett miért nem valami jobban kalkulálható egységgel dolgozol? Például a meló mértéke lehetne inkább óra egységben megadva: adott hónapban X órát dolgozott. Persze ettől függetlenül lehetne pluszban egy mező, hogy ez most 100%-ot, vagy 432%-ot jelent, bár lehetne ezt is másképp megoldani, ez már egyéni döntés kérdése.
2.) hmm, itt most gyorsan átfutva nem jut eszembe hirtelen más, mint hogy minden naptári napot eltárolni - tulajdonképpen muszáj, hiszen minden napra más adat vonatkozik.
Mivel minden naptári naphoz tartozhat általános, mindenkire érvényes adat is, esélyes, hogy egy külön táblában kellene tárolni a naptári napokat,és ezek id-jaihoz kapcsolni az egyes dolgozók napokra lebontott adatait. Szerintem csak így tudsz minden adatot jól követhetően tárolni, hogy minden évre, napra, dolgozóra rá lehessen külön keresni, és viszonylag általános legyen a szerkezet. Még ha sok adat is lesz ezzel, több táblában, és dolgozónként hivatkozni kell a naptári napok id-jaira az év összes napján...
Nem kell minden évnek külön tábla, egy szerintem elég, ahol az összes naptári nap szerepel, aztán lehet, hogy van erre megfelelő ellenérv. De ilyen esetben mindenképp érdemes szerintem különbontani a dátum egyes adatait, tehát akár évet, hónapot, napot, bizonyos dátum szerinti kereséseknél tudtommal ez hatékonyabb is lehet, mert nem kell mindig dátumkonverziós függvényeken keresztülverni az egész dátumot.Most nem gondoltam végig minden lehetőséget, tehát remélem még valaki hozzátesz a gondolatmenethez.
Egyébként ez igazából szimpla SQL-kérdés, semmi köze a PHP-hoz, nyugodtan mehetett volna az SQL-kérdés topicba, ott talán többen is látják, azok is, akiket a PHP nem érdekel, de vágják az SQL-t (és követik a topicot). Tulajdonképpen nem tudom, melyik a látogatottabb topic.
-
#2012
Sk8erPeter
nagyúr
tras
#2008
Sk8erPeter
nagyúr
Nem hiszem, hogy így látatlanban, mindenféle körülmények leírása nélkül fogja neked tudni bárki is, hogy mit kellene tartalmaznia a general_setting tábládnak, de először is létre kéne hozni...
Másrészt a /tmp könyvtár nem elérhető vagy nem írható a webszerver számára, állítsd át php.ini-ben a session.save_path értékét, vagy adj rá írási jogokat, már amennyiben saját rendszeredről van szó, és/vagy hozzáférsz a beállításokhoz.
Na meg kicsit részletesebben számolj be a problémádról.Szerk.:
(#2011) bLaCkDoGoNe : hogy a helyzetet súlyosbítsam, ezek után még priviben is próbálkozott ugyanezzel, 0 előrehaladással, de mentségére szóljon, hogy állítólag utána valahogy megoldotta.
Mondjuk sanszos, hogy azt is külső segítséggel. -
#2010
Sk8erPeter
nagyúr
retrox
#2005
Sk8erPeter
nagyúr
Látom ide is beírtad a kérdésedet... Felejtsd már el ezt az ütemezett életkor-update-elést, egyszerűen amikor kíváncsi vagy a felhasználó életkorára, számítsd ki a születési dátumából minden alkalommal, amikor megjeleníted, ez úgyis villámgyors, ne szenvedj már a totál megbízhatatlan ütemezéssel... (korrigálom magam: az ütemezés maga nem feltétlenül megbízhatatlan, de ha mégis kimarad valamilyen oknál fogva (pl. valaki kiszedi az ütemezett feladatok közül, épp volt egy áramkimaradás az ütemezés időpontjában, mittudomén stb.), akkor máris szar értéket jelenítesz meg, ahelyett, hogy a mindig naprakész automatikus kiszámítást végeznéd el)
Szerk.: még szerkesztési időn belül találtam erről szóló topicot: [link]
itt a kérdező nem tudom, mit szenved azzal a query-vel, mit gányolgat, de utána megmondja a megoldást, hogy valami usershortcodes.php fájlba kell tenni ezt a kódrészletet, gondolom neked megfelelően átalakítva, ha kell, nekem személy szerint fingom sincs, mi ez, soha nem használtam e107-et, és hacsak nem nagyon muszáj, nem is fogok.Szerk. 2.: van itt valami Birthday Menu is, ahol állítólag csak be kell pipálni egy checkboxot ("Show age"), és máris ott lesz neked az életkor... Akkor minek szórakozol saját megoldásokkal, ami rossz?
-
#1919
Sk8erPeter
nagyúr
cucka
#1918
Sk8erPeter
nagyúr
Ja persze, tudom, hogy nem kell vele foglalkozni, csak érdeklődtem a működése felől.
Sajnos jól gondoltam, MyISAM esetén a PDO felől sem működik a tranzakció plusz commit/rollback mechanizmus:
[Transactions and auto-commit]
"WarningPDO only checks for transaction capabilities on driver level. If certain runtime conditions mean that transactions are unavailable, PDO::beginTransaction() will still return TRUE without error if the database server accepts the request to start a transaction.
An example of this would be trying to use transactions on MyISAM tables on a MySQL database."
Kár.
Azt hiszem, nem érdemes emiatt megváltoztatnom InnoDB-re a jelenlegi adattábláim tárolási mechanizmusát, akkor viszont szívhatok azzal, hogy több új elem beillesztése esetén hiba fellépésekor megfelelően visszavonogassam szépen kézzel az INSERT-eket, utólag a megfelelő sorokra küldve egy DELETE-et...
Tulajdonképpen azt sem látom be, mi értelme van, hogy csupán driverszinten ellenőrzi a tranzakciós képességeket, miért nem ugat érte (legalább lenne notice, warning vagy PDOException), ha az adattábla nem támogatja őket, hogy a programozó ne nézzen már bambán, hogy vajon a rollback-nél miért nem vonta vissza a kívánt módosításokat, amennyiben elvégezte...
Milyen szép is lenne egy DataSet alapúhoz hasonló megoldás, mint .NET-ben.
-
#1917
Sk8erPeter
nagyúr
cucka
#1916
Sk8erPeter
nagyúr
PazsitZ, cucka: köszönöm a válaszokat!
PazsitZ:
"Viszont, az innoDB támogat tranzakciókezelés, amire ha szükséged van, akkor szükséged van."
Na, most legalább egyben megtudtam azt is, hogy nem érdemes próbálkoznom MyISAM esetén PDO-val a PDO::beginTransaction(), illetve PDO::rollBack() (na meg PDO::commit()) metódusokkal. Pedig igencsak előnyös lenne, hogy amennyiben valami hiba lépett fel több bejegyzés létrehozási kísérlete során, vissza tudjam vonni egy sima rollBack-kel az egészet.
Eszerint MyISAM storage engine-nél ne is próbálkozzak ilyesmivel, ugye?Ja, közben ezt találtam a phpMyAdmin átlátható felületén, hogy két tárolómotor támogatja a transactiont MySQL-ben:
InnoDB Supports transactions, row-level locking, and foreign keys
BerkeleyDB Supports transactions and page-level lockingcucka:
"Az innoDB támogatást be kell kapcsolni a MySQL-ben, alapból ki van kapcsolva."
Köszönöm, közben megtaláltam a my.ini fájlban (Windows) a sort, amit ki kell kommentelni:
# Use this option if you have a MySQL server with InnoDB support enabled
# but you do not plan to use it. This will save memory and disk space
# and speed up some things.
skip-innodb
(nyilván az utsó sort)
Mondjuk ha azt mondjátok, ennek az előnyei csak "nagy forgalmú oldalnál és/vagy nagy méretű adatbázis tábláknál" értékelhetők igazán, akkor hagyom is a fenébe egyelőre, nem foglalkozom vele. De szóljatok, ha mégis érdemes.
(Amúgy MySQL-verzió: 5.0.51a.)"Igazából olyan nincs, hogy konkurrens írás, egyszerre csak 1 írási művelet végződik, a többiek pedig várnak a sorukra."
OK, világos. Csak úgy értettem, nem állhat-e elő mégis az az eset, aminek minimális az esélye, hogy két kérés esetén épp ugyanakkor próbálnak írni az adatbázisba, ezért a lock-olási folyamat megkergül - dehát mondjuk így is-úgy is gondolom az egyik akkor is előbb fogja tudni lezárni, hogy a másik ne tudja addig babrálni.
Ilyenkor van egy bizonyos timeout idő, amíg vár a sorára, majd amikor már nincs lock-olva a tábla, végrehajtja a feladatot, igaz? -
#1914
Sk8erPeter
nagyúr
cucka
#1912
Sk8erPeter
nagyúr
ha már szó volt róla, én is kérdezek, hogy tanuljak:
"a táblát innoDB engine-el tárold" - ez miért fontos igazából? Mitől jobb az InnoDB, mint mondjuk a MyISAM, stb.? Gyorsabb nála? Akkor miért nem ez a default? Érdekes, localhoston phpMyAdminban (2.10.3) nem is látom most az opciók közt ezt a lehetőséget...
"Új válasz felvitelénél pedig az innoDB miatt nem fogja lockolni a táblát, tehát zavaró mellékhatások nélkül lesz ideje újraszámolni az indexeket."
Mi történhet konkurrens írási kísérletnél? -
#1766
Sk8erPeter
nagyúr
vincent001
#1762
Sk8erPeter
nagyúr
válasz
vincent001
#1762
üzenetére
Nálam AppServ van fent, de korábban WampServer is volt, azzal sincs gond.
Amúgy a második hiba lehet azért, mert nincs benne a MySQL-könyvtár a környezeti változókban. De ezt elvileg az AppServ elintézi (bár úgy emlékeztem, a WampServer is, de akkor lehet, hogy nem).
Nem tudom, mi van az index.php-dben, az nyitja-e meg a webshopodhoz szükséges fájlokat, feltételezem, hogy igen (ha tényleg az ahhoz tartozó kezdőlapról van szó).(#1765): és már enged csatlakozni az adatbázishoz?
Nehéz így megmondani a hiba okát, hogy nem tudjuk, a szükséges fájl-e az az index.php. -
#1761
Sk8erPeter
nagyúr
vincent001
#1760
Sk8erPeter
nagyúr
válasz
vincent001
#1760
üzenetére
Ha tuti jól adtad meg az adatokat (odafigyelve, hogy pl. számíthat a kis- és nagybetű közötti eltérés), akkor egy elég fontos kérdés: telepítettél MySQL-szervert a saját gépedre is?
Apache önmagában nem elég!
Egy elég egyszerű teszt lehet pl. Windows alatt, hogy elindítod a parancssort (Start - Futtatás - cmd ), majd beírod, hogy mysql, és Enter, ha nincs hiba, elindul a MySQL-parancssor, akkor okés, jól működik a szerver.Ha biztosan telepítetted a MySQL-szervert, akkor hibaüzenet alapján elvileg a következők közül nem stimmel valami:
define('_DB_SERVER_', 'localhost');
define('_DB_USER_', '**********');
define('_DB_PASSWD_', '*******');Nézd át, hogy biztos jók-e ezek az adatok.
Ezenkívül figyelj rá, hogy eltérhet a localhoston (a saját gépeden) a jelszó-felhasználónév páros, attól függően, mit állítottál be.Látszik, hogy a PrestaShop MySQL-osztálya akkor jelzi ezt a hibaüzenetet, amikor a fentiekben található hiba miatt nem tud csatlakozni a MySQL szerverhez.
if ($this->_link = @mysql_connect($this->_server, $this->_user, $this->_password))
{
if(!$this->set_db($this->_database))
die(Tools::displayError('The database selection cannot be made.'));
}
else
die(Tools::displayError('Link to database cannot be established.')); -
#1759
Sk8erPeter
nagyúr
vincent001
#1758
Sk8erPeter
nagyúr
válasz
vincent001
#1758
üzenetére
Soha nem használtam még ezt, de miért nem a telepítési útmutató szerint csinálod? OLVASD EL EZT.
Igazából nem is értem, minek turkálsz a config-fájlokban, amikor pont ennek elkerülésére való a felhasználóbarát telepítős módszer.
Látom máshol is feltetted a kérdést...
(grat.) -
#1757
Sk8erPeter
nagyúr
vincent001
#1756
Sk8erPeter
nagyúr
válasz
vincent001
#1756
üzenetére
Hogyan próbálsz csatlakozni az adatbázishoz?
Megfelelő a jelszó-felhasználónév párosítás?
A kódod hogy néz ki (persze kivéve a jelszót és felhasználónevet, az nem érdekel)? -
#1755
Sk8erPeter
nagyúr
Speeedfire
#1752
Sk8erPeter
nagyúr
válasz
Speeedfire
#1752
üzenetére
cucka nyilván arra céloz, hogy az elegáns megoldás az, ha a nyers szöveges változatban keresel (igazából pont ezt mondta), nem a HTML-tagekkel teli szövegben - mondok egy nem is annyira elrugaszkodott példát:
tegyük fel, hogy a ckeditor szerkesztője egy adott stílusú szöveget úgy formáz, hogy hozzáteszi a "text" nevű osztályt - pl. beírod a szövegedet (legyen az, hogy 'blabla'), majd megformázod ckeditorral, és tételezzük fel, hogy így fog kinézni eredményként a ckeditor HTML-kódja:
<p class="text">blabla</p>Mit csinálsz akkor, ha valaki rákeres éppen a "text" szóra? A keresőd az adatbázisban megtalálja ezt a karaktersorozatot, még ha az csak a HTML-tagek között is van, és a felhasználó csak néz, hogy miért is jött ki ez a találat, amikor ott csak a 'blabla' karaktersorozat van...
Remélem így már világos, miért okozhat ez problémát. -
#1669
Sk8erPeter
nagyúr
Speeedfire
#1668
Sk8erPeter
nagyúr
válasz
Speeedfire
#1668
üzenetére
Nincs mit!
-
#1667
Sk8erPeter
nagyúr
Speeedfire
#1666
Sk8erPeter
nagyúr
válasz
Speeedfire
#1666
üzenetére
Ezek szerint félreérted.
Van egy lekérdezésed, amit lefuttatsz a MySQL-ben. Annak az eredménye az adattábládnak valahány (esetleg 0 vagy egyetlen vagy több) sora. A sorban ugye vannak oszlopok, nálad jelen esetben többek közt az 'id' és a 'sorszam' nevű mezők.
Ha végrehajtod a lekérdezést, és egyetlen sort ad eredményül, akkor 1 eredménye van a lekérdezésednek, épp az az 1 sor. Ha több, akkor már nem jó a kódod, mert akkor minden cikluslépésnél felülírogatja a korábbi $katid és $fid változókat. Kérdés, mi a célod és mi a kívánt eredmény.Gondolom a lekérdezésednek egyetlen eredménye van, tehát
a következő HELYETT:
while($row2 = mysql_fetch_assoc($tabla)) {
$fid = $row2['id'];
$katid = $row2['sorszam'];
}legyen inkább ez:
$row2 = mysql_fetch_assoc($tabla);
$fid = $row2['id'];
$katid = $row2['sorszam']; -
#1665
Sk8erPeter
nagyúr
Speeedfire
#1664
Sk8erPeter
nagyúr
válasz
Speeedfire
#1664
üzenetére
Én ebben csak azt nem értem (nem olvastam vissza, de ettől függetlenül), hogy mi értelme van while ciklussal végigmenni a lekérdezés eredményén, és minden egyes cikluslépésben felülírogatni az $fid és $katid változókat, amit aztán később felhasználsz... Ha több, a lekérdezés eredményének megfelelő sor is van a táblában, akkor így nem tudod, hogy épp melyik azonosítókat érted el - ha meg csak egyetlen ilyen megfelelő sornak szabad lennie, akkor minek a while?
-
#1633
Sk8erPeter
nagyúr
sonar
#1632
-
#1621
Sk8erPeter
nagyúr
csongiclio
#1620
Sk8erPeter
nagyúr
válasz
csongiclio
#1620
üzenetére
Van pl. egy index.php kezdőlapod, és úgy adod meg a címet+nyelvet, hogy
http://www.ezazoldalad.hu/index.php?lang=hu
vagy csak simán
http://www.ezazoldalad.hu/?lang=huAztán attól függően include-olod a különböző nyelvű fájlokat, hogy mi van a lang mögött (pl. lang=hu, ha magyar vagy lang=en, ha angol [persze ízlésed szerint lehet akár nyelv=magyar és nyelv=angol is, ahogy érzed, de előbbi elegánsabb, többen értik
] )Valahogy így:
<?php
$langs=array( 'hu', 'en' );
if( !emtpy($_GET['lang']) && in_array($_GET['lang'], $langs) )
{
switch($_GET['lang']){
case 'hu': include('lap_magyar.html'); break;
case 'en': include('lap_angol.html'); break;
}
}
?>VAGY még egyszerűbb, ha pl. úgy vannak elnevezve a doksijaid, hogy "lap_hu.html", "lap_en.html", stb., és akkor így is lehet:
<?php
if( !emtpy($_GET['lang']) && in_array($_GET['lang'], $langs) ){
include('lap_' .$_GET['lang']. '.html');
}
?>És akkor persze ezt még lehet tovább kombinálni, különböző menüpontokra is. Még sok megoldás is létezik, ez két lehetséges az egyszerűek közül.
-
#1612
Sk8erPeter
nagyúr
KaiotEch
#1611
Sk8erPeter
nagyúr
válasz
KaiotEch
#1611
üzenetére
Az alábbi helyett:
SELECT COUNT(*) FROM legion_members
legyen így:
SELECT COUNT(*) AS legion_sum FROM legion_membersPl.:
$legion_members_sum=mysql_query("SELECT * FROM legions ORDER BY level ASC");
if( !$legions_sum ){
echo "Hiba történt az adatbázis lekérése során! <br />Hiba: ". mysql_errno() . "\n\r" .mysql_error()."<br />";
}
else{
$sum = mysql_fetch_assoc($legion_members_sum); //tagok száma
}Ezután azt, hogy hányan vannak, a $sum['legion_sum'] változó használatával tudod kiíratni.
"első <td>-be írja hogy hogy az adott légiónak hány tagja van, 2. <td>-be a nevét"
A légió adott tagjának a nevét szeretnéd kiíratni a második oszlopba? És az első oszlopba minden alkalommal kiíratnád, hány tagja van a légiónak? Kicsit egyértelműbben légyszi.
Az eddig világos, hogy van egy "level" és egy "name" nevű mező a MySQL-táblában.Ja, és használd a "Programkód" gombot. Jelöld ki a forráskódodat, és katt a Programkód gombra. Sokkal áttekinthetőbb lesz a kódod tőle.
no para, gondoltam, hogy csak véletlenül mellément 
Mondjuk sanszos, hogy azt is külső segítséggel.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Aktív témák
Hirdetés
- Cooler Master CK550 RGB mechanikus (barna switch/magyar kiosztás)
- Újszerű Meta Quest 3 (128gb), 1 év garanciával +kiegészítőkkel
- Asus Prime B560M-K + i5 1500 + be quiet! + 32 Gb Patriot Viper 3.200 Mhz Beszámitok!
- Eladó Konfig Ryzen 7 7700 32GB DDR5 1TB SSD RX6800XT 16GB!
- 5700x / B550i ITX Aorus / 32GB HyperX / Lianli vízhűtés /1000 SFX-L corsair táp/ 1TB nvme
- Telefon felváráslás!! Samsung Galaxy S22/Samsung Galaxy S22+/Samsung Galaxy S22 Ultra
- Telefon felvásárlás!! Samsung Galaxy A70/Samsung Galaxy A71/Samsung Galaxy A72
- Telefon felvásárlás!! Huawei P20 Lite/Huawei P20/Huawei P30 Lite/Huawei P30/Huawei P30 Pro
- Bomba ár! Lenovo ThinkPad T490 - i5-8GEN I 16GB I 256GB SSD I 14" FHD I Cam I W10 I Garancia!
- 121 - Lenovo Legion Pro 5 (16ARX8) - AMD Ryzen 7 7745HX, RTX 4070 (48 hónap garancia!)
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: PC Trade Systems Kft.
Város: Szeged