Неуспешна ODBC връзка към SQL Server 2008 чрез VPN

Имам добавка за Excel, която позволява на потребителите да изпълняват заявки към база данни на SQL Server и да връщат резултатите директно в електронната таблица. Това работи добре.

Вече има потребител в сателитен офис, който се свързва с нашата мрежа (споделено устройство и т.н.) чрез VPN връзка. Когато той използва същите електронни таблици, които работят за всички в главния офис, тя получава следната грешка:

[DBNETLIB] SQL Server не съществува или достъпът е отказан

Това, което е наистина странно е, че ако стартирате отделна заявка, тя работи добре, но изглежда, че изпълняването на много заявки последователно прави листа глупости. Малко е трудно да се диагностицира, тъй като добавката на Excel изпълнява вътрешни заявки, вероятно много от тях. Моята теория е, че когато DB сървърът види много последователни заявки, идващи от IP, който е извън мрежата, има момент, в който той отказва да върне повече данни.

Има ли валидност моята теория? Има ли промени в конфигурацията, които мога да направя в DB, ​​които ще позволят на отдалечените ODBC връзки да работят добре?


person Paschover    schedule 28.04.2011    source източник
comment
В случай, че се интересувате, проблемът е, че създавах курсор от страна на сървъра и заявките винаги ще изтекат, тъй като трябва да платите на мрежата за обратно пътуване за всяка клетка в набора от резултати. Започна да работи добре, когато превключих на курсор от страна на клиента. Всичко това се използва с ADO. В процес съм на преминаване към SQLApi++.   -  person Paschover    schedule 15.08.2011
comment
Бихте ли променили това на отговора, моля?   -  person Richard    schedule 23.08.2011


Отговори (1)


В случай, че се интересувате, проблемът е, че създавах курсор от страна на сървъра и заявките винаги ще изтекат, тъй като трябва да платите на мрежата за обратно пътуване за всяка клетка в набора от резултати. Започна да работи добре, когато превключих на курсор от страна на клиента. Всичко това се използва с ADO. В процес съм на преминаване към SQLApi++

person Paschover    schedule 30.08.2011