Разница между ADO на стороне клиента и на стороне сервера, когда база данных SQL Server является локальной? - PullRequest
1 голос
/ 08 мая 2019

Я использую SQLServer EXPRESS на локальном ПК для размещения базы данных и соединения с набором записей ADO из Excel / VBA.

Каковы последствия использования adUseClient против adUseServer для свойства recordset.CursorLocation?

Документация, которую я нашел, в основном касается плюсов и минусов доступности ресурсов на сервере по сравнению с клиентом, НО это не проблема, поскольку сервер и клиент - это одно и то же устройство.

1 Ответ

1 голос
/ 08 мая 2019

Это немного неполно - это касается не только местоположения, но и типа. Видите, типы ограничены местоположением. С помощью курсора на стороне клиента вы можете иметь статический набор записей 1 ; запрашивать набор ключей или динамический набор записей недопустимо с помощью курсора на стороне клиента. Когда вы думаете об этом, это логично, потому что сервер - это тот, который имеет самую последнюю информацию, поэтому он может быть только тем, кто предоставляет набор ключей или динамический набор записей.

Обратите внимание, что одним из аспектов ADO является то, что вы не получите сообщение об ошибке, если запросите недопустимую комбинацию. Скорее, он будет молча заменять ваши «запросы» действительным запросом, который может обслуживать поставщик. 2 Таким образом, вы не можете доверять тому, что ваши запросы были выполнены, пока вы фактически не открыли набор записей. После открытия вы заметите, что тип / местоположение / блокировка могут отличаться от того, что вы запрашивали.

С набором статических записей на стороне клиента это в основном означает, что сервер обслуживает вас данными в виде одного большого блока. Когда вы перемещаетесь, больше нет связи с сервером с целью поддержания актуальности данных. Вы все еще можете говорить с ним в целях обновления или повторной синхронизации, но, как следует из названия, это зависит от клиента.

С набором записей набора ключей на стороне сервера все, что вы получаете от сервера, - это цепочка ключей. Когда вы перемещаетесь по набору записей, он должен будет запросить у сервера запись для того ключа, на котором вы находитесь. Таким образом, при работе вокруг вас меньше загружается, но больше разговоров.

С динамическим набором записей на стороне сервера, который является самым редким - большинство провайдеров не реализуют это - сервер может уведомлять клиента об изменениях, включая добавления / удаления, но в остальном он похож на набор ключей.

Таким образом, короче говоря, местоположения недостаточно - вы должны учитывать и местоположение, и тип вместе, что влияет на то, насколько «болтливым» будет ваша кодовая база с сервером.

в сторону - отключенные наборы записей

Иногда "клиентская сторона" смешивается с "отключенной" ... это на самом деле другое дело, хотя отключенный набор записей по необходимости должен быть набором записей на стороне клиента. В конце концов, как вы могли бы "отключиться", не теряя кеш? Как упоминалось ранее, вы все еще можете выполнять обновления данных со статическим набором записей на стороне клиента; вы просто не знаете, были ли данные изменены на сервере, так как вы получили данные во время открытия. С серверным набором ключей / динамическим ключом вы можете проверить, изменились ли данные, как только вы перейдете к этой записи, а не намного раньше прямо при открытии статического набора записей на стороне клиента. Следовательно, существует большая вероятность возникновения конфликта записи с набором записей на стороне клиента по сравнению с набором записей на стороне сервера, особенно если вы используете набор записей для просмотра формы.

Отключение набора записей просто означает, что никакой связи не происходит, когда вы выполняете Update с набором записей, а сервер не синхронизирован. Однако у вас есть возможность повторно подключить и зафиксировать изменения в большом количестве.

Обратите внимание, что на LockType также влияет местоположение 3 . Логично, что набор записей на стороне клиента никогда не может быть пессимистичным в их блокировке, потому что, чтобы быть пессимистичным, вам нужен исключительный контроль над этим, и только сервер может обеспечить это.


  1. Согласно CursorType doc :

    Поддерживается только настройка adOpenStatic, если для свойства CursorLocation установлено значение adUseClient.

  2. Из той же статьи:

    Если установлено неподдерживаемое значение, ошибки не будет; вместо этого будет использоваться ближайший поддерживаемый CursorType.

    Если поставщик не поддерживает запрошенный тип курсора, он может вернуть другой тип курсора. Свойство CursorType изменится, чтобы соответствовать фактическому типу курсора, который используется, когда открыт объект Recordset.

  3. С Статья свойства LockType :

    Параметр adLockPessimistic не поддерживается, если для свойства CursorLocation установлено значение adUseClient. Если установлено неподдерживаемое значение, ошибки не будет; вместо него будет использоваться ближайший поддерживаемый LockType.

...