Hirdetés
- Magga: PLEX: multimédia az egész lakásban
- sziku69: Szólánc.
- Luck Dragon: Asszociációs játék. :)
- sziku69: Fűzzük össze a szavakat :)
- Brogyi: CTEK akkumulátor töltő és másolatai
- Meggyi001: Eldugott helyek Párizsban, amiket jó eséllyel még nem láttál... 2. rész.
- GoodSpeed: Kell-e manapság egérpad vagy sem?
- Gurulunk, WAZE?!
- droidic: Windows 11 önállóság nélküli világ: a kontroll új korszaka
- Sub-ZeRo: Euro Truck Simulator 2 & American Truck Simulator 1 (esetleg 2 majd, ha lesz) :)
Új hozzászólás Aktív témák
- 
			
			  martonx veterán válasz  PumpkinSeed
							
							
								#3478
							
							üzenetére PumpkinSeed
							
							
								#3478
							
							üzenetéreÉn egy adatbázist használnék, a régiónkénti szerverekhez pedig csak egy-egy saját cache-t (mondjuk redis vagy ilyesmi) tennék. Amikor bármi bemegy a DB-be, az X percen belül úgyis be fog futni a cache-be, semmi értelme kismillió adatbázissal szórakozni. Szerintem. Illetve tényleg van értelme minden régióba szervert tennetek? Ez egy sima webszerver, nem media streaming vagy ilyesmi. Nálunk pl. az egész világot egy szál szerverről Írországi adatközpontból szolgáljuk ki, és nagyon nem lassú (nyilván ami késleltetés Nyugat-EU-ban 20ms, az USA-ban 60, Ausztráliában meg akár 100ms fölé is mehet, de ennyi latencyvel simán együtt lehet élni, ahelyett hogy emiatt elkezdenénk görbíteni a teret). A szerver mellé pedig régiónként vannak média streaming szervereink. A legújabb rendszerünk pedig régiónként elosztva készül (saját pixel tracking maximum 5ms-os késleltetése miatt kritikus, hogy közel legyen a felhasználóhoz), mindegyik régiónak van egy saját kis fis-fos NoSql-je (kvázi cache-ként fogható fel), és egy sync service-e, ami bizonyos időközönként, események hatására szinkronizálja a lokális NoSql-t az egyetlen központi MS SQL szerverrel. 
- 
			
			  bambano titán válasz  PumpkinSeed
							
							
								#3478
							
							üzenetére PumpkinSeed
							
							
								#3478
							
							üzenetéreén mindenre postgrest használok, abból lehet master-slave verziót. a lekérdezős frontendeket rátenném a slave-ekre, a hozzászólások posztolását meg a masterre. ha ez nem elég teljesítményben, akkor a blogokat szétültetném ilyen rendszerekből több párhuzamosra. egy ilyesmi verziót csinálnék, neked tetsző sql adatbáziskezelővel. 
- 
			
			  bambano titán válasz  PumpkinSeed
							
							
								#3476
							
							üzenetére PumpkinSeed
							
							
								#3476
							
							üzenetére"Mit értesz az alatt, hogy soha nem szokott jól sikerülni?": az ígéretek meg a valóság között időnként eltérés mutatkozhat. én nem mondtam, hogy nosql nem jöhet szóba, én azt mondtam, hogy én elkerülném a master-master replikációt. ha valaki szereti a nosql-t, használjon azt. fenti állítás még azt sem tartalmazza, hogy te ne használj master-master replikációt  én nem tenném, de mindenki a maga szerencséjének a pogácsa. én nem tenném, de mindenki a maga szerencséjének a pogácsa.
- 
			
			  bambano titán válasz  PumpkinSeed
							
							
								#3474
							
							üzenetére PumpkinSeed
							
							
								#3474
							
							üzenetérea blogolás eléggé lekérdezés-intenzív feladat, sokkal több lekérdezés megy, mint insert. szerintem egy master-több slave adatbázist érdemes használni, nagy in-memory frontendekkel. ráadásul a nyelvi korlátok miatt az adatbázis lekérdezése nem egyenletes eloszlású a földön, így ha témánként vagy témacsoportonként csinálsz egy mastert, akkor azt oda lehet tenni, ahol a többség használja. szerk: én nem próbálkoznék master-master replikációval, az sose szokott jól sikerülni. 
- 
			
			  martonx veterán válasz  PumpkinSeed
							
							
								#3472
							
							üzenetére PumpkinSeed
							
							
								#3472
							
							üzenetére"szükségem van végetelen master-master replikációra" - mert miért is?  Nekem ez architekturális tervezési hibának tűnik, mikor valakitől ilyet hallok. Nekem ez architekturális tervezési hibának tűnik, mikor valakitől ilyet hallok.
- 
			
			  ALFA senior tag válasz  PumpkinSeed
							
							
								#3219
							
							üzenetére PumpkinSeed
							
							
								#3219
							
							üzenetéreAhogy írtam, csak ezt az egyet írhattam, mert amíg nem kapok rá választ, nem írhatok másikat abba a fórumba, mert ez a moderátorok szabálya. 
 Úgyhogy akkor fogtok látni újabb beírást oda tőlem, ha arra valaki válaszol.
 Most már nagy negyedszer írom le, egyszer végre talán célbaér az üzenet. 
- 
			
			  ALFA senior tag válasz  PumpkinSeed
							
							
								#3213
							
							üzenetére PumpkinSeed
							
							
								#3213
							
							üzenetéreÉn az SQL-es részté nem értem, hogyan tudja a szkript a következő lekérdezést is? Addig tiszta, hogy kiadsz egy Select lekérdezést, megkapod az eredményt. 
 Csakhogy ennél a megoldásnál az eredmény minden adata, ahonnan lehetséges további lekérdezés, az linkként jelenik meg, és a link már az újabb Selectes lekérdezést tartalmazza.A logikáját szeretném megérteni  
 Mint egy sakkozós, aki pár lépésre előre gondolkodik, begyűjti a következő potenciális lekérdezések össze változatát is?
- 
			
			  ALFA senior tag válasz  PumpkinSeed
							
							
								#3210
							
							üzenetére PumpkinSeed
							
							
								#3210
							
							üzenetéreKicsit bővebben, ha lehetne.  
 Hogyan tudja egy php program eldönteni, hogy mely adatokhoz van újabb lekérdezési lehetőség, ráadásul úgy, hogy rögtön meg is adja hozzá a linket?Számomra egyértelmű a kérdés, de csak akkor tudom jobban kifejteni, ha adsz visszajelzést, hogy mi nem egyértelmű a számodra.  
- 
			
			  bambano titán válasz  PumpkinSeed
							
							
								#3000
							
							üzenetére PumpkinSeed
							
							
								#3000
							
							üzenetéremilyen sql? 
 postgresql-nél a memóriák méretének növelése segít, illetve ha nem szabvány sql-t dumpolsz, hanem a saját dump formátumát, és akkor az gyorsabb.
- 
			
			  fordfairlane veterán válasz  PumpkinSeed
							
							
								#2627
							
							üzenetére PumpkinSeed
							
							
								#2627
							
							üzenetére
- 
			
			  tamas1985 tag válasz  PumpkinSeed
							
							
								#2556
							
							üzenetére PumpkinSeed
							
							
								#2556
							
							üzenetérekipróbáltam nálam nem jó, lehet valamit rosszul csinálok 
- 
			
			  daninet veterán válasz  PumpkinSeed
							
							
								#2553
							
							üzenetére PumpkinSeed
							
							
								#2553
							
							üzenetéreköfi  
- 
			
			válasz  PumpkinSeed
							
							
								#2535
							
							üzenetére PumpkinSeed
							
							
								#2535
							
							üzenetéreHát ez a bajom ezekkel a könyvekkel, de úgy egészében az oktatással is - kb 1000 éves bevett gyakorlatokat oktatnak, ahelyett, hogy kicsit körbenéznének, mi változott a világban. Az egyetemen is pont ez volt... 
 1. óra eleje: "Itt én kérem szépen naprakész dolgokat tanítok, nem számítok be 4-5 éve végzett főiskolai tárgyakat"
 Többi órát meg végig anekdotázgatva: "1980-ban, Moszkvában..." 
- 
			
			  Sk8erPeter nagyúr válasz  PumpkinSeed
							
							
								#2532
							
							üzenetére PumpkinSeed
							
							
								#2532
							
							üzenetéreMikor vetted azt a könyvet? A prepared statementek használata nem egy újkeletű dolog.  A PHP 5 meg már 2004 júliusában megjelent. Régi könyvekből meg szinte semmilyen folyamatosan fejlődő programozási nyelvet nem éri meg elkezdeni tanulni, mivel ezer dolog változhat az évek során, például a nyelvi adottságok, best practice-ek. A PHP 5 meg már 2004 júliusában megjelent. Régi könyvekből meg szinte semmilyen folyamatosan fejlődő programozási nyelvet nem éri meg elkezdeni tanulni, mivel ezer dolog változhat az évek során, például a nyelvi adottságok, best practice-ek.
- 
			
			  Sk8erPeter nagyúr válasz  PumpkinSeed
							
							
								#2530
							
							üzenetére PumpkinSeed
							
							
								#2530
							
							üzenetéreAkkor azt a könyvet öntsd le benzinnel, aztán gyújtsd fel.  Manapság ezek szerint annyit ér. Egyébként a prepared statementeknek köze nincs az OOP-hoz, a kettő összevetése nem tudom, hogy miből jött ki. Manapság ezek szerint annyit ér. Egyébként a prepared statementeknek köze nincs az OOP-hoz, a kettő összevetése nem tudom, hogy miből jött ki. 
- 
			
			  Sk8erPeter nagyúr válasz  PumpkinSeed
							
							
								#2504
							
							üzenetére PumpkinSeed
							
							
								#2504
							
							üzenetéreValahogy nehéz elhinni, hogy csak gyorsmegoldásként van így, mert a prepared statement használata nem jelent érdemben plusz időt ahhoz képest, hogy konkatenálod a query-t, és azzal szenvedsz, ha már legalább egyszer használtál prepared statementeket. Tényleg nem csak szopatásból találják ki ezeket, hanem a fejlesztő megsegítésére. Hidd el, miután úgy használod, sokkal minőségibbnek és átláthatóbbnak fogod látni a saját kódodat is. Jótanácsként mondom, nem csak hogy cseszegesselek, még ha úgy is tűnik...  "Igen notepad++-t használok, mert nekem ez a kézre eső megoldás, több képernyős módban egyszerre 4 felületet látok egyszerre, másra nincs szükségem.  " "
 Egyáltalán nem értem az összefüggést. Miért, egy normális IDE használatával nem tudnád mindezt megoldani? 
 Pont most írtam a másik topicban, hogy nem nagyon értem, akár egy kis projektnél is mire jó, hogy nehézkesebbé tesszük a dolgunkat azzal, hogy minimális fejlesztőkörnyezeti támogatást sem kapunk kódolás közben. Ujjbegy-és csuklóedzés, vagy mi?"Az aposztrófok zavartak be, mert utána nem jelentkezett a jelenség.  " "
 Ennek nem sok értelme van így, mivel azt mondtad, hogy egyszer sikeresen feltöltésre kerül az adat, máskor meg kinullázódik. Ha épp sikeres volt a feltöltés, és akkor is idézőjelben volt, akkor az miért volt sikeres? Szóval valami más lesz ott a probléma, és később is előjöhet. 
- 
			
			válasz  PumpkinSeed
							
							
								#2479
							
							üzenetére PumpkinSeed
							
							
								#2479
							
							üzenetéreSQL Injection 4 Prezident  Sk8erPeter:  
- 
			
			  martonx veterán válasz  PumpkinSeed
							
							
								#2483
							
							üzenetére PumpkinSeed
							
							
								#2483
							
							üzenetéreHehe, így legyen 5-ösöm a lottón. Mondtam én, hogy a kódoddal lesz a hiba. 
- 
			
			  Sk8erPeter nagyúr válasz  PumpkinSeed
							
							
								#2479
							
							üzenetére PumpkinSeed
							
							
								#2479
							
							üzenetéreEz 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?
- 
			
			  jocomen aktív tag válasz  PumpkinSeed
							
							
								#2483
							
							üzenetére PumpkinSeed
							
							
								#2483
							
							üzenetéreEgyébként milyen típusúnak kell lennie? Ha szám, úgy rémlik nem kell macskaköröm. 
- 
			
			  jocomen aktív tag válasz  PumpkinSeed
							
							
								#2479
							
							üzenetére PumpkinSeed
							
							
								#2479
							
							üzenetéreTipp: 
 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.
- 
			
			  martonx veterán válasz  PumpkinSeed
							
							
								#2477
							
							üzenetére PumpkinSeed
							
							
								#2477
							
							üzenetéreMost 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.
- 
			
			  rum-cajsz őstag válasz  PumpkinSeed
							
							
								#2475
							
							üzenetére PumpkinSeed
							
							
								#2475
							
							üzenetéreNa 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.
- 
			
			  jocomen aktív tag válasz  PumpkinSeed
							
							
								#2467
							
							üzenetére PumpkinSeed
							
							
								#2467
							
							üzenetéreA 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).
- 
			
			  jocomen aktív tag válasz  PumpkinSeed
							
							
								#2465
							
							üzenetére PumpkinSeed
							
							
								#2465
							
							üzenetéreNem 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.
- 
			
			  jocomen aktív tag válasz  PumpkinSeed
							
							
								#2463
							
							üzenetére PumpkinSeed
							
							
								#2463
							
							üzenetéreA `barcode` meg van határozva elsődleges kulcsként a `products` táblában? 
- 
			
			  Sk8erPeter nagyúr válasz  PumpkinSeed
							
							
								#2459
							
							üzenetére PumpkinSeed
							
							
								#2459
							
							üzenetéreIgazad 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 nagyúr válasz  PumpkinSeed
							
							
								#2457
							
							üzenetére 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.![;]](//cdn.rios.hu/dl/s/v1.gif) 
- 
			
			  Ablakos addikt válasz  PumpkinSeed
							
							
								#2380
							
							üzenetére PumpkinSeed
							
							
								#2380
							
							üzenetéreNem is ezt írta a kolléga.  Azt írta melyikeket láthatja. A user_tables nem jó. Azt írta melyikeket láthatja. A user_tables nem jó.
- 
			
			  bpx őstag válasz  PumpkinSeed
							
							
								#2378
							
							üzenetére PumpkinSeed
							
							
								#2378
							
							üzenetéreall_tables 
 a user_tables csak a saját táblákat mutatja
- 
			
			  chabeee aktív tag válasz  PumpkinSeed
							
							
								#2311
							
							üzenetére PumpkinSeed
							
							
								#2311
							
							üzenetéreoh ezt nem tudtam, mysql-t használok 
 megnézem miket lehet velük ügyködni, köszi
- 
			
			  chabeee aktív tag válasz  PumpkinSeed
							
							
								#2304
							
							üzenetére PumpkinSeed
							
							
								#2304
							
							üzenetéreJavaban csináltam, rájöttem hogy kell szépen. 
 Az a lényeg, hogy van három táblám, és azokhoz akartam adatokat szúrni/módosítani ha a kliens úgy akarja. Igazából az volt a probléma, hogy nem egyből töltöttem fel az adatokat, hanem, megvártam amíg a kliens kilép és redekraráétattam a táblákat, a listából feltöltöttem az elemeket. De ez így nagyon verzió nullás, tehát okosabban egyből a hozzáadás pillanatában kell beszúrni az adatbázisba is. Így már gyorsabb lett.
- 
			
			  chabeee aktív tag válasz  PumpkinSeed
							
							
								#2302
							
							üzenetére PumpkinSeed
							
							
								#2302
							
							üzenetéreigen ezekkel tisztában vagyok 
- 
			
			  chabeee aktív tag válasz  PumpkinSeed
							
							
								#2297
							
							üzenetére PumpkinSeed
							
							
								#2297
							
							üzenetéreigen az megvolt  
- 
			
			  bpx őstag válasz  PumpkinSeed
							
							
								#2286
							
							üzenetére PumpkinSeed
							
							
								#2286
							
							üzenetéreAzért, mert alapértelmezett esetben a TO_CHAR dátum bemenet esetén a lehetséges leghosszabb kimenetre készülve rak paddinget (extra space-ek), ezért amikor a te 'THURSDAY'-t vársz, ott valójában 'THURSDAY '-t kapsz, mert a 'WEDNESDAY' a leghosszabb, és minden napot 9 karakterre egészít ki emiatt. Ha ezt nem szeretnéd, akkor a 'DAY' helyett használj 'FMDAY'-t, amiben az FM kikapcsolja a paddinget. Ezen kívül: 
 - az UPPER felesleges, mert a 'DAY' miatt eleve nagybetűsen kapod az eredmény ('day' - kisbetű)
 - ha a TO_CHAR-t a megfelelő NLS paraméterrel kiegészíted, akkor rögtön magyarul kapod a napot
 - az INITCAP függvénnyel lehet a szavak kezdőbetűjét nagybetűre cserélni, ha ez az igényPl: SQL> SELECT INITCAP(TO_CHAR(TO_DATE('1994-01-06','YYYY-MM-DD'),'FMDAY', 'NLS_DATE_LANGUAGE = HUNGARIAN')) AS VALAMI FROM DUAL; 
 VALAMI
 ------------
 Csütörtök
- 
			
			  Sk8erPeter nagyúr válasz  PumpkinSeed
							
							
								#2281
							
							üzenetére PumpkinSeed
							
							
								#2281
							
							üzenetérePéldául beillesztésnél tudod felhasználni a szekvenciát. 
 Vegyünk egy nagyon egyszerű példát: van egy supplier nevű táblád (az általad létrehozott supplier_seq alapján), első mezője egy int id, ami primary key is egyben. Másik mezője legyen a példa kedvéért egy name mező, nvarchar2(50) típussal.
 Feltöltesz valami újat, pl.:insert into supplier 
 values (supplier_seq.nextval, 'blabla');A lényeg tehát a supplier_seq.nextval, ezzel tudod kivenni a szekvencia soron következő értékét. 
- 
			
			  Ablakos addikt válasz  PumpkinSeed
							
							
								#2281
							
							üzenetére PumpkinSeed
							
							
								#2281
							
							üzenetéreMi az hogy lefut? Létrehoztál egy sequencia objektumot. Ha létrehozol egy táblát az sem "fut le". 
 Hivatkozhatsz a pseudooszlopaira nextval vagy curval-lal.
 tehát: select supplier_seq.nextval from dual; A sequencia következő elemét adja. Kiválóan alkalmazható egy unique key megszorítással ellátott oszlopot egyedi azonosítóval ellátni.
- 
			
			  bpx őstag válasz  PumpkinSeed
							
							
								#2281
							
							üzenetére PumpkinSeed
							
							
								#2281
							
							üzenetéreelső találat 
- 
			
			  martonx veterán válasz  PumpkinSeed
							
							
								#2277
							
							üzenetére PumpkinSeed
							
							
								#2277
							
							üzenetéreSémákkal tudsz adatbázisokat / adatbázis részeklet elkülöníteni. Olyan ez, mint programozásban a namespace. Sequence: már a nevében benne van, hogy mi ez, és mire jó. Nem fogod kitalálni, egy folyamatosan növekvő számláló. Hogy mire jó azt a képzeletedre bízom, pl. adatbázis sorokat azonosítani. 
- 
			
			válasz  PumpkinSeed
							
							
								#2264
							
							üzenetére PumpkinSeed
							
							
								#2264
							
							üzenetéreJogos, azt nem mondtam, hogy PHP-ben kellene megoldanom. Irány a PHP topic... 
- 
			
			  Ablakos addikt válasz  PumpkinSeed
							
							
								#2237
							
							üzenetére PumpkinSeed
							
							
								#2237
							
							üzenetéreMire való? Jó nagyot szívni, mire megtalálja a fejlesztő, melyik rekord vajon miért nem akar bemenni az adatbázisba  
- 
			
			  martonx veterán válasz  PumpkinSeed
							
							
								#2239
							
							üzenetére PumpkinSeed
							
							
								#2239
							
							üzenetéreVan két adathalmazod. Az egyik SQL táblában, a másik meg egy szöveg fileban mondjuk vesszővel elválasztva. 
 Mit teszel, ha a kettő közös metszetét kellene meghatároznod?
 Persze elkezdheted mindkettőt lekérni, majd memóriában for-okkal összeforgatni, és ifekkel ellenőrizni.
 Vagy fogod, feltöltöd a csv-det egy ilyen external táblába, és egy szimpla sql select-el megkapod a közös halmazt.
 Kapisgálod, hogy mire jó ez?
- 
			
			  bpx őstag válasz  PumpkinSeed
							
							
								#2237
							
							üzenetére PumpkinSeed
							
							
								#2237
							
							üzenetéreAz, hogy odamásolsz pl. egy CSV file-t és tudsz belőle úgy lekérdezni, mintha közönséges tábla lenne. 
- 
			
			  diegho nagyúr válasz  PumpkinSeed
							
							
								#2229
							
							üzenetére PumpkinSeed
							
							
								#2229
							
							üzenetéreCsak egy visszatöltő programja van, ami már előre kimentett adatbázist tud visszatölteni. MS SQL 2005-öt használ szerverként. Fogalmam sincs mit tehetnék. Amikor csak rámásolom az adatbázist, akkor a program látja, hogy ott vannak a cégek, de megnyitni és kimenteni nem tudom őket. 
Új hozzászólás Aktív témák
Hirdetés
- Milyen légkondit a lakásba?
- GL.iNet Flint 2 (GL-MT6000) router
- Automobilista 2
- Pánikban a világ a Radeon RX 5000 és 6000 sorozat támogatása miatt
- AMD Catalyst™ driverek topikja
- TCL LCD és LED TV-k
- OLED TV topic
- AMD Ryzen 9 / 7 / 5 9***(X) "Zen 5" (AM5)
- Apple MacBook
- 5.1, 7.1 és gamer fejhallgatók
- További aktív témák...
Állásajánlatok
Cég: NetGo.hu Kft.
Város: Gödöllő
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest
 
								 
							 
								 én nem tenném, de mindenki a maga szerencséjének a pogácsa.
 én nem tenném, de mindenki a maga szerencséjének a pogácsa. Nekem ez architekturális tervezési hibának tűnik, mikor valakitől ilyet hallok.
 Nekem ez architekturális tervezési hibának tűnik, mikor valakitől ilyet hallok. 
								

 
								 
								 
								
 
								
 
								 Manapság ezek szerint annyit ér. Egyébként a prepared statementeknek köze nincs az OOP-hoz, a kettő összevetése nem tudom, hogy miből jött ki.
 Manapság ezek szerint annyit ér. Egyébként a prepared statementeknek köze nincs az OOP-hoz, a kettő összevetése nem tudom, hogy miből jött ki. 



 
								 
								![;]](http://cdn.rios.hu/dl/s/v1.gif)
 
								 Azt írta melyikeket láthatja. A user_tables nem jó.
 Azt írta melyikeket láthatja. A user_tables nem jó. 
								 
								 
								 
								
