Привет всем! Помогите, пожалуйста, разрешить ситуацию. Я работаю с большими объемами данных в Access, и при выполнении некоторых запросов появляется ошибка 3183: "Недостаточно места на временном диске". Сжатие файла не помогает, удаление лишних таблиц тоже. Уменьшать количество записей нельзя. Подскажите, как увеличить размер временного диска и что это вообще собой представляет. Заранее спасибо.
-
Познакомьтесь с пентестом веб-приложений на практике в нашем новом бесплатном курсе
- Статус
На С свободно 8 Гб, там, где база - 20 Гб. Пробовала ставить двойное ограничение (дважды ставила условия в запросах) на количество записей. С небольшими объемами сработало. С большими - зависает компьютер.
У нас была проблема когда Access казалось что места мало а на самом деле было слишком много .. он неверно считал объём свободного места ... правда это было в 2000 версии ...
Надо переходить с Access на чтонибудь приличное, не расчитат он на объемы у него другие задачи. С объемами пожалуйте на MS SQL.
Посмотри файл подкачки, особенно в момент этих вот запросов. на сколько он используется? Если на 100% попробуй увеличить вручную.
Если данных очень много, то для этого лучше использовать сервер БД. База Access не подходит для хранения больших объемов данных. Например, я использую mySQL 5. При этом меняется подход к разработке и возрастает скорость выполнения запросов. Для работы с БД не стоит делать связанных таблиц ODBC, лучше воспользоваться запросами к серверу (В режиме конструкруктора запроса в меню "Запрос"->"Запрос SQL" выбрать "К серверу"). Програмно лучше работать через ADO, она быстрее работает с серверами чем DAO, несмотря что через ODBC. Временные таблицы (результатов расчетов), можно хранитьв БД Access.
Если используется Access 2002 и выше, то можно перейди на проект Access и MS SQL Server. C этия я не работал.
Если используется Access 2002 и выше, то можно перейди на проект Access и MS SQL Server. C этия я не работал.
Для: BOPOHA
Не стоит сбивать человека.. ADO и DAO это одно и тоже DAO - data access objects это предыдущее название ADO - active data objects ... А ODBC (...(???) database connection) - это вообще другая песня ... никакого отношения к ADO или DAO не имеющая...
Не стоит сбивать человека.. ADO и DAO это одно и тоже DAO - data access objects это предыдущее название ADO - active data objects ... А ODBC (...(???) database connection) - это вообще другая песня ... никакого отношения к ADO или DAO не имеющая...
Тот факт что DAO и ADO 2-е совершенно разные библиотеки доступа к данным. DAO создана специально для Access (+ c возможностью работать с другими БД через интерфейс ODBC), а ADO - новая библиотека работающая совершенно по другому принципу (OLE DB) и ориентирована на сервера (в частности MS SQL Server).
ODBC - Open DataBase Connection - общий интерфейс работы с любыми базами данных (устарел), был бы драйвер для этой БД.
При работе из Access c сервером mySQL меня интересовала произовдительность. Оказалось, что хранимый запрос к серверу выполняется почти мнгновенно (по сравнению с запросом к большей таблице Access и связанной таблицей к серверу). И подключается этот запрос через интерфес ODBC. Когда встает вопрос программно работать с табличками на сервере библиотек ADO оказывается производетельней и работает она через следующие интерфейсы: ADO -> OLE DB Provider -> ODBC -> MySQL ODBC 3.51 Driver -> mySQL сервер.
Для DAO цепочка следующая DAO -> ODBC -> MySQL ODBC 3.51 Driver -> mySQL сервер.
В Access можно использовать одновременно две библиотеки DAO и ADO, достаточно добавить на них ссылки. Только объявлять объекты нужно с использованием имен библиотек:
Два выше объвленых наборов между собой не совместимы
совсем забыл:
DAO - Data Access Objects
ADO - ActiveX Data Objects (новая библиотека по отношению к DAO)
ODBC - Open DataBase Connection - общий интерфейс работы с любыми базами данных (устарел), был бы драйвер для этой БД.
При работе из Access c сервером mySQL меня интересовала произовдительность. Оказалось, что хранимый запрос к серверу выполняется почти мнгновенно (по сравнению с запросом к большей таблице Access и связанной таблицей к серверу). И подключается этот запрос через интерфес ODBC. Когда встает вопрос программно работать с табличками на сервере библиотек ADO оказывается производетельней и работает она через следующие интерфейсы: ADO -> OLE DB Provider -> ODBC -> MySQL ODBC 3.51 Driver -> mySQL сервер.
Для DAO цепочка следующая DAO -> ODBC -> MySQL ODBC 3.51 Driver -> mySQL сервер.
В Access можно использовать одновременно две библиотеки DAO и ADO, достаточно добавить на них ссылки. Только объявлять объекты нужно с использованием имен библиотек:
Код:
Dim rstDAO As DAO.Recordset
Dim rstADO As ADODB.RecordsetДва выше объвленых наборов между собой не совместимы
Код:
Set rstDAO = rstADO '-- нельзясовсем забыл:
DAO - Data Access Objects
ADO - ActiveX Data Objects (новая библиотека по отношению к DAO)
Спасибо всем за помощь! Я, конечно, могу перейти на MySQL, но я не знаю всех его фишек, а изучать нет времени и желания. Но, самое интересное, что пока вы ничем не могли мне помочь, кроме отрицательного отношения Access, я смогла доделать отчеты.
Каким-то образом, тип связей в запросах стал напрягать программу, после того, как я облегчила связи и сделала некоторые дополнительные условия, увеличила объем памяти и размер файла подкачки, я смогла все-таки добиться результата. Но надолго ли?
Каким-то образом, тип связей в запросах стал напрягать программу, после того, как я облегчила связи и сделала некоторые дополнительные условия, увеличила объем памяти и размер файла подкачки, я смогла все-таки добиться результата. Но надолго ли?
Для: Елена Припихайло
Вы правы. Я совсем забыл еще об несколько способов оптимизации.
Итак, первый:
У меня была ситуация, когда необходимо было хранить информацию о ~130 000 организациях в год. С целью последующего анализа. Реализация была следующая: предприятия хранились в отдельных таблицах по годам.
В этом случае потребовалось реализовывать переход на следующий год и функции формирования имен таблиц. Если бы не нужно было проводить анализ за несколько лет одновременно таблицы хранились бы в раздельных файлах mdb.
Второй:
Уменьшить размер записи в таблицы. Например, за счет переноса полей (особенно, MEMO) в другую таблицу. Оптимизировать размер полей. Например: для поля месяцев хватит размера "Байт". Особенно внимательно необходимо отнестись к текстовым полям.
Третий:
Разбить таблицу на две таблицы. Например, если часть записей заполняются для ограниченного числа записей, то вынести их в отдельную таблицу.
Четвертый:
Удалить не нужные индексы (они могут занимать 50% от размера таблицы, особенно по текстовым полям), а добавить только необходимые, например:
Составные, если часто используется выборка по нескольким полям одновременно.
Добавить индексы по полям, которые используются для объединения таблиц.
Оптимизация индексов увеличит скорость выполнения запросов.
Пятый:
Оптимизация самих запросов. Выбирать только те поля, которые нужны. Уменьшить количество таблиц: например, убрать справочники, их можно подключить на самом отчете. Стараться сделать запрос более селективным - уменьшить объем выбираемых записей при помощи условий отбора. Заменить вложенный запрос в выражении условия на значения, которые он возвращает (если конечно это возмоно). Постараться избежать преобразований типов данных при выполнении запроса: например, текст в число, дата в текст и наоборот. Постараться, использовать только стандартные функции SQL (Sum(), First() и т.д.).
Шестой:
Использование временных таблиц (которые могут распологаться во временной БД). При расчете часть данных можно добавлять во временные таблицы, для дальшейшего расчета. Или для расчета в коде с минимальным использованием запросов. На основании временной таблицы может работать отчет.
Вы правы. Я совсем забыл еще об несколько способов оптимизации.
Итак, первый:
У меня была ситуация, когда необходимо было хранить информацию о ~130 000 организациях в год. С целью последующего анализа. Реализация была следующая: предприятия хранились в отдельных таблицах по годам.
В этом случае потребовалось реализовывать переход на следующий год и функции формирования имен таблиц. Если бы не нужно было проводить анализ за несколько лет одновременно таблицы хранились бы в раздельных файлах mdb.
Второй:
Уменьшить размер записи в таблицы. Например, за счет переноса полей (особенно, MEMO) в другую таблицу. Оптимизировать размер полей. Например: для поля месяцев хватит размера "Байт". Особенно внимательно необходимо отнестись к текстовым полям.
Третий:
Разбить таблицу на две таблицы. Например, если часть записей заполняются для ограниченного числа записей, то вынести их в отдельную таблицу.
Четвертый:
Удалить не нужные индексы (они могут занимать 50% от размера таблицы, особенно по текстовым полям), а добавить только необходимые, например:
Составные, если часто используется выборка по нескольким полям одновременно.
Добавить индексы по полям, которые используются для объединения таблиц.
Оптимизация индексов увеличит скорость выполнения запросов.
Пятый:
Оптимизация самих запросов. Выбирать только те поля, которые нужны. Уменьшить количество таблиц: например, убрать справочники, их можно подключить на самом отчете. Стараться сделать запрос более селективным - уменьшить объем выбираемых записей при помощи условий отбора. Заменить вложенный запрос в выражении условия на значения, которые он возвращает (если конечно это возмоно). Постараться избежать преобразований типов данных при выполнении запроса: например, текст в число, дата в текст и наоборот. Постараться, использовать только стандартные функции SQL (Sum(), First() и т.д.).
Шестой:
Использование временных таблиц (которые могут распологаться во временной БД). При расчете часть данных можно добавлять во временные таблицы, для дальшейшего расчета. Или для расчета в коде с минимальным использованием запросов. На основании временной таблицы может работать отчет.
Возник еще один вопрос, который я не могу решить сама. Дело в том, что мой системный администратор не дает мне доступ админа на компьютере. После установок-переустановок, видно сбились какие-то настройки, связанные с администрированием Office. В результате на импорт-экспорт, запросы на создание Access ругается: "Ошибочный аргумент (ошибка 3001)". Переустановила Access - не помогло. Узнала пароль админа - зашла под админом, оказалось. что БД настроены на Access2000, причем запустила свои запросы - заработало. После переустановки Офиса в режиме администратора перестала БД работать и в режиме админа. Неужели, если я работаю в Access 2003? мне нужно настраивать БД под 2000?
Да, переход на 2000 в параметрах, не помог
Да, переход на 2000 в параметрах, не помог
Я не думаю что права могут повлиять на выполнение запросов в Access. Сам я работаю без прав администратора. Проблемы были только с безопастностью в Access и тем фактом, при в параметрах Access 2003 указано, что по умолчанию создавать БД в формате Access 2000.
Мне не совсем понятна проблема. Что значит "БД настроены на Access2000" и "нужно настраивать БД под 2000".
Мне не совсем понятна проблема. Что значит "БД настроены на Access2000" и "нужно настраивать БД под 2000".
- Статус
Обучение наступательной кибербезопасности в игровой форме. Начать игру!