Difference between ADO client-side vs server-side cursor when the SQL Server database is local?

问题

I am using SQLServer EXPRESS on a local PC to house the database and connecting with an ADO recordset from Excel/VBA.

What are the implications of using adUseClient vs adUseServer for the recordset.CursorLocation property?

The documentation I have found primarily deals with the pros and cons of resource availability on the server vs client BUT this is not an issue here as the server & client are the same device.

回答1:

That is a bit incomplete - it's not just about the location but also the type. See, types are limited by the location. With a client-side cursor, you can have static recordset¹; asking for a keyset or dynamic recordset is not legal with a client-side cursor. When you think about it, that is logical, because the server is the one that has the most current information, so it can be only the one to provide the keyset or the dynamic recordset.

Note that one aspect about ADO is that you don't get an error if you ask for an invalid combination. Rather, it will silently substitute your "requests" to a valid request that the provider can serve.² Thus, you cannot trust that your requests has been honored until you've actually opened the recordset. After opening, you'll note the type/location/lock may be different from what you requested.

With a client-side static recordset, it basically means the server serves you the data in one big chunk. As you navigate around, there is no further communication with the server for the purpose of keeping the data current. You still can talk to it for the purposes of updating or resyncing, but as the name implies, that is driven by the client.

With a server-side keyset recordset, all you get back from the server is a chain of keys. As you navigate around the recordset, it will have to ask server for the record for that key you are on. So there's less upfront load but more chatty conversation as you work around.

With a server-side dynamic recordset, which is the rarest -- most providers don't implement that -- server is able to notify the client about the changes including additions/deletions, but otherwise it's similar to keyset.

So in short, location is not enough - you must consider both the location and the type together which influences how "chatty" your codebase will be with the server.

Aside -- Disconnected recordsets

Sometime "client-side" gets mixed up with "disconnected"... that's actually another thing, though a disconnected recordset by necessity must be a client-side recordset. After all, how could you possibly "disconnect" without losing the cache? As alluded to earlier, you still can perform updates on the data with a client-side static recordset; you just don't know if the data has been changed on the server since you retrieved the data at time of opening. With a server-side keyset/dynamic, you are able to check whether data has been changed as soon as you navigate to that record, rather than much earlier right at the opening of the client-side static recordset. Therefore, there is a greater chance of encountering a write conflict with a client-side recordset compared to a server-side recordset, especially if you are using the recordset for browsing around on a form.

Disconnecting a recordset simply means no communication happens when you perform an Update on the recordset and server is not kept in sync. You have the option of re-connecting and committing the changes in bulk, however.

Note that LockType is also affected by the location³. It is logical that a client-side recordset can never be pessimistic in their locking because to be pessimistic, you need exclusive control over that and only the server can provide that.

---

1. According to CursorType doc:

   Only a setting of adOpenStatic is supported if the CursorLocation property is set to adUseClient.

2. From same article:

   If an unsupported value is set, then no error will result; the closest supported CursorType will be used instead.

   If a provider does not support the requested cursor type, it may return another cursor type. The CursorType property will change to match the actual cursor type in use when the Recordset object is open.

3. From LockType property article:

   The adLockPessimistic setting is not supported if the CursorLocation property is set to adUseClient. If an unsupported value is set, then no error will result; the closest supported LockType will be used instead.

来源：https://stackoverflow.com/questions/56037800/difference-between-ado-client-side-vs-server-side-cursor-when-the-sql-server-dat