- Karácsonyfaként világíthat a Thermaltake új CPU-hűtője
- Az USA vizsgálja a RISC-V kínai terjedésének kockázatát
- Kicsit extrémre sikerült a Hyte belépője a készre szerelt vízhűtések világába
- Egészen nagy teljesítményspektrumon fedné le a mobil piacot az AMD
- Kihívás a középkategóriában: teszten a Radeon RX 7600 XT
- AMD Ryzen 9 / 7 / 5 7***(X) "Zen 4" (AM5)
- Milyen alaplapot vegyek?
- OLED TV topic
- NVIDIA GeForce RTX 3080 / 3090 / Ti (GA102)
- Gaming notebook topik
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Projektor topic
- Milyen CPU léghűtést vegyek?
- Kormányok / autós szimulátorok topicja
- Házimozi haladó szinten
Hirdetés
-
Súlyos adatvédelmi botrányba kerülhet a ChatGPT az EU-ban
it Egyre nagyobb probléma az AI hallucinálása – most az osztrák adatvédelmi hatóság veheti elő a ChatGPT miatt az OpenAI-t, alapvetően a GDPR megsértése miatt.
-
Karácsonyfaként világíthat a Thermaltake új CPU-hűtője
ph Az ASTRIA 600 ARGB ráadásul a hűtési teljesítmény szempontjából sem szégyenkezhet.
-
Samsung Univerzum: Így ismerhető meg a Galaxy AI bármilyen telefonon
ma A Try Galaxy webalkalmazás kontrollált környezetben mutatja meg, mit tud a One UI 6.1-es rendszer és a mesterséges intelligencia.
Új hozzászólás Aktív témák
-
JohnD
tag
Helló! Wampserver 3.2.0-t használva a következő probléma adódik: php-ből mysql parancsokkal csatlakoznék a mysql szerverhez, de a mariadb-hez csatlakozik, a phpmyadminban a mariadb alatt létrehozott adatbázishoz csatlakozik, az az alatti táblát tudom csak lekérdezni. Mi lehet a gond? Vmi konfigurációs probléma szerintem. Köszi a segítséget!
-
mlaci01
tag
Sziasztok,
Hátha tud valaki segíteni.
Van két táblám:
T1: T1m1,T1m2,T1m3,T1m4,T1m5,T1m6,T1m7,T1m8
T2: T2m1,T2m7,T2m8
INSERT csak a T1 táblára van annak mikéntjére nincs ráhatásom.
Szeretném INSERT-kor ha a (T1m7+T1m8) megtalálható a (T2m7+T2m8)-ban,
akkor a T2m1 mező értéke automatikusan beíródna a T1m6-ba.
Remélem érthetően fogalmaztam.
Előre is köszönöm a segítséget.
L, -
JohnD
tag
válasz Ivy.4.Ever #2104 üzenetére
Jó, azóta meglett már, köszi!
-
Panhard
tag
Sziasztok! Adatbázisban szeretnék utólag legenerálni egy új oszlopba, soronként unixtime-ot, meglévő dátum és idő mezőkből.
Addig megvan a kód, hogy fix dátum, idő értékből megcsinálja, de hogy tudom a dátum és idő helyére beírni a dátum és idő mezők értékeit?UPDATE database SET timestamp = UNIX_TIMESTAMP('2020-09-19 16:00:00') where sorszam < 100
-
Atomantiii
őstag
Arra van ötlete valakinek, hogyan lehetne megoldani ékezetes problémát phpmyadminban a komment résznél?
Tehát sql-ben meg van írva a tábla szerkezete
CREATE TABLE IF NOT EXISTS `valami`.`valami` (
`oszlop1` int(10) unsigned NOT NULL AUTO_INCREMENT COMMENT 'ID',
`oszlop2` varchar(40) NOT NULL COMMENT 'Név',
stb
CURRENT_TIMESTAMP COMMENT 'Módosítás időpontja',
PRIMARY KEY (`oszlop1`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 AUTO_INCREMENT=35 ;Ha megnézem az adott táblát phpmyadmin alatt, akkor az ékezetes karakterek helyett más jelenik meg a komment sorban, pedig phpmyadminban a kiszolgáló karakterkódolása: UTF-8 Unicode (utf8)-ra van állítva.
[ Szerkesztve ]
-
Ivy.4.Ever
őstag
válasz Atomantiii #2109 üzenetére
Nekem sima utf8-at nem ismer a MariaDB. Vagy használd a COLLATE szót is. Ilyen van hogy utf8mb4_general_ci pl azon belül. Egyébként az mb4-eseket ajánlott használni ha már utf8. Gyakori probléma forrás.
[ Szerkesztve ]
-
Atomantiii
őstag
válasz Ivy.4.Ever #2110 üzenetére
Köszi, sajnos nem szereti. Beírtam így:
DEFAULT CHARSET=utf8 COLLATE=utf8mb4_general_ci-ként beírtam, azt mondja rá, hogy COLLATION 'utf8mb4_general_ci' is not valid for CHARACTER SET 'utf8'
Van amit elfogad, de azok meg nem ismerik ugyanúgy a magyar karaktereket.
-
nevemfel
senior tag
válasz Atomantiii #2111 üzenetére
Az összes utf8mb4 kezdetű sorrendezés az utf8mb4 karakterkiosztáshoz tartozik. A te esetedben ez:
DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci
Egyébként ahogy olvasom, a
utf8mb4_general_ci
heylett jobb azutf8mb4_unicode_ci
Forget your troubles, c'mon get happy
-
nevemfel
senior tag
válasz Atomantiii #2113 üzenetére
Nem ismerem a phpmyadmin-t, de valahogy nyilván abban is be kell állítani a charsetet és a collationt is.
Ja nem, ez más. A webszervert kell beállítani, hogy a standard fejlécbe ne tegyen content-type charset beállítást is.
[ Szerkesztve ]
Forget your troubles, c'mon get happy
-
instantwater
addikt
válasz Atomantiii #2113 üzenetére
Nézd meg terminálban vagy valami desktop klienssel.
Ha ott jó, akkor a PHPMYADMIN karakterkódolása a rossz.
Nézd meg a HTML és HTTP headert is, mindkét helyen UTF8nak kell szerepelni.[ Szerkesztve ]
-
Agostino
addikt
válasz Atomantiii #2116 üzenetére
ALTER TABLE parancs nem kellene? emlékeim szerint pusztán a DB charset állítása nem húzza be TABLE-ben is a változtatást. de lehet rosszul emlékszem. megnézném azért a tábla mit csinál...
[ Szerkesztve ]
hey friend listen, i know the world is scary right now but its gonna get way worse
-
Atomantiii
őstag
válasz Atomantiii #2118 üzenetére
Kezdem feladni...
Ha sql-ből csinálok egy új táblát phpmyadminba egy már létezőbe beszútrva, akkor azt megcsinálja szépen, csak az ékezetes karakterek nem jelennek meg normálisan a komment részben az oszlop fejlécében.
Ha van egy másik táblám aminél jók phpmyadminban a komment résznél az ékezetek és úgy ahogy van átmásoltatom sql-ben egy másik táblaként, akkor ugyanúgy rosszak lesznek a komment részben a karakterek.
Ha az elrontott ékezetes betűket átírom phpmyadminban, utána szépen megjelennek az ékezetes karakterek ott is. Most már nem értem mi lehet a baja, miért nem jó ha sql-ből hozom létre.
[ Szerkesztve ]
-
Ivy.4.Ever
őstag
válasz Atomantiii #2119 üzenetére
Megnézted pl. Mysql Workbenchben?
-
Atomantiii
őstag
válasz Ivy.4.Ever #2120 üzenetére
Ugyanaz a helyzet MySql Workbenchben is, mint phpmyadminban. Ha sql-ként hozom létre nem jó, ha átírom utána jó lesz.
-
SunyaMacs
aktív tag
válasz Atomantiii #2121 üzenetére
Az SQL queryt milyen környezetből / honnan futtatod? Pl. ha cmd-ből, akkor lehet, hogy régebbi Windowson az nem utf-8 módban van, vagy a csatlakozásnál valamilyen ok miatt nem utf8mb4 a charset az, amit a kliens használ és külön be kell állítani a
--default-character-set
paraméterrel. -
SunyaMacs
aktív tag
válasz Atomantiii #2123 üzenetére
Igen, oda, ahol meghívja az exe fájlt és oda utána írva paraméterként.
-
Atomantiii
őstag
válasz SunyaMacs #2124 üzenetére
Most így van benne:
SET MYSQLEXE="c:\Program Files\MySQL\MySQL Workbench 8.0 CE\mysql.exe"
SET MYSQLDUMPEXE="c:\Program Files\MySQL\MySQL Workbench 8.0 CE\mysqldump.exe"Viszont akárhogy próbálom nem akarja elfogadni, hogy lefusson hiba nélkül. Bár biztos én bénázok.
Illetve utána így mondja meg neki, hogy melyik adatbázissal és felhasználóval csinálja meg.
SET MYSQL=%MYSQLEXE% -h adatbázis név -u felhasználónév -pjelszó
[ Szerkesztve ]
-
Atomantiii
őstag
Most nézem, hogy elvileg a cmd kódlapját is lehet állítani, most 852-esen (OEM - latin II)-őn van. De annak jónak kellene lennie, mert abban benne vannak a magyar karakterek.
[ Szerkesztve ]
-
SunyaMacs
aktív tag
válasz Atomantiii #2126 üzenetére
Én a biztonság kedvéért a batch script elején a cmd kódlapját 65001-re állítanám, hogy egyezzen. A --default-character-set=utf8mb4 paramétert a #2125 hsz-ed utolsó sora szerinti kódhoz írnám a jelszó után, úgy remélhetőleg nem kéne hibát dobnia.
-
SunyaMacs
aktív tag
válasz Atomantiii #2128 üzenetére
Örülök, hogy megoldódott
Régebben a logout-on volt egy kisebb fanyalgásom a témáról, lehet érdekes lesz számodra. -
Hege1234
addikt
Sziasztok!
a etl database browser-be megoldható valahogy a limit eltörlése vagy megnövelése?
most alapból 1000-en van
vagy a mysql workbench-nél van esetleg egyszerűbb és tudja a limit állítást? -
sonar
addikt
válasz Hege1234 #2130 üzenetére
Workbenchnél ott a legördülő menü, ahol lehet variálni a limiteket. De ahogy nézem ennél az ETL-nél is ott a lehetőség, jobbra fent. Szerintem ha 0-ra állitod akkor nem lesz limit a lekérdezésnél.
De azzal legyél tisztában, hogy ha nagy a tábla akkor egy fullos lekérdezés meg tudja akasztani az adatbázis szervert.A tudást mástól kapjuk, a siker a mi tehetségünk - Remember: Your life – Your choices!
-
Hege1234
addikt
működik köszönöm
elkerülte a figyelmem
esetleg azt hogyan tudom elérni hogy be is töltse a találatokat?
mert most engedi már görgetni de pár ezret azért hosszadalmas..
(20-30 at betölt és ahogy görgetek úgy tölti be folyamatosan)kodi adatbázisáról van szó
ami most még csak a gépemen fut
de tervezem hogy routerre teszem
ott tényleg nem lenne jó egyszerre mindent betölteni
köszi a fegyelmeztetést -
coco2
őstag
Sziasztok!
Használ valaki mysql ndb cluster-t mostanában? Üzemeltetési tapasztalatok / stabilitás érdekelne főleg, meg hogy a folyamatos frissítések mennyi hibával érkeznek hozzá?
Memory engine-t használok jelenleg, és a mysql doksik azt tanácsolják, érdemesebb átnézni az áttérés lehetőségeit, azért tettem fel a kérdést.
កុំភ្លេចប្រើភាសាអង់គ្លេសក្នុងបរិយាកាសអន្តរជាតិ។
-
Agostino
addikt
sziasztok
az egyik updatemet szeretném továbbfűzni és sejtem is, hogy mi a baja, miért nem fut le, de azért ha lehetséges és van megoldás, akkor élnék vele. a következőt kell elképzelni:
UPDATE rendeles SET
datum = CONCAT(datum,'01'),
mennyiseg = (
SELECT rendeles_mennyiseg
FROM rendelestabla1
WHERE rendeles_id1 = mrendeles_id
) WHERE mennyiseg IS NULL, /*ez tudom fölös*/mennyiseg = (
SELECT rendeles_mennyiseg
FROM rendelestabla2
WHERE rendeles_id2 = mrendeles_id
) WHERE mennyiseg IS NULL;egyetlen oszlopot kellene kétszer updatelnem de mindig csak azokat a sorokat, ahol a mennyiseg NULL, azért, hogy a már lefutott első updatet a második ne bántsa. tippre az a baja, hogy zárójelben lévő select utáni WHERE nem jön be neki. ha külön-külön lemegy a három UPDATE nincsen semmi gond, egyszerűen csak jó lenne, ha egyetlen menetben lefutna minden.
[ Szerkesztve ]
hey friend listen, i know the world is scary right now but its gonna get way worse
-
Agostino
addikt
válasz instantwater #2136 üzenetére
1064 syntax, azért kell kétszer mert - bár ezek csak kitalált táblanevek - mindkét tábla ugyan olyan adatokat tartalmaz, viszont ki kell egészítsék egymást. mert lehet, hogy az egyik táblában ugyan azon id-hez nincsen adat.
Ha nagyon minden kötél szakad 2 külön UPDATE utasításba lehetne szétszedni.
igen, ez van mosthey friend listen, i know the world is scary right now but its gonna get way worse
-
instantwater
addikt
válasz Agostino #2137 üzenetére
Mivel egy táblában egy mezőt updatelsz, esetleg meg lehet próbálni a 2 forrástáblát összekapcsolni UNIONnal vagy JOINnal, és azt átadninaz updatenek.
Mi a baj a 2 külön updatevel?
Az a baj, hogy látni kellene a valós neveket, célokat, és okokat.
Lehet, hogy te az updatet akarod megerőszakolni, de lehet, hogy a valóságban egy másik megközelítés lenne jobb. -
Panhard
tag
Sziasztok. Adatbázisban van egy oszlopom, ami DATETIME formátumú, így vannak benne az adatok: "2021-02-04 20:00:00". Én ebből az oszlopból mindig csak a dátumra kérdezek le így: CAST(DATETIME AS DATE).
Hogyan lehet indexelni ezt a dátumra történő lekérdezést? Ha az egész oszlopot indexelem, úgy nem jó, mert csak a dátumra kérdezek le, így az indexelés hatástalan. -
-
Panhard
tag
válasz instantwater #2140 üzenetére
"column BETWEEN dátum 00:00:00 AND dátum 23:59:59 ?"
ezt nem értem.Sajnos a tárhely szolgáltatóm nem használja a 8-as MySQL-t.
Vannak oszlopok is, amikben a dátum és idő van külön-külön, azokon az indexelés jól működik.
Gondoltam lecserélem őket egy datetime oszlopra. De akkor lehet marad ahogy van. -
Panhard
tag
válasz instantwater #2140 üzenetére
"column BETWEEN dátum 00:00:00 AND dátum 23:59:59 ?"
Így működik. Köszönöm!
-
instantwater
addikt
-
Panhard
tag
válasz instantwater #2144 üzenetére
SELECT * FROM tabla WHERE datetime between '".$_GET["datum"]." 00:00:00' and '".$_GET["datum"]." 23:59:59' ORDER BY datetime DESC
Így működik.Viszont lenne még egy kérdésem: Van pár tábla, ahol elég sok duplikált bejegyzés van a datetime oszlopban, és ezért nem engedi beállítani az indexet. Neten találtam pár megoldást a duplikált bejegyzések törlésére, de egyik sem működik. Erre tudsz valami működő megoldást?
-
instantwater
addikt
válasz Panhard #2145 üzenetére
Kérlek használj parameter bindinget, mert így sérülékeny a rendszer SQL injectionnel szemben.
Bármi SQL beküldhető a paraméterben és némi okoskodás után csúnya dolgokat lehet művelni.Sima indexet állíts be, ne unique indexet.
Egy időbélyeget nincs értelme unique indexbe tenni, hiszen egy adott pillanatban történhetett több minden amit el akarsz tárolni, és ha unique az index akkor hibát fogsz kapni.Korábban írtad, hogy a dátum meződ a primary key.
Erre van valami ok?
Primary key általában egy auto increment mező, az user email címe, uuid vagy hasonló szokott lenni. -
Panhard
tag
válasz instantwater #2146 üzenetére
ai, date, time oszlopok voltak az adatbázisban. Az ai volt az auto increment, csak a rendezés miatt kellett, más haszna nem volt. Ez a három oszlop helyett lett a datetime, a másik három majd törölve lesz.
A datetime mezőben soha nem lesz két egyforma adat. De ha mégis valamiért feltöltődne, a primary key index megakadályozza.
A datetime oszlop tartalmát a date és time oszlopokból generáltam. Csak az a baj, hogy 2018 előtt nem figyeltem arra, hogy ne töltődjön fel két egyforma adat, így most van egy pár táblázat, ahol kb: másfél millió sorból van átlagban 500 duplikált. Azokat kellen törölnöm. -
Dißnäëß
veterán
Sziasztok, mennyire MySQL ? MariaDB-ért köveztek ? Talán még nem nyílt nagyot az olló a kettô között.
Lá lá lá lá lááá lááá.. Lá lá lá lá lááá lááá .. Lá lá lá lá lááá lá lááá lá lá lá lááááá láááá
Új hozzászólás Aktív témák
- Autós topik látogatók beszélgetős, offolós topikja
- Politika
- Mibe tegyem a megtakarításaimat?
- Luck Dragon: Asszociációs játék. :)
- Otthoni hálózat és internet megosztás
- Szeged és környéke adok-veszek-beszélgetek
- Path of Exile (ARPG)
- Xbox tulajok OFF topicja
- AMD Ryzen 9 / 7 / 5 7***(X) "Zen 4" (AM5)
- Kodi és kiegészítői magyar nyelvű online tartalmakhoz (Linux, Windows)
- További aktív témák...
- BONTATLAN Új Iphone 15 PRO 128-512GB Független 1év Apple GARANCIA Deák Térnél Azonnal Átvehető.
- ÚJ Bontatlan Macbook Pro 16 M3 Pro MAX 14 30GPU 96GB 2TB Magyar billentyűzet Azonnal átvehető.
- 5% kedvezmény a Cammus szimulátor termékeihez.
- Krómozott előlapos Jura Z5 automata kávéfőző beépített profi cappuccino fejjel
- Eladó teljesen új, bontatlan Nespresso Essenza mini piros színben