anvgДа не здесь. Диалог "Свойства подключения", вкладка "Использование" сбросить галку "Фоновое обновление". Или если программно обновляете, то QueryTable.Refresh False
Ура! Наконец то получилось. Надо было снять Фоновое обновление, обновить, сохранить и только потом обновить подключение с SQL-запросом к листам.)

ferzmikkanvgПотом FULL JOIN не работаДля обращения к листам Excel используется движок Access, а он года с 97, в плане SQL, не развивается. Там есть только Left Join, Right Join, Inner Join
Пытаюсь использовать функцию ROW_NUMBER, не работает чего то. Может быть ограничение из за этого. Есть где нибудь список функции и возможностей , которые можно применять, а также которые не будут работать для обращении к excel листам, но предлагаются альтернативы ?

anvgКто бы его составил, раз сразу поиском не находится. По зарезервированным словам . По функциям можно посмотреть в самом Access, а можно и поискать давайте сделаю это за вас ;)
Спасибо!)

anvgДля обращения к листам Excel используется движок Access, а он года с 97, в плане SQL, не развивается.
Мне вот интересно узнать. Если это так, то на сегодняшний день наверняка есть другая наиболее оптимальная технология выгрузки данных.

У меня ситуация такая. Безусловно, самый лучший вариант это выгружать данные из сервера с помощью SQL-запроса. Но не разрешают пользоваться. Есть OLAP. Если делать MDX-запросы, то запросы получаются очень большими и запутанными. А также MDX не соединяет таблицы как SQL, имеет другую логику. Поэтому делаю так: на каждый excel-лист выгружаю данные с OLAP и потом запускаю SQL-запрос с ограниченным функционалом к этим листам, соединяются таблицы как надо, расчеты разные и выводит результат на другой лист. Сам SQL-запрос очень большой. Я трачу много времени на экспериментирование, изучение тонкостей, написание запроса учетом ограничении функционала. Может для данной ситуации есть наиболее оптимальное решение? Учитывая такой логический нюанс, что разрабатываю инструмент, который формирует нужный отчет нажатием одной кнопки с помощью макросов, и запускать будут другие пользователи.

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

У меня Microsoft Office 2007. Windows 7. Тип системы - 64. Сегодня установили Бизнес скайп. В пуске появилась папка "Средства Microsoft Office 2016". Пишет что не может загрузить драйвер. Потом восстановили. Как то странно работает. Теперь вылезает такая ошибка в экселевском файле при создании подключения к листу. Что делать?

Пытаюсь в запросе использовать временную таблицу. Пишу запрос с использованием INTO. Такая функция должна работать в Microsoft Access SQL.


Запускаю. Выдает сообщение об ошибке. Здесь возможно использовать временные таблицы путем INTO или надо по другому делать? Если разрешить доступ к базе данных, в даннном случае к листу, то логически как временную таблицу можно поместить на лист, если там находятся исходные данные?

Если написать такой запрос

то выдает сообщение об ошибке.

Похоже WITH для сохранения промежуточного результата запроса не поддерживается

На моем локальном компьютере обновление происходит нормально. Но на другом компьютере - вылезает сообщение.

Свободных гигабайтов на диске много. Возможно установлена квота (2 гигабайта). Где найти и увеличить эту квоту? И возможно ли определить размер необходимой квоты?

Может быть есть смысл изменить строку подключения и указать максимальным размер базы?

GaryaОбойти его можно, храня разные таблицы в разных базах данных.
Есть несколько листов, где на каждом листе одна таблица и запускается локальный SQL-запрос к этим листам и выводит результат на отдельный лист. Я правильно понимаю, что в данном случае, только разбить локальный SQL-запрос на два запроса с промежуточным результирующим листом?

GaryaferzmikkСвободных гигабайтов на диске много. Возможно установлена квота (2 гигабайта). Где найти и увеличить эту квоту? И возможно ли определить размер необходимой квоты?Это ограничение ядра MS JET, посредством которого происходит работа с данными БД MS Access и/или MS Excel.
Обойти его можно, храня разные таблицы в разных базах данных. Либо используя MS SQL Server - у него ограничение размера БД до 10 Тб.
Если передать все расчеты на Access, то там тоже будет такое ограничение?

Фишка в том, что данные выгружались по одному городу и такое ограничение вылезает. Но надо будем по всем городам. Access сможет как то обработать?

Bobgosferzmikk,
Вам действительно нужен Access или просто ломает от мысли перевода уже сделанного на MS SQL или Oracle ?
У нас есть OLAP, оттуда выгружаются разные таблицы и заталкиваются в каждый лист. Потом сложный SQL запускает. Приходится промежуточные таблицы вставлять в дополнительных листах (это случаи, когда подзапрос повторяется). Потом макросом добавлять дополнительные поля. Для такого случая excel не идеально подходит.

MS SQL не продоставляют, так как будет влить на основные процессы, поэтому ищу возможные пути реализации.

Чтобы все города выгружать в Access я вижу такое решение: с помощью цикла выгружать по отдельному городу обрабатывать с помощью SQL. И выводит в конечную таблицу. Аналогично для остальных городов, и полученные строки добавляет в эту конечную таблицу. В итоге получится обработанная конечная таблица по всем городам. Понятно, что эту таблицу нельзя поместить в Excel целиком, тут либо по городам, либо без разбивки по SKU. Тут другой вопрос. Вот Access сможет ли выдержать такую конечную таблицу просто для хранения обработанных данных?

vikkivкстати в твоём случае для работы на SQL достаточно минимальных прав хотя-бы на TempDB, главное чтобы там дрова нужные стояли (вроде ACE) и OpenQuery/OpenRowSet были разрешены.. тогда сможешь использовать обычный T-SQL в Temp пространстве для работы со всеми внешними запросами, ну и Join-ить как вздумается SQL с MDX результатами..
Там есть такая возможность настроить, чтобы запущенные нужные запросы на сервере не сильно тормозили основные главные процессы?

Получается надо будет предоставить некоторым пользователям эти права, кто будет запускать такой запрос.

vikkivкстати в твоём случае для работы на SQL достаточно минимальных прав хотя-бы на TempDB, главное чтобы там дрова нужные стояли (вроде ACE) и OpenQuery/OpenRowSet были разрешены.. тогда сможешь использовать обычный T-SQL в Temp пространстве для работы со всеми внешними запросами, ну и Join-ить как вздумается SQL с MDX результатами..
Тут вместо TempDB можно использовать Табличную переменную? Или у TempDB больше возможностей?