Új hozzászólás Aktív témák

• #1940 fordfairlane veterán B.A.T. #1939

  Új Válasz 2017-08-05 13:56:35 #1940

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  fordfairlane

  veterán

  válasz B.A.T. #1939 üzenetére

  A Visual C++ 2013-as redistributable csomagot még kipróbálom, bár sztem ha 2015-el nem ment jó eséllyel ezzel se fog.

  Jó eséllyel menni fog a 2013-mal. Ezek a runtimeok nem felülről kompatibilisek, ezért is lehet belőlük több verziót feltelepíteni egymás mellé.

  Egyébként igazad van, a 6.3.9-től kezdve nincs 32 bites letölthető bináris:

  Changes in MySQL Workbench 6.3.9

  - Windows: Zip packages and 32-bit binaries are no longer published. The .NET Framework version 4.5 is now required.

• #1938 fordfairlane veterán B.A.T. #1936

  Új Válasz 2017-08-05 12:54:57 #1938

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  fordfairlane

  veterán

  válasz B.A.T. #1936 üzenetére

  Vagy rakd fel a Visual C++ 2013 redistributable csomagot [link], vagy használd a Mysql Workbench 6.3.9 változatát.

  2.3.1 Installing

  Requirements for Windows:
  - Microsoft .NET Framework 4.5
  - Microsoft Visual C++ 2015 Redistributable Package

  Note:
  The 2013 version was changed to 2015 with MySQL Workbench 6.3.9.

• #1886 fordfairlane veterán #50162688 #1884

  Új Válasz 2017-02-26 23:22:26 #1886

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  fordfairlane

  veterán

  válasz #50162688 #1884 üzenetére

  Telepítés után hozd létre kézzel ezt a plugin könyvtárat.

• #1865 fordfairlane veterán Headless #1864

  Új Válasz 2017-02-10 15:37:15 #1865

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  fordfairlane

  veterán

  válasz Headless #1864 üzenetére

  Ez egy szimpla Equi-join. Sem subselect, sem más nem kell.

  SELECT projekt.projekt_id, user.name FROM projekt, user WHERE projekt.user_id = user.id

• #1862 fordfairlane veterán kezdosql #1859

  Új Válasz 2017-01-31 14:16:56 #1862

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  fordfairlane

  veterán

  válasz kezdosql #1859 üzenetére

  InnoDB táblaformátumot kell használni, és akkor lesz tranzakciókezelés (meg sorszintű lock, foreign key constraint, stb..) Mysql és MariaDB kábé ugyanaz, egyik a másik forkja. Ezen a szinten lényeges különbség nincs a kettő közt.

• #1759 fordfairlane veterán martonx #1758

  Új Válasz 2015-11-23 15:49:48 #1759

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  fordfairlane

  veterán

  válasz martonx #1758 üzenetére

  Elképzelhető, hogy MySQL-en kívül máshol nem nagyon van ilyen. Én sem használtam még soha. Oracle alatt lehet csinálni felsorolás - CHECK CONSTRAINT-t egy adott mezőre.

• #1756 fordfairlane veterán martonx #1755

  Új Válasz 2015-11-23 11:59:34 #1756

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  fordfairlane

  veterán

  válasz martonx #1755 üzenetére

  Szerintem a SET mezőtípusra gondol. [link], [link]

• #1722 fordfairlane veterán TomyLeeBoy #1721

  Új Válasz 2015-05-31 12:23:22 #1722

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  fordfairlane

  veterán

  válasz TomyLeeBoy #1721 üzenetére

  A / max regexp patterdefinícióknál okozhat gondot, sehol máshol. Elég elcseszett sztringkezelés lehetett abban a scriptben.

• #1710 fordfairlane veterán Apollo17hu #1707

  Új Válasz 2015-05-29 12:26:52 #1710

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  fordfairlane

  veterán

  válasz Apollo17hu #1707 üzenetére

  MySQL tud analitikus függvényeket?

  Tudomásom szerint egyiket sem ismeri.

• #1626 fordfairlane veterán Czimby #1625

  Új Válasz 2015-02-04 19:36:24 #1626

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  fordfairlane

  veterán

  válasz Czimby #1625 üzenetére

  Itt a lista a különféle oprendszerekről:

  [link]

  Úgy rémlik, hogy Oracle fiók kell a letöltéshez.

• #1550 fordfairlane veterán Kommy #1549

  Új Válasz 2014-08-31 14:45:52 #1550

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  fordfairlane

  veterán

  válasz Kommy #1549 üzenetére

  fordfairlane: há ebből a leírásból nem jöttem rá, hogy fognak a felhasználói adatai átkerülni a phpbb-ből az SLS-be.

  Én sem, ez a doksi elég szegényesnek tűnik, de biztos vannak példák máshol a weben. Egyelőre több időm nincs ezzel foglalkozni.

• #1548 fordfairlane veterán Kommy #1545

  Új Válasz 2014-08-31 13:12:22 #1548

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  fordfairlane

  veterán

  válasz Kommy #1545 üzenetére

  A phpBB-nek van API-ja, amin keresztül autentikálható a felhasználó:

  [link]

  Ez a tiszta megoldás, nem a phpBB tábláihoz való közvetlen hozzáférés.

• #1477 fordfairlane veterán Zedz #1476

  Új Válasz 2013-10-28 16:02:25 #1477

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  fordfairlane

  veterán

  válasz Zedz #1476 üzenetére

  A táblanév.mezőnév valamiért nem csípi a `` jelet.

  Így csípi:

  `táblanév`.`mezőnév`

• #1465 fordfairlane veterán Jim-Y #1464

  Új Válasz 2013-09-17 10:39:01 #1465

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  fordfairlane

  veterán

  válasz Jim-Y #1464 üzenetére

  Akkor a dátum mezőt UNIQUE-re kell állítani, és lehet használni az INSERT IGNORE vagy REPLACE-t.

• #1463 fordfairlane veterán Jim-Y #1461

  Új Válasz 2013-09-17 10:33:59 #1463

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  fordfairlane

  veterán

  válasz Jim-Y #1461 üzenetére

  INSERT IGNORE INTO tabla ...

  ezzel próbálkoztam, de nem jó, beszúr egy újabb sort, nyílván más id-vel, de a többi ugyanaz

  Ha van egy inkrementálódó kulcsmező, akkor, ahogy elnézem, nincs kulcsérték megadva, anélkül pedig nem fog működni.

• #1453 fordfairlane veterán

  Új Válasz 2013-08-29 11:49:49 #1453

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  fordfairlane

  veterán

  Egyébként pont erre való az EXPLAIN, query-optimalizálásra.

  [link]

• #1452 fordfairlane veterán martonx #1451

  Új Válasz 2013-08-29 11:39:37 #1452

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  fordfairlane

  veterán

  válasz martonx #1451 üzenetére

  Gondolom volt index, csak az adott lekérdezéshez használhatatlan volt a lekérdező számára.

• #1449 fordfairlane veterán martonx #1446

  Új Válasz 2013-08-29 10:38:42 #1449

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  fordfairlane

  veterán

  válasz martonx #1446 üzenetére

  Indexelés nélkül a nem kulcs mezőkön, nem gyorsítótárazott forráson a keresés-rendezés full table scant igényel, így nem csoda.

• #1437 fordfairlane veterán GG888 #1436

  Új Válasz 2013-08-21 16:20:46 #1437

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  fordfairlane

  veterán

  válasz GG888 #1436 üzenetére

  A LIKE helyett használhatsz reguláris kifejezéseket.

  [link]

• #1435 fordfairlane veterán biker #1434

  Új Válasz 2013-08-21 16:07:09 #1435

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  fordfairlane

  veterán

  válasz biker #1434 üzenetére

  Amikor szóvátették az adatszerkezet problémáit, nem arra hivatkoztál, hogy nem éri meg vele foglalkoznod, hanem hogy akkor redundáns lesz, meg lassítja a lekérdezést, és ehhez hasonlók. Márpedig ezek fals indokok, mert nem attól lesz redundáns az adatbázis, ha a relációkat a megfelelő elvek mentén feldarabolod, hanem attól, ha egyben tárolsz nem egybe tartozó adatmezőket. Ez abszolute szakmai dolog, szakmai téma, és te szakmai alapon kérdőjelezted meg a jogosságát.

  Az igaz, hogy az nem igazán jó érv, hogy így "nem szép", meg hogy "nem eléggé tankönyvszerű", én ezért is próbáltam gyakorlatiasabban megközelíteni a témát, de a te indokaid pl. a sebességre vagy a lekérdezés bonyolultságára sem igazán állják meg a helyüket.

• #1433 fordfairlane veterán Sk8erPeter #1432

  Új Válasz 2013-08-21 15:36:57 #1433

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  fordfairlane

  veterán

  válasz Sk8erPeter #1432 üzenetére

  Utólag refaktorálható az adatszerkezet. Egyébként az ilyen függőséget nem kell feltétlenül tankönyvszerűen kezelni. Ha nincs túl sok mező, amit érint a dolog, a NULL használata is korrekt megoldás.

• #1431 fordfairlane veterán Sk8erPeter #1428

  Új Válasz 2013-08-21 15:11:22 #1431

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  fordfairlane

  veterán

  válasz Sk8erPeter #1428 üzenetére

  A lényeg: az akciós és aktuális árnak, aktuális szállítónak és egyebeknek semmi keresnivalójuk ugyanabban a táblában, amiben a termékek alapvető, ritkán változó paramétereit tárolod.

  Ha ez a tranzitív függőség bennmarad, az még nem olyan nagy tragédia ( 3NF helyett csak 2NF ).

• #1427 fordfairlane veterán biker #1425

  Új Válasz 2013-08-21 11:22:10 #1427

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  fordfairlane

  veterán

  válasz biker #1425 üzenetére

  Igazad van, nem jó példa. Ágyúval verébre. Ez inkább egy-egy feltételes kapcsolat lehet a legtöbb esetben, vagyis hogy a termékek egy része akciós, a többi nem. Mondjuk ebben az esetben is külön táblába tenném az akcióparamétereket, mert már megszoktam, hogy a "dolgokat", amiknek önálló attribútumai vannak (kezdet - vége), önálló objektumoként kezelem, még akkor is, ha csak egy kapcsolódó rekord lehet egy termékhez. Aztán valami ORM könyvtár elvégzi a betöltést-mentést-rekordösszefűzést.

• #1424 fordfairlane veterán biker #1422

  Új Válasz 2013-08-21 11:11:48 #1424

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  fordfairlane

  veterán

  válasz biker #1422 üzenetére

  Egyébként nem arra akartam helyezni a hangsúlyt, hogy az üzletpolitika mit kíván meg, hanem hogy melyik a rugalmasabb adatszerkezet. Ez egyébként nagyon régi technika. A relációs adatbázisok, és a különféle normálformák használata nem épp mai találmány.

• #1423 fordfairlane veterán biker #1422

  Új Válasz 2013-08-21 11:05:07 #1423

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  fordfairlane

  veterán

  válasz biker #1422 üzenetére

  Mert nalunk ugy megy, hogy kitalaljuk melyik termekunk mettol meddig akcios, nem pedig kitalaljuk holnap valami akcios lesz, de nem tudom mi

  Máshol meg másként megy. Minnél nagyobb a kereskedelmi egység, annál inkább jellemnző, hogy az akciózás termékcsoportosító módon kerül kivitelezésre. Például úgy, hogy nem egy termék lesz akciós, hanem egy termékek csoportja. Majd ebbe az akcióba bevonódhat újabb termék. Aztán az akció meghosszabbodhat. Aztán kerül bele újabb termék. Aztán kikerülhet belőle bizonyos termék, mert pl. elfogy. Aztán kiderülhet, hogy túl jól sikerült az akció, ezért az összes termékre csökkenteni kell a mértékét. Vagy épp ellenkezőleg, nem sikerült túl jól, sok termék továbbra is készleten, megromlik pl. ezért növelni kell a kedvezményt az összes terméken.

• #1421 fordfairlane veterán biker #1419

  Új Válasz 2013-08-21 00:14:23 #1421

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  fordfairlane

  veterán

  válasz biker #1419 üzenetére

  Itt az az alap tézis részetekről, csak rossz lehet mert sok oszlopa van

  Nem az oszlopok számával önmagával van a probléma, hanem azzal a fajta adatszerkezettel, amivel letárolásra kerülnek a termékhez kapcsolódó adatok.

  Jelen példa esetében a termékhez kapcsolódik egy akció, aminek vannak attribútumai, például kezdeti-, és végidőpontja. Ezt tranzitív függésnek hívják, és a probléma nem az, hogy egyben van, mert lekérdezés szempontjából ez az adatszerkezet kvázi "kész" van, csak ki kell íratni a mezőket, amire épp szükség van

  A probléma a következők lehetnek:

  1. beszúrási anomália

  Addig nem tudsz létrehozni akciót, amíg nincs készen felvíve legalább egy termék, amihez hozzácsatolod.

  2. módosítási anomália

  Az akciók paramétereit az összes termékrekordon egyszerre kell végrehajtanod, különben inkonzisztens lesz az adatbázis (új akció keletkezik a semmiből, ha valami probléma folytán nem hajtódik végre minden termék rekordján a módosítás)

  3. törlési anomália

  Ha törölsz minden terméket, akkor az akció is törlődik magától. (Mellékhatás, amit ebben az adatszerkezetben nem tudsz megkerülni)

  Ezek olyan nem várt mellékhatásai, amik problémát okozhatnak minden ilyennél, nem csak az akcióknál.

  A normalizálás erről szól. Nem véletlenül találták ki több évtizede, és használják mindenhol.

  És igen, ez azt eredményezheti, hogy akár egy mezőt is külön táblába kell tenni adott esetben, majd ellátni a megfelelő foreign key-jel, ( és persze erre majdhogynem automatikusan mehet rá az index, így a JOIN gyakorlatilag "költségmentes" lesz). Viszont így az adatszerkezet sokkal karbantarthatóbb lesz.

• #1420 fordfairlane veterán Peter Kiss #1417

  Új Válasz 2013-08-20 23:53:56 #1420

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  fordfairlane

  veterán

  válasz Peter Kiss #1417 üzenetére

  Mi kérünk elnézést?

  Jah, hát lassan ott tart a dolog.

• #1413 fordfairlane veterán biker #1410

  Új Válasz 2013-08-20 18:05:28 #1413

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  fordfairlane

  veterán

  válasz biker #1410 üzenetére

  akkor minden darabolással egy redundáns termék_ID oszloppal hízlalod az adatbázist...

  Mert jellemzően nem attól lesz redundáns az adatbázis, hogy túl sok tábla kerül bele, hanem attól, hogy túl kevés. Például ebben a példában a közös akciókban szereplő termékeket nem tudod összekötni egymással, mert termékenként tárolod az akciók összes attribútumát. Aztán mi van akkor, ha egy adott termék más szállítótól érkezik, hogyan kapcsolod a kettő tételt össze, ha a termék statisztikájára vagy kíváncsi?

  Ez az egész téma ráadásul egy adatbázis tervezési tanfolyam első leckéi közé tartoznak. Normálformák, ilyesmi. Alapvető dolog relációs adatbázisoknál. Ez az egész aggódás, hogy túl sok a tábla akkor szokott előjönni, ha a JOIN-ok vagy az indexek használata már lassan és nehézkesen megy, ami adatbáziskezelésnél viszont alapvető dolog.

• #1370 fordfairlane veterán martonx #1369

  Új Válasz 2013-08-01 10:37:48 #1370

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  fordfairlane

  veterán

  válasz martonx #1369 üzenetére

  Nem a tárolt eljárások létjogosultságát vagy hasznosságát kérdőjeleztem meg, hanem azt, hogy minek kell azon köröket futni, hogy ki használta és ki nem (és jájjdeámátőr) Sokan nem használják, mert nem a klasszikus Oracle, Sybase, DB2 vagy MSSQL-en tanultak, a Mysql-be meg később került bele. Vagy azért nem használják, mert korlátozottak a lehetőségek és emiatt úgyis szükség van egy alkalmazásszerverre, és ha már van alaklmazásszerver, akkor azon implementálnak minden funkcionalitást. Vagy azért, mert a tárolt eljárások még annyira sem egységesek a különféle vendorok közt, mint az SQL lekérdezések. Nincs azon semmi meglepő, hogy ilyen körülmények közt csomóan nem nyúlnak hozzá, csak ha muszáj.

• #1368 fordfairlane veterán martonx #1367

  Új Válasz 2013-07-31 21:23:10 #1368

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  fordfairlane

  veterán

  válasz martonx #1367 üzenetére

  Szerintem ha nem tudsz értelmesen hozzászólni a témához, akkor talán ne erőltesd. Nincs szükség arra, hogy megmondóemberként itt arcoskodj.

• #1366 fordfairlane veterán szmegma #1365

  Új Válasz 2013-07-31 20:47:03 #1366

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  fordfairlane

  veterán

  válasz szmegma #1365 üzenetére

  Nem nagy dolog, én sem használtam még soha.

• #1334 fordfairlane veterán Jim-Y #1333

  Új Válasz 2013-07-24 11:02:27 #1334

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  fordfairlane

  veterán

  válasz Jim-Y #1333 üzenetére

  Egyébként lehetséges, hogy megoldható egy lekérdezéssel is, de tárolt eljárással vagy alkalmazáslogikával talán átláthatóbb.

• #1332 fordfairlane veterán Jim-Y #1328

  Új Válasz 2013-07-24 10:52:54 #1332

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  fordfairlane

  veterán

  válasz Jim-Y #1328 üzenetére

  Miért akarod egy queryben lekérdezni ezt? Különféle szerkezetű és számosságú eredményhalmazról van szó.

• #1286 fordfairlane veterán spammer #1285

  Új Válasz 2013-06-12 19:56:18 #1286

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  fordfairlane

  veterán

  válasz spammer #1285 üzenetére

  Működik, csak a kérdés, hogy mint módszer, ez is rossz-e?

  Teljesen jó. Persze jobb lenne, ha a PDO interfészt használná.

• #1284 fordfairlane veterán spammer #1280

  Új Válasz 2013-06-12 19:40:13 #1284

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  fordfairlane

  veterán

  válasz spammer #1280 üzenetére

  Ennyit kell kapj. A num_rows az eredményhalmaz elemeinek számát adja vissza. Jelen esetben az eredményhalmozod egyetlen szám, ami a sorok számát tartalmazza. Ezt az eredményt ugyanúgy kell kiolvasnod, mint mikor táblamezőket kérdezel le.

• #1275 fordfairlane veterán spammer #1274

  Új Válasz 2013-05-31 15:18:48 #1275

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  fordfairlane

  veterán

  válasz spammer #1274 üzenetére

  Kétszer fut le ez a programrész?

• #1224 fordfairlane veterán laracroft #1223

  Új Válasz 2013-05-10 16:37:23 #1224

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  fordfairlane

  veterán

  válasz laracroft #1223 üzenetére

  Ha a két lekérdezés túl sokáig tart, akkor egy is. Át kéne nézni / gondolni a táblák-mezők indexelését, amivel gyorsítani lehet az ilyesfajta lekérdezéseken.

  A másik lehetőség, hogy, jellemzően webes környezetben sokkal több a táblából olvasás, mint az írás. Ebben az esetben azokat az aggregált adatokat, amelyek csak írás esetén változhatnak meg, és a lekérdezésük időigényes, előre ki lehet számolni, majd valahogy letárolni. Kvázi gyorsítótárazni. Mondjuk ez jelen esetben nem igazán járható út, de talán részhalmazokat elő lehetne állítani, amiket aztán gyorsabb átfésülni.

• #1222 fordfairlane veterán laracroft #1221

  Új Válasz 2013-05-10 14:35:54 #1222

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  fordfairlane

  veterán

  válasz laracroft #1221 üzenetére

  Egy lapon is lehet két lekérdezés eredményét megjeleníteni.

• #1220 fordfairlane veterán laracroft #1219

  Új Válasz 2013-05-10 14:17:40 #1220

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  fordfairlane

  veterán

  válasz laracroft #1219 üzenetére

  És miért egy lekérdezésben akarod látni? Ez két külön szűrőfeltétel. Talán UNION queryvel összeeszkábálható egybe, de nem tiszta megoldás az sem.

• #1186 fordfairlane veterán futár #1185

  Új Válasz 2013-03-29 18:50:57 #1186

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  fordfairlane

  veterán

  válasz futár #1185 üzenetére

  Például. Általánosságban értettem a dolgot, elnézve, hogy mennyi probléma van egy ilyen alkalmazással.

• #1184 fordfairlane veterán futár #1183

  Új Válasz 2013-03-29 16:34:53 #1184

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  fordfairlane

  veterán

  válasz futár #1183 üzenetére

  Az ilyen régi szoftvereket legcélszerűbb egyben átvinni valami virtualizált környezetbe, az eredeti rendszert guestként futtatva, akkor van velük a legkevesebb probléma.

• #1180 fordfairlane veterán futár #1177

  Új Válasz 2013-03-29 15:28:01 #1180

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  fordfairlane

  veterán

  válasz futár #1177 üzenetére

  Úgy látom, hogy a Mysql 4.0.x -> 4.1.x váltásnál jött elő először ez az autentikáció probléma. Van valami old_passwords nevű my.ini direktíva, amivel ez talán orvosolható a legfrissebb Mysql esetében is. Ha nem, akkor régebbi verzióval kell próbálkozni.

• #1178 fordfairlane veterán futár #1177

  Új Válasz 2013-03-29 15:15:36 #1178

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  fordfairlane

  veterán

  válasz futár #1177 üzenetére

  Gondolom ez azt jelenti, hogy valami friss Mysql-lel próbálkozol.

• #1175 fordfairlane veterán futár #1167

  Új Válasz 2013-03-29 14:44:25 #1175

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  fordfairlane

  veterán

  válasz futár #1167 üzenetére

  SQL hiba: denied for user 'ODBC'@'localhost' (using password: NO)

  A hibaüzenet alapján szerintem csak egy ODBC nevű Mysql felhasználót kell létrehoznod az adatbáziskezelővel, üres jelszóval.

• #1142 fordfairlane veterán #68216320 #1140

  Új Válasz 2013-03-11 19:15:31 #1142

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  fordfairlane

  veterán

  válasz #68216320 #1140 üzenetére

  Ha a mysqli interfészt használod, akkor inkább a mysqli_stmt::bind_params-t célszerű használnod. A példa alapján szerintem egyértelmű, hogyan kell használni.

• #530 fordfairlane veterán cucka #524

  Új Válasz 2009-01-22 18:34:39 #530

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  fordfairlane

  veterán

  válasz cucka #524 üzenetére

  Én a komplikációk elkerülése érdekében mindig kerülöm stringbe változó beírását, inkább összefűzöm a megfelelő operátorral.

• #462 fordfairlane veterán VladimirR #461

  Új Válasz 2008-08-02 01:43:33 #462

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  fordfairlane

  veterán

  válasz VladimirR #461 üzenetére

  Tipp:

  [link]

  De bizonyára a mysql konfigurációban is van lehetőség ezen finomhangolni, én magam még nem próbáltam.

Új hozzászólás Aktív témák