ADO, показывающий «скрытые столбцы» с собственным SQL-сервером

Question

Я работаю над старым приложением с использованием VB6 и классического ASP. Мы используем отключенные наборы ADO для передачи данных взад и вперед. Обычно это работает. Но то, что начиналось в последнее время, связано с любым внутренним/внешним соединением, ADO включает их в доступные записи на выбор. Поэтому, когда указывалось значение столбца для обновления (в случаях, когда он выдает ошибку, столбец первичного ключа), он по очереди обновляет неправильный столбец (с тем же именем). Я знаю, что для ADO нормально использовать первичные ключи для всех подключенных таблиц, но по умолчанию это для ADO, чтобы скрыть их. В нашем случае ADO не скрывает их.

То, что я сузил до этого, является драйвером Native Client SQL, который работает некорректно. Я могу вернуться к драйверу SQL Server (SQL 2000), и он отлично работает, но как только я вернусь к SQL-клиенту SQL, он проявляет вышеприведенное поведение. Я проверил свойства на открытом соединении и свойства самих наборов записей, они совпадают в каждом экземпляре, кроме одного (количество скрытых столбцов имеет смысл, поскольку SQL Native не скрывает их).

Я пробовал все: от удаления папки MSADC из IIS и повторного добавления его, я удалил SQL Native и переустановил его (и впоследствии обновил его до самой новой версии). Я также несколько раз воссоздал соединение ODBC в процессе устранения неполадок. На данный момент я в недоумении.

Также добавляется одна вещь: SQL Native Client отлично работает на наших других серверах, и никто другой не имеет этой проблемы. Кто-нибудь может иметь представление о том, что может произойти? Благодаря!

Edit: Пример того, что происходит (это происходит на любой запрос (хранимой процедуры, если это имеет значение) и с> = 1 присоединяется к любого рода)

выберите temp_id, temp_value на temp_test внутреннее соединение another_table на another_table .temp_id = temp_test.temp_id внутреннее соединение yet_another_table на yet_another_table.another_id = another_table.another_id

это будет производить в АДО записей:

SQL Native Client

(0) temp_id

(1) temp_value

(2) temp_id (первичный ключ another_table)

(3) another_id (первичный ключ пока another_table)

SQL Server драйвер

(0) temp_id

(1) temp_value

SQL Server 2005 будет показывать, как это должно быть: temp_id, temp_value

Answer 1

это происходит на любой запрос (хранимые процедуры, если это имеет значение)

Это не the issue described here это?:

Если изменение в строке соединения изменяет поведение, я бы предположил, что у вас есть две разные схемы, а затем две версии одной и той же хранимой процедуры; и тот, который выполняется с SQL Nativ Client, является неправильным.

Answer 2

У меня точно такой же сценарий, и у нас это уже более года на наших серверах и серверах у нашего клиента. Я никогда не нашел решения, и в результате нам просто нужно использовать драйвер SQL Server, который позор, поскольку SQL Native, кажется, подключается значительно быстрее.

Это не связано с различными схемами или разными версиями одного и того же хранимого устройства, как указано выше. Я использую файл dsn, и просто изменение имени драйвера изменяет поведение в/из упомянутого выше. Кажется, что это происходит со всеми видами (вероятно, сохраненными процедурами тоже, как указано)

Если кто-нибудь найдет решение, я был бы рад услышать об этом.

Warwick