Új hozzászólás Aktív témák
-
Lolek
aktív tag
Sziasztok,
egy működő sql server alatti gépet kell átnevzzek, ez milyen hatással lesz az SQL serverre?
Tudtok adni néhány tippet, hogy mire figyeljek oda?
KösziBéla
-
-
Joci93
senior tag
Az alábbi lekéredzéssel mi lehet a gond?
$onlinesearch = mysqli_query ($bd,
"SELECT * FROM users WHERE online = '1' AND key = '2' ") or die(mysqli_error($bd));Ezt a hibát adja ki rá:
"You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'key = '2')' at line 3"Furcsa, több ezer emberrel találkozunk és egyik sem fog meg igazán. Aztán megismerünk valakit, aki megváltoztatja az életünket. Örökre.
-
-
Joci93
senior tag
válasz bambano #2454 üzenetére
Megvan a probléma:
Valamiért a "key" nevet nem szerette igazán a MySQL. Átnevezve kulcs-ra már egyből működött.
Azért köszönöm a segítséget.Furcsa, több ezer emberrel találkozunk és egyik sem fog meg igazán. Aztán megismerünk valakit, aki megváltoztatja az életünket. Örökre.
-
Sk8erPeter
nagyúr
-
-
Sk8erPeter
nagyúr
válasz PumpkinSeed #2457 üzenetére
"Ilyen oszlop nevet nem szokás adni, hogy key."
Nincs ilyen íratlan és írott szabály. Bár jelen esetben ha a felhasználó azonosítójára gondolt a kérdező, akkor mondjuk tényleg hülyeség és indokolatlan a "key" név. Mondjuk ennél csak a magyar mezőnevek rosszabbak.Sk8erPeter
-
PumpkinSeed
addikt
válasz Sk8erPeter #2458 üzenetére
Nálunk Oracle-n ujjlevágással járt key meg ilyen oszlopnevek megadása, meg a column oszlopnév. Valami tervezési hiba lehet belőle vagy mit magyaráztak, bár baromság is.
[ Szerkesztve ]
"Akinek elég bátorsága és türelme van ahhoz, hogy egész életében a sötétségbe nézzen, elsőként fogja meglátni benne a fény felvillanását." - Kán
-
Sk8erPeter
nagyúr
válasz PumpkinSeed #2459 üzenetére
Igazad van egyébként, mert foglalt neveket nagyon nem illik megadni,pont azért,mert olyan problémák adódhatnak belőle, amilyeneket a kérdező említett (sikertelen query-k),ha nem használnak megfelelő "körítő" karaktereket, amikkel a problémák elkerülhetőek.
Sk8erPeter
-
Joci93
senior tag
válasz Sk8erPeter #2456 üzenetére
A * csak azért került bele, hogy az érintett oszlopokat ne lássátok
PumpkinSeed: A 'key' az egy random számot tárolt volna el, ami a belépéshez szükséges. (Biztonsági kulcshoz hasonló)
Furcsa, több ezer emberrel találkozunk és egyik sem fog meg igazán. Aztán megismerünk valakit, aki megváltoztatja az életünket. Örökre.
-
PumpkinSeed
addikt
MySQL InnoDB alatt akarok meghatározni idegen kulcsot:
ALTER TABLE location_log
ADD FOREIGN KEY (barcode)
REFERENCES products(barcode);#1005 - Can't create table '...' (errno: 150) (Részletek...)
A Részletek-re kattintva közli, hogy az InnoDB támogatja az idegen kulcsot...
"Akinek elég bátorsága és türelme van ahhoz, hogy egész életében a sötétségbe nézzen, elsőként fogja meglátni benne a fény felvillanását." - Kán
-
jocomen
aktív tag
válasz PumpkinSeed #2463 üzenetére
A `barcode` meg van határozva elsődleges kulcsként a `products` táblában?
[ Szerkesztve ]
-
jocomen
aktív tag
válasz PumpkinSeed #2465 üzenetére
Nem lehet, h a kódban a FK létrehozása előrébb van, mint a products tábláé (PK) ?
Egy eset ugyan ilyen hibakódra (1005 / 150):
LATEST FOREIGN KEY ERROR
------------------------
100509 20:59:49 Error in foreign key constraint of table foo/#sql-12c_4:
FOREIGN KEY (car_id) REFERENCES Cars (car_id):
Cannot find an index in the referenced table where the
referenced columns appear as the first columns, or column types
in the table and the referenced table do not match for constraint.
Note that the internal storage type of ENUM and SET changed in
tables created with >= InnoDB-4.1.12, and such columns in old tables
cannot be referenced by such columns in new tables.
See http://dev.mysql.com/doc/refman/5.1/en/innodb-foreign-key-constraints.html
for correct foreign key definition. -
PumpkinSeed
addikt
válasz jocomen #2466 üzenetére
Nem lehetséges, mert már kész táblákról van szó. Esetleg az, hogy a location_log tábla törölve volt, és újra létrehozva majd most, hogy változtatni akarok a recycle_bin (vagy mi van itt) beleszól a változtatásba?
"Akinek elég bátorsága és türelme van ahhoz, hogy egész életében a sötétségbe nézzen, elsőként fogja meglátni benne a fény felvillanását." - Kán
-
jocomen
aktív tag
válasz PumpkinSeed #2467 üzenetére
A recicle_bin nemtom micsoda.
Mivel "gyerek táblát" hozol létre, szerintem nem gond, h törölve volt.
Én valami elírásra gondolok, mivel szintaktikailag helyes. Esetleg nincs kiválasztva az adatbázis? USE database ... ;
Vagy nem abban a táblában állsz benne, amiben a FK-t akarod létrhozni (így már jártam).[ Szerkesztve ]
-
PumpkinSeed
addikt
válasz jocomen #2468 üzenetére
A törölt tábla kavart be, mert miután létrehoztam más néven engedte, furcsa is volt hogy valami ls234k23 ilyen típusú táblára akar hivatkozni.
"Akinek elég bátorsága és türelme van ahhoz, hogy egész életében a sötétségbe nézzen, elsőként fogja meglátni benne a fény felvillanását." - Kán
-
Agony
aktív tag
Sziasztok!
Szerintetek megvalósítható az alábbi elképzelés egy SQL lekérdezéssel?
Adott egy tábla ami tárolja a versenyekre a nevezéseket. Egy versenyre mondjuk beérkezik 30 nevezés, de egy versenyre ugyanaz az ember akár háromszor is jelentkezhet különböző lovakkal. Ez simán le is lehet kérdezni és megvan, hogy kik indulnak az adott versenyen/versenyszámban.
Viszont felmerült egy olyan igény, hogy szeretnék ha a nevezési listában több lóval induló személy nevezéseit a beérkezett nevezések között arányosan osztaná meg a lekérdezés, hogy legyen ideje átülni egy másik lóra.Tehát ha egy ember egy lóval indul teljesen mindegy hányadik a sorban, viszont ha egy ember 4 lóval megy, akkor úgy kellene listáznia a nevezéseket, hogy ez az ember legyen az első, a tizedik, a huszadik és a harmincadik induló a 30 nevezővel rendelkező versenyen.
A nevezésről most ezek az információk állnak rendelkezésre:
lovas varchar(100)
Lovas nevét tároljalo varchar(100)
A ló nevét tároljausername varchar(100)
A nevező felhasználót tárolja, hogy lekérdesse és módosíthassa a saját nevezéseit.egyesulet varchar(100)
A lovas egyesületének nevét tároljaedzo varchar(100)
Az edző nevét tároljaverseny varchar(100)
A verseny kódját tárolja ami a category táblával van kapcsolatban a verseny adataiért ha szükséges.versenyszam varchar(100)
A versenyszámot tárolja.nevezes datetime
A nevezés beérkezésének pontos idejét tárolja.id int(11) AUTO_INCREMENT
A beérkező nevezéseket sorszámozza.Előre is köszönöm az ötleteket!
Start with a whisper, end with a scream!
-
Apollo17hu
őstag
Erre egy komplett logikát kellene építeni.
Mi van akkor, ha ketten is 4 lóval indulnak? Akkor a másik a 2., a 11., a 21. és a hányadik(?) induló legyen a sorban? És mi legyen azokkal, akik 3 lóval indulnak? Mi van, ha valaki 8 lóval indul? Hogy kezelje le a közös többszörös eseteit? (2 lovasok vs. 4 lovasok vs. 8 lovasok vagy akár a 6 lovasok is ide kerülhetnek)
Analitikus függvények mentén kellene elindulnod...
-
Agony
aktív tag
válasz Apollo17hu #2471 üzenetére
Köszönöm a válaszokat!
Megoldható, mert láttam ilyet működés közben, de sajnos nem jöttem rá, mi alapján dobja szét a nevezéseket.
Egyébként úgy van ahogy írod Apollo, minden több lóval induló lovast a beérkezett nevezés mennyiségen arányosan szétoszt.Itt látható egy példa a startlista fülre kattintva. Az a lovas aki 3 lóval megy az elejére-közepére-végére van elhelyezve, akik pedig 2 lóval mennek azok az elejére és a végére.
Start with a whisper, end with a scream!
-
PumpkinSeed
addikt
Olyan kérdésem lenne, hogy van egy ilyen sorbeszúrásom:
INSERT INTO loclog (`barcode`, `date`, `where`, `to`)
VALUES ('".$switch_lok."', '".date('d/m/y H:i:s')."', 'Lok1', 'Lok2');és amit a barcode helyére kap, sokszor random időközönként 0-val helyettesíti az adatbázisban. Valami ilyesmi helyett: 5999486816777...
"Akinek elég bátorsága és türelme van ahhoz, hogy egész életében a sötétségbe nézzen, elsőként fogja meglátni benne a fény felvillanását." - Kán
-
rum-cajsz
őstag
válasz PumpkinSeed #2475 üzenetére
Na jó, de mi a kérdés?
Szerintem a $switch_lok változód nem kap értéket. Vagy esetleg érvénytelen értéket kap, hibás deklarálás miatt.=Kilroy was here============================ooO=*(_)*=Ooo=======
-
PumpkinSeed
addikt
válasz rum-cajsz #2476 üzenetére
Ja igen az lemaradt. Miért lehet ez? <- a kérdés.
A változót teszteltem. Minden adatbevitel előtt kiírattam a változó értékét és mindig helyes adat volt benne. Ezenkívül teljesen random időnként kap 0 értéket. Semmi logikát nem véltem felfedezni benne.
"Akinek elég bátorsága és türelme van ahhoz, hogy egész életében a sötétségbe nézzen, elsőként fogja meglátni benne a fény felvillanását." - Kán
-
martonx
veterán
válasz PumpkinSeed #2477 üzenetére
Most komolyan erre mit mondjunk? Vagy a kódódban van valami hiba, vagy a mysql-ed valami elavult verzió, ami ráadásul egy roncs instbil gépen fut. Vagy mindkettő. Nyilván normális esetben ez lehetetlen lenne.
Én egyébként ismerve a hszeidet, biztosra veszem, hogy a kódodban lesz a hiba, és nem a mysql-ben. De egy Pentium 3-ason futó MySql-től is kitelhet bármi.Én kérek elnézést!
-
PumpkinSeed
addikt
válasz martonx #2478 üzenetére
Ennyi a teljes kód:
$switch_lok = $_POST['lok_switch'];
{mysqli_query($database_connect,"INSERT INTO loclog (`barcode`, `date`, `where`, `to`) VALUES ('".$switch_lok."', '".date('d/m/y H:i:s')."', 'Lok1', 'Lok2');");}A kódot már szét teszteltem, mindenféleképpen kap értéket. A szervert viszont egyáltalán nem ismerem és lehetséges, hogy elavult valamilyen eszköz benne.
Verziószám: 3.5.5, utolsó stabil verzió: 4.2.5
[ Szerkesztve ]
"Akinek elég bátorsága és türelme van ahhoz, hogy egész életében a sötétségbe nézzen, elsőként fogja meglátni benne a fény felvillanását." - Kán
-
jocomen
aktív tag
válasz PumpkinSeed #2479 üzenetére
Tipp:
Cseréld le a barcode típusát int-ről bigint-re. Amilyen hosszú értéket kéne befogadjon, lehet, h néha túllépi a méretét.[ Szerkesztve ]
-
-
PumpkinSeed
addikt
-
jocomen
aktív tag
válasz PumpkinSeed #2483 üzenetére
Egyébként milyen típusúnak kell lennie? Ha szám, úgy rémlik nem kell macskaköröm.
[ Szerkesztve ]
-
Sk8erPeter
nagyúr
válasz PumpkinSeed #2479 üzenetére
Ez komolyan hihetetlen, már tudtommal legalább 1,5-2 éve foglalkozol webfejlesztéssel, hogyan lehetséges, hogy még mindig simán konkatenálod az adatbázis-query-ket? Miért nem használod azokat a rohadt nyomorult prepared statementeket? MySQLi-ben is vannak, PDO-ban is, mi akadályoz meg benne, hogy használd? Hogy valami rakás szar tutorialban nem azt a megoldást mutatták?
A PHP topicot is követed, még mindig nem tűnt fel, hogy aki ilyen módon gányol, az mindig megkapja, hogy ne ölje már halomra a kismacskákat?
Nem beszélve arról, hogy a $_POST-tömb tartalmát egyrészt közvetlenül, másrészt mindenféle ellenőrzés nélkül használod... Ha már kókányolsz össze-vissza, legalább ne ilyen durván. Csak hogy még fokozzuk az élvezeteket, még mindig csak Notepad++-ban kódolsz, "jó lesz az"-alapon?[ Szerkesztve ]
Sk8erPeter
-
martonx
veterán
válasz PumpkinSeed #2483 üzenetére
Hehe, így legyen 5-ösöm a lottón. Mondtam én, hogy a kódoddal lesz a hiba.
Én kérek elnézést!
-
sztanozs
veterán
válasz PumpkinSeed #2479 üzenetére
SQL Injection 4 Prezident
Sk8erPeter:
[ Szerkesztve ]
JOGI NYILATKOZAT: A bejegyzéseim és hozzászólásaim a személyes véleményemet tükrözik; ezek nem tekinthetők a munkáltatóm hivatalos állásfoglalásának...
-
-
jocomen
aktív tag
válasz Sk8erPeter #2489 üzenetére
Okozhat hibát, ha varchar-ként tárolja?
Nem tudom mi alapján számozzák, vagy h szoktak-e műveletet végezni vonalkódokkal, de pl számok összehasonlítása (gyártók, termék típusok keresése) okozhat-e hibát, vagy karakterként is ugyanaz lenne a sorrend <> összehasonlításnál, ... ?Mert ha később műveletet akar végeztetni vele (bár most eltűnt a hiba), okozhat még problémát az esetlegesen rosszul megválasztott adattípus, nem?
[ Szerkesztve ]
-
Sk8erPeter
nagyúr
válasz jocomen #2490 üzenetére
Hát ha pl. betűk és számok egyaránt előfordulnak a vonalkódban, akkor nyilván nem kéne integerként tárolni. Ha biztosan csak számok vannak benne, akkor miért is ne, teljesítmény-szempontból még jobb is lehet. A kollégától azért kérdeztem vissza, mert nem igazán értem, hogy jönnek ide a tizedesvesszők/-pontok, amikor egy vonalkódról beszélünk.
Sk8erPeter
-
válasz Sk8erPeter #2489 üzenetére
vonalkódot lebegőpontos adattípusban tárolni?
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
fordfairlane
veterán
válasz Sk8erPeter #2491 üzenetére
Ha biztosan csak számok vannak benne, akkor miért is ne, teljesítmény-szempontból még jobb is lehet.
Kivéve, ha nullával vagy nullákkal kezdődő számsorról van szó. Arra a decimal vagy numeric típus való, nem a különféle méretű integerek, és persze a lebegőpontos ábrázolásmódok sem.
x gon' give it to ya
-
válasz Sk8erPeter #2493 üzenetére
hol is kértem tőled segítséget?
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
Sk8erPeter
nagyúr
válasz fordfairlane #2494 üzenetére
Ez teljesen jogos. Bár ha nagyon akarom, és a vonalkód fix hosszú, akkor string paddinggel fel lehetne akár tölteni 0-kkal a kimaradókat balról, de minek.
Részemről a lebegőpontos ábrázolás szóba sem jött, ezzel bambano kezdett előhozakodni, bár nem értem még mindig, minek.
(#2495) bambano :
Hogy jött egyáltalán képbe a lebegőpontos ábrázolás? Pont erre kérdeztem rá, erre visszakérdezed ugyanazt... Kicsit érdekes irányt vett a beszélgetés, mintha némi skizofrénia került volna a képbe.Sk8erPeter
-
válasz Sk8erPeter #2496 üzenetére
nem én hozakodtam elő. lásd: "Észre se vettem eddig de most, hogy átraktam double-ről varchar-ra nincsenek random kinullázások."
az iróniadetektorod elemcserére szorul.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
fordfairlane
veterán
válasz Sk8erPeter #2496 üzenetére
Egyébként egyszerű a probléma: nem írta le, hogy a vonalkód milyen értékkészletű, és azt sem, hogy a DB séma milyen. Utólag megtudtuk, hogy double volt, de ezzel sem megyünk sokra, mert a varchar mindent elbír, tehát inkább csak elfedi a hibát, mint sem megoldja.
[ Szerkesztve ]
x gon' give it to ya
-
Sk8erPeter
nagyúr
válasz bambano #2497 üzenetére
Hopsz, na ez most tényleg az én hülyeségem volt, bevallom, a linkelt hsz. fölött átsiklottam. Nálam már korábban kiakadt a gányolásszenzor.
Szóval innen a félreértés, bocsánat.
Ez esetben már értem a felvetésedet is.(#2498) fordfairlane :
Na ja. Engem azért érdekelt volna, vajon akkor pontosan miért is nullázódtak ki az értékei, de úgy látszik, ezt már nem tudjuk meg.Sk8erPeter
-
sztanozs
veterán
válasz Sk8erPeter #2499 üzenetére
Pl, mert az olvasó beolvasott egy betűt (véletlenül vagy konfigurálási/olvasási hibából) a számsorba és a ezt 0-ra konvertálta az RDBMS.
JOGI NYILATKOZAT: A bejegyzéseim és hozzászólásaim a személyes véleményemet tükrözik; ezek nem tekinthetők a munkáltatóm hivatalos állásfoglalásának...
Új hozzászólás Aktív témák
- Politika
- Redmi Note 13 Pro 5G - nem százas, kétszázas!
- Samsung Galaxy S24 Ultra - ha működik, ne változtass!
- ASUS ROG Ally
- Tőzsde és gazdaság
- EAFC 24
- A személyre szabott reklám lehet a streaming következő slágere
- LEGO klub
- AMD APU (AM4 és AM5) topik
- AMD Ryzen 9 / 7 / 5 7***(X) "Zen 4" (AM5)
- További aktív témák...