adUseClient vs adUseServer

[codesearcher]

Most of the time i only use aduseclient but when i was aware of aduseclient to use client resources and aduseserver uses server resources, i tried to use aduseserver to fetch data to msflexgrid and as a result, no data was fetch but when i returned it to aduseclient, data were fetch and placed to msflexgrid. Why is that?

[dilettante]

While old, you might want to read the subtopics under:

Chapter 11 - Universal Data Access Using ADO

Cursors have numerous characteristics, and for multirecord report data binding using a client-side cursor is a way to "punt" and get useful default characteristics. This can come at a cost of copying and recopying data to do it, but it can be useful for quick and dirty programming.

With the proper characteristics a server-side cursor can report-bind as well and have far better performance, and more importantly use far less memory. The latter matters most in code that runs in a server handling many user requests such as ASP pages, but far less on a single-user PC where RAM is cheap.

[techgnome]

Depends on the code... when you use adUseClient, the query is performed, and all of the data is then sent to the client. When you use adUseServer though, the data isn't returned directly... you have to access the rows in the recordset first to make them available. Serverside is best for forward, read-only, looping operations. ClientSide is best when you need all of the data all at once for displaying, or if you want to disconnect the recordset.

-tg

[Schmidt]

Most of the time i only use aduseclient but when i was aware of aduseclient to use client resources and aduseserver uses server resources, i tried to use aduseserver to fetch data to msflexgrid and as a result, no data was fetch but when i returned it to aduseclient, data were fetch and placed to msflexgrid. Why is that?

An ADO-Recordset is a "Wrapper-Class for Records" which in
adUseClient-mode combines:
- a free positionable "Cursor" (an internally movable Pointer to the current-Record)
- true "Container-Mode" (ability to completely disconnect from the Server-DB, storing "the Set of records" InMemory)
- reliable RecordCount-, Sort- and Filter-methods, directly usable after returning from the DB-Select (having "the Set" InMemory behind the Rs)

In adUseServer-Mode the ADO-Recordsets are basically reduced to "pure Cursor Mode".
(imagine such a "Cursor" as a "Stripe, consisting only of the Fields/Columns of only one single Record")

When you use the Cursor-Positioning-Methods (MoveFirst, MoveNext, AbsolutePosition)
on an ADO-Recordset, then in adUseClient-Mode the positioning can be performed on
the already "InMemory-Cached" copy of all the Records, the "SQL-Select-String" described.

In adUseServer-Mode such a positioning (usually) needs more efforts, since the
"next Record you want to position the ADORs to" has to be requested from
the Server itself.

adUseServer is the "more complex mode" (under the covers) - and it puts quite
some strain on serverside Resources (but it is the somewhat "lighter" mode,
memory-wise on the client-side).

With todays PCs which have Memory in the Gigabyte-Range, its usage is not that
worthwile as it was 15 years or so ago.

So, adUseClient is the way to go today IMO - much easier to handle for the ADO-
OleDB- and ODBC-Drivers (especially on "non-MS-Drivers", as e.g. MySQL) - and
with much less "surprises" when you use such Rs (as e.g. in your FlexGrid-Filling).

In adUseClient-Mode you can rely on, that directly after you selected an Rs, you
have all the contents of the Select (all the Records) InMemory - and that the
Rs will be immediately "responsive" with the correct RecordCount, but also with
its internal (InMemory-based, non-DB-related) Filter- and Sort-Methods.

adUseServer is useful only in a few (rare) cases (e.g. it performs better with
some Bulk-Inserts in a tight "AddNew"-loop - but that's it basically).

Modern DB-access-schemes all prefer something like adUseClient-Mode these
days (e.g. in ADO.NET you don't have something like adUseServer-mode anymore).
Though for direct "single-Record-access" to DB-Engines there often are special
"Cursor-Classes" available in most larger Frameworks as e.g. .NET and Java.

Olaf

[codesearcher]

dilettante, tg, schmidt, thanks for the reply.

Yes I have noticed that aduseclient is best for retrieving data for display and since memory is cheap nowadays for client computers to have, thus, there not much use of adUseServer to retrieve data for display. adUseServer now is used to perform action queries where the server can best perform there.

[codesearcher]

dilettante, tg, schmidt, thanks for the reply.

Yes I have noticed that aduseclient is best for retrieving data for display and since memory is cheap nowadays for client computers to have, thus, there not much use of adUseServer to retrieve data for display. adUseServer now is used to perform action queries where the server can best perform there.