- D1Rect: Nagy "hülyétkapokazapróktól" topik
- weiss: Pant* rant
- Gurulunk, WAZE?!
- eBay-es kütyük kis pénzért
- btz: Internet fejlesztés országosan!
- Yutani: Yutani Retró Hangkártyái: OAK Mozart Wavetable
- sziku69: Fűzzük össze a szavakat :)
- Luck Dragon: Asszociációs játék. :)
- Steven: Sokat utazó kávéfüggők ide!
- Klaus Duran: 2025 dude
Új hozzászólás Aktív témák
-
leslie23
tag
Nagyon köszi a válaszokat! És valóban, az a szál dobja az hibát, amelyiken a query több, mint 15 másodperce fut (dokumentáció írja is, hogy a default connection timeout 15 sec, command timeout pedig 30).
Ami viszont számomra nagyon furává teszi az egészet... Ha egyetlen szál fut (csak egy kiugróan hosszú queryt választok ki a 70 közül), akkor ugyanezen kóddal nem dobja el a kapcsolatot és közel 50 másodpercig nyitva van a connection és leszedi szépen az adatokat. Command timeout be van állítva 0-ra (ez eddig is be volt), de a connection timeout a default értéken (15 sec) van. Ez magyarázza, hogy az első verziónál, szekvenciális végrehajtás mellett miért nem jött elő a connection timeout hiba a néhány hosszabb querynél sem.
Viszont onnantól kezdve, hogy a parallel szálakon, szimultán futnak a query-k és explicit módon nincs meghatározva a connection timeout, rögtön ketyeg a 15 másodperc...Ennek esetleg valamilyen SQL-oldali beállítás lehet az oka?
Új hozzászólás Aktív témák
● ha kódot szúrsz be, használd a PROGRAMKÓD formázási funkciót!
- Csere-Beszámítás! Corsair Dominator Platinum 2x32GB (64GB) Kit 5200MHZ DDR5
- CarPlay / Android Auto adapter meglévő Android alapú fejegységhez
- Asus ROG G20AJ - Intel Core i7-4790, GTX 980
- OLCSÓBB!!! DDR5 16GB 8GB 32GB 4800MHz 5600MHz RAM Több db
- Xiaomi Redmi Note 10 Pro 128GB, Kártyafüggetlen, 1 Év Garanciával
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest