Ideja, kuri sauna i galva tokia - nuo kazkurios versijos ADO pradejo palaikyti transakcijas (tipo patys ADO komponentai turi savo transakciju valdymo mechanizma). Manau, kad cia suo ir pakastas. Tikriausia tie gudrus objektai pradeda inicijuoti transakcija ir pasiklysta tarp triju medziu, kol sugalvoja ar cia galima commit'inti ar reikia rollback'inti. "Meff" <noemail@japan.cc> wrote in message news:hs9bsg$s7p$1@trimpas.omnitel.net... > Pasinaudosiu Lino patarimu paloginti ką ten daro SQL'as. Bet tai kažin ar neatsakys į klausimą: kaip ADO priversti > elgtis kitaip? > > Klausimas buvo įdomumo dėlei. Yra tekę .Net'e generuoti SQL table'ų struktūras, taip pat darbą su jomis, tai va > tokiems atvejams ir noriu žinoti kaip ADO priversti daryti tai ką reikia taip, kaip reikia. > Šiuo konkrečiu ir buvo panaudota SP :-) Būtent ji ir ištrina duomenis per < 1 s :-) > > > "2x50" <a@a.a> wrote in message news:hs9bgr$rpt$1@trimpas.omnitel.net... >>> Kaip manot, ką .Net'as padaro ir kaip tokių nesąmonių išvengti? Jau ne pirmą kartą su tokia nesąmone susiduriu. Ypač >>> aktualu, kai trinami dideli duomenų kiekiai. >> >> Senesniais kokias 2003 metais buvo rekomenduojama naudoti stored proceduras darbui su duomenim. Pabandyk, gal pades. >> As >> tik taip softa rasydavau, stored procedura moka istrinti (ar ten kazka kitka padaryt), o per ADO tik iskvieti stored >> procedura kaip komanda (alia execute mano_proc @param1=x, nesikabinekit prie sintakses :). Nenaudodavau jokiu command >> objektu ar panasiu indusu stebuklu, kurie neaisku ka daro... :P >> >>