Виталий Перевозчиков,

Я так понимаю это общеизвестная проблема. Посмотрел код выполняющийся на sql сервере, хотелось бы услышать мнение sql dba (cам по oracle), там для получения данных используются api курсоры, которые не совсем оптимально используют ресурсы сети (выполняют много вызовов).
Известная проблема 1С 7.7. SQL просто забивается тысячами и десятками тысяч мелких запросов. Какого-то простого решения не имеет. 1С просто работает с SQL ровно так же, как и с DBF.
тут наши программисты сами делают для себя, потом они эти копии на своих машинах разворачивают, вот они и жалуются
База видно маленькая, если программисты разворачивают свои копии, конвертируя её в DBF.
Зря.
Во-первых, лишняя трата времени и ресурсов компьютера.
Во-вторых, оптимизация под DBF отличается от SQL и лучше, если разработчик отлаживает тоже под SQL. Вот так пишут обращение к базе выборками (на DBF они быстрее), потом удивляются, чего оно на SQL тормозит.
Поставьте разработчикам локальные developer версии SQL (если вдруг express не хватает по ограничениям). Даже если требуется легальность, developer версия стоит тысячи полторы рублей.

Виталий Перевозчиковвсе так плохо?
Всё плохо с точки зрения быстродействия, но очень даже не плохо с точки зрения повышения понятности кода запросов и понижения планки "входа в специальность". Зубодробительный SQL запрос из двух десятков JOIN и полусотни CASE на языке запросов 1С зачастую записывается легко и понятно. Правда работает в десяток раз медленней и в ряде случаев SQL запрос нельзя записать на языке запросов 1С. Функциональность таки не идёт ни в какое сравнение.

Виталий Перевозчиковтут имеется ввиду выгрузка всей БД средствами 1С, а не выгрузка каких то определенных данных.
Если выгрузка для создания архива, то нафиг. Выгружайте средствами SQL. Если требуется первичная выгрузка при создании новой периферийной базы, то можно сделать копию центральной (средствами SQL естественно), потом опять таки посредством SQL удалить из неё лишние данные.