ADO i kursor po stronie serwera

lacze sie z mysql poprzez ODBC za pomoca komponentow ADO. wyciagam z kilku tabel duzo rekordow, juz w jednej mam ponad 50 tysiecy. domyslnie komponenty ado pracuja z kursorem po stronie klienta wiec pobieraja caly zbior do siebie i tam na nim pracuja. niestety nie moge na to pozwolic bo pobranie tych 50tysieci z tylko jednej tabeli zabiera ponad 70mb ram.
ustawilem dla polaczenia i dla query/dataset kursory na dynamiczne i na dzialajace po stronie serwera ale teraz przy probie wykonania zapytania dostaje wyjatek:

"Dataset does not support bookmarks which are
required for multi-record data controls."

dodam ze blad pojawia sie w momencie podlaczenia dbgrida(nawet na etapie projektowania z aktywnym polaczeniem). gdy odlacze dbgrida dziala poprawnie.

co musze zrobic aby uzyskac kursor po stronie serwera i moc kozystac z dbgrida?

calosc dotyczny C++Builder 2006, mysql 5.1 ODBC 5.1 lub 3.51

A czemu nie wybrac konkretnym zapytaniem/widokiem tylko kilku interesujacych informacji? Po co w ogole przetwarzac wszystko po stronie klienta?

to chyba nie jest odpowiedz na postawiony problem!?

musze meic dostep do calego zbioru a ze jest on zbyt duzy to chce miec kursor po stronie serwera a nie klienta i tu jest problem bo nie moge podpiac wtedy grida. prosze o pomoc w rozwiazaniu tego problemu a nie inne rady ;)

To jest pytanie o sens Twojego pytania. Nie chcesz pobierac calej zawartosci, ale chcesz ja miec po swojej stronie? Przeciez to bez sensu. Ja pytam o sens pobierania tak duzych danych zamiast wybierac tyle ile trzeba po stronie serwera. A rzadko kiedy trzeba miec wszystkie u siebie...

sprawa wyglada tak, przegladam np 50 000 rekordow(modyfiuje etc)... nie chce ich pobrac wszystkich Od razu bo to za duzy naklad pamieci. wiec usatwiam bufor na 1000 rekordow, pobieram calosc z kursorem po stronie serwa. sprzecznosc? jaka? takie zestawienie podwuje ze do mnie wraca 1000rekordow a w momencie gdy przechodze na 1001 to automat podmienia mi te 1000 na kolejne 1000 i tak do konca.
nie chce wyciagac pierwszego 1000, puzniej nowe zapytanie i kolejny itd skoro sa do tego mechanizmy.

dokladnie ta sama operacja dla postgresql dziala ale odswierzanie kolejne partii rekordo idzie strasznie opornie. duzo gorzej niz w przypadku bezposrednigo zapytania. mysle ze to sprawa ODBC dla postgre.

w zwiazku z tym zalezy mi na rozwaizaniu z mysql tyle ze przy ustawieniu kursora na serwer dostaje ten blad z pierszego postu.

Mozesz sprobowac w takim razie skorzystac z mechanizmu BulkRead, ktory powinien zadzialac duzo szybciej i sprawniej. Ale trzeba sie troche bardziej opisac i pare rzeczy podziedziczyc. A do czego ten dbgrid tam? To przegladanie to takie reczne?
Obawiam sie, ze przy takiej ilosci wymienianych danych nie ma co liczyc na predkosc swiatla. Dlatego pytalem o mozliwosc ograniczenia ilosci danych przesylanych tam i z powrotem.

http://dev.mysql.com/tech-resources/articles/vb-cursors-and-locks.html
tu jest wszystko opisne. mam dokladnie takie usatwienia. kursor dynamiczny, i kursor po stronie serwa. w polaczeniu odbx jest aktywowany dynamic cursor. gdy tylko calosc podlacze pod grida dostaje error. czy to oznacza ze na gridzie to nie ruszy?

W takim razie z bledu wynika, ze dbGrid nie uzywa 'bookmarks', ktore najwyrazniej sa w tym przypadku konieczne. BTW czemu chcesz uzyc dynamic, skoro jest najmniej wydajne? Sadzilem, ze chodzi Ci o cos w stylu forwardOnly...

dynamic bo tylko taki typ kursora po stronnie serwa obsluguje bookmarki.
na chwile obecna sprawa wyglada tak: dalem kursor na serwa, typ kursora tylko do przodu, wylaczone buforowanie, dataset tylko do odczytu.

takie zestawienie kursorow daje niezla wydajnac wiec w petli modyfikuje i wrzucam na widok listy. calosc leci w watku wiec nie boli mnie to zbytnio...

a z tym darmowym wbudowanym gridem nie chce miec juz nic do czynienia:D nawet nie potrafi dopasowac szerokosci kolumn, pozbyc sie skrola anie nic...