OLEDB GetNextRows a teljes táblát olvassa
2022-07-11T14:11:15+02:00
2022-07-11T16:04:54+02:00
2022-08-14T17:45:41+02:00
BUH-X
OLEDB adatkiszolgálót használok. (WinDev HFSQL)
A gondom, hogy a legelső GetNextRow a teljes tábla olvasás idejét eltölti.
Az első lekérés nagyon hosszú (500 sec, az összes többi 0 sec.
Bonusz hiba, hogy mivel a currency típusú oszlopokat nem tudom jól olvasni, át konvertálom a SELECT lekérdezésben TO_CHAR()  formába. Ez az időt meg száz szorozza. 4 másodperc helyett több mint 500 másodperc. De csak az első GetNextRow.
A GetNextRow-nak nem csak egy sort kellene bepufferelni?
Illetve miért lesz ilyen hosszú a TO_CHAR konvertálás miatt?
Mutasd a teljes hozzászólást!

  • Próbáltam ODBC interfészen keresztül is.

    SELECT TO_CHAR(oszlop) FROM tabla ... >500 sec SELECT oszlop FROM tabla ... 4 sec

    Ez normális?
    Mutasd a teljes hozzászólást!
  • Szia!

    Nem tudom....
    Túl sok az ismeretlen változó.
    Hány rekord?
    Milyen adatbázis? 
    Natív HFSQL?
    Nem terheli meg az adatbázis szerver prociját?

    Support-ot kérdezted már?

    A konvertálás időbe tellik.
    Hogy mennyi a normális az függ a rekordok számától és még sok minden mástól is.
    Mutasd a teljes hozzászólást!
  • Válaszok:
    38000 rekord
    Windev HFSQL kliens/szerver
    Gyári HFSQL Control Center programból kiadva az SQL lekérdezést, nincs különbség időben, a sima és a konvertált lekérdezésben
    Sőt most próbáltam, hogy ha az adattáblát letöltöm fájlba.
    Majd az OLEDB/ODBC kapcsolódásnál a fájlt adom meg, akkor sem jelent plusz időt a TO_CHAR konverzió.
    Windev support sajnos nem szokott válaszolni, windev fóromon is próbálkoztam
    Azt sem tudom még, hogy én rontok-e el valamit, minden szereplő új nekem, az SQL is az OLEDB is.

    A jelenlegi probléma úgy merült fel, hogy nem sikerül a DBTYPE_CY  típusú currency mezöket jól átvennem. Elvileg 10 000-es szorzó van. De nekem néha 1 000 néha 100 000 a jó osztó. Excel OLEDB-n jól látja. Ezért akartam átlépni, és konvertálni TO_CHAR-ra. Elvileg jó is, csak lassú.

    Nem tudom, hogy minden ROW lekérésnél újra kell olvasnom a header infot is, hogy a currecny tulajdonságokat újra megkapjam.

    Köszönöm
    Mutasd a teljes hozzászólást!
  • Szia!

    6 digit a tört rész.
    Itt írják:

    Currencies

    De egyébként nincs sok dokumentáció még erről...
    Ránézésre valami nagyon új lehet...
    Mutasd a teljes hozzászólást!
  • Nem új dolog. Csak ez egy komplett keretrendszer, sokan is használják. Csak így külön az adatbázis nem szokták piszkálni. Gondolom azért nincs válasz sem.

    Most ott tartok, hogy wireshark-al megnéztem a hálózati kommunikációt .Beraktam két felismerhető szöveges adat közé a problémás oszlopot.  A konverziót a szerver csinálja valóban. Ami jó. Konverzió nélkül látom, hogy 8 bájtot küld le, ahogy kell. Konverzióval viszont leküldi jól a karakterláncot, de utána küld kb. 7kbyte 0-át. Minden sornál.
    Mutasd a teljes hozzászólást!
abcd