Поиск  Пользователи  Правила 
Закрыть
Логин:
Пароль:
Забыли свой пароль?
Регистрация
Войти
 
Страницы: Пред. 1 2 3 4 5 6
RSS
Excel и Access могут облегчить друг другу жизнь?, как можно совмещать их способности
 
Цитата
БМВ написал:
там даже в документации многое от selection строится
И?
Вариант с копированием и вставкой.
Код
Public Sub cloneColumn()
    Dim cellRange As Range
    Set cellRange = Selection.Cells(1).Range
    cellRange.Expand wdColumn
    cellRange.Copy
    cellRange.PasteAndFormat wdPasteDefault
End Sub
 
вернусь к теме  :)
Цитата
JeyCi написал: ... я пока не могу найти серьёзного повода для перехода с Access на сервер... (по своим объёмам)...

(помимо Индексов, которые надо настраивать на сервере, в отличие от автоиндексации в Access - ранее обсудили скорость работы)...
всё-таки есть один НЕ очень удобный момент в Access:
-- его Синтаксис  :oops: --
1) Запрос в Запросе
- пример Server - здесь - уж очень стройная структура кода с использованием WITH x AS (.....) etc.

Выбор ближайшей (к текущей) прошедшей даты

(также здесь выкладывал Андрей VG  WITH-использование для обхода графа)
- пример Access - надо SELECT'ы расписывать полностью - может становиться малочитабельно при сложных вложенных конструкциях -

мой Выбор ближайшей (к указанной) даты (из др. данных)
когда много SELECT'ов и JOIN'ов бывает (больше чем под спойлером), то даже заменить более структурным видом не возможно в Access...
2) последовательные Запросы (через точку с запятой не выполнить даже в ADO на Access-ном драйвере - до сих пор не получалось)
p.s.
здесь я попробовала подключаться к Server - на всякий случай... - строка подключения - правда к Server Compact Edition
P.P.S
Если в чём не права в п.1 и п.2 - опровержения приветствуются - но у меня сложились такие впечатления по п.1 и п.2
Изменено: JeyCi - 3 Май 2019 16:29:58
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
 
Цитата
JeyCi написал:
Если в чём не права в п.1 и п.2
Вы правы (подпункт про ближайшую дату не смотрел). Собственно, Access SQL не развивается с 97 года.
 
про дату в моём запросе: просто пришлось join'ить по неточному совпадению дат (ввиду неполноты данных).
*****
а вот много JOIN'ов и SELECT'ов и следовательно длинный запрос (другой) - через ADODB.Command выдаёт ошибку E_FAIL ... хотя просто запрос, выполненный в Access, работает (как и более короткая sql-комманда в ADO тоже работает)... а как выкрутиться в ADO с длинным запросом непонятно, т.к. ADO не join'ит, только SQL... а переходить на чистый VBA - уж очень сильно бегать придётся по массиву... вот и подумала "приплыли"... придётся подумать ещё...
интересно, ?? есть ли ограничения по длине строки SQL-запроса при использовании Серверного драйвера и запросе на сервер через ADODB.Command
Изменено: JeyCi - 15 Мар 2019 16:07:35
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
 
а вот и ограничения для Access
Спецификации запроса базы данных Microsoft Access
Атрибут Максимальное значение
Число установленных связей 32 на одну таблицу за вычетом числа индексов, находящихся в таблице для полей или сочетаний полей, не участвующих в связях
Число таблиц в запросе 32
Число полей в наборе записей 255
Размер набора записей 1 Гбайт
Предел сортировки 255 символов в одном или нескольких полях
Число уровней вложения запросов 50
Число символов в ячейке на бланке запроса 1 024
Число символов для параметра в запросе с параметрами 255
Число операторов AND в предложении WHERE или HAVING 40
Число символов в инструкции SQL приблизительно 64 000
Изменено: JeyCi - 15 Мар 2019 15:51:46
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
 
а вот и для SQL Server Спецификация (правдв для 64x):
Длина строки, содержащей инструкции SQL (размер пакета) - 65 536 * размер сетевого пакета (??)
p.s.
и даже на пользователей ограничения (внизу страницы)
p.p.s
когда-то на заре юности  8) ещё здесь у меня возникал этот вопрос... надежда остаётся
(!! хотя работает ведь в Access, только ADO его скушать не хочет длинным !)
Изменено: JeyCi - 15 Мар 2019 16:09:05
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
 
Непонятно в чем проблема. Можно сделать представление для выборки типа "срез последних", и обращаться к представлению как к таблице. Нет?
Неизлечимых болезней нет, есть неизлечимые люди.
 
Цитата
TheBestOfTheBest написал: Непонятно в чем проблема.
TheBestOfTheBest, я вскрыла глюк, но воспроизвести в малом примере для форума не могу пока... вобщем, проблема в вычисляемом выражении с использованием функции EXP()... без этой обёртки в EXP() ИЛИ с тестовым EXP(100) - всё проходит... но внутри должны быть вычисления... сейчас пойду проверять все типы данных - там длинное целое умножается на двойное с плавающей точкой, потом обёртка EXP() - думаю, , может где null'и проскочили и пропустила и не обработала ошибку... думаю, дело всё-таки в шибке, допущенной в функцию -- т.к. встречаются активы-неликвид и в них и считать-то не проходит, как по формуле... только странно, что Access пропускает, а ADO такой же SQL-запрос даёт E_FAIL...
8) пошла оптимизировать... спасибо, (всем!) что заглянули и за ваш view  ...
p.s.
значит дело не в длине запроса, судя по всему...!
Изменено: JeyCi - 17 Мар 2019 10:55:50
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
 
Вывод: Access может показать записи с #Ошибка, ADO из-за них выдаёт E_FAIL без выполнения запроса...
Выход: банально отфильтровать все #Ошибка записи с помощью WHERE и/или JOIN
(в рабочем файле заменила LEFT JOIN на INNER JOIN, и через WHERE не пропускала значения=0 в операцию деления)
всё стало гут ! всем спасибо !
Изменено: JeyCi - 19 Мар 2019 12:30:29
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
 
на этой радостной ноте - думаю, можно, и рассмотреть возможности для Оптимизации работы с БД
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
 
Цитата
TheBestOfTheBest написал: Можно сделать представление для выборки типа "срез последних", и обращаться к представлению как к таблице. Нет?
если Cделать предварительную выборку за нужный период В ТАБЛИЦУ и обращаться к этой таблице - то да, помогает... если к Запросу - то нет, т.к. такая инструкция запроса просто вставляется sql-конструкцией в финальный запрос (ссылающийся на прежний запрос)... беру на заметку: особенно когда запрос об изначальной выборке используется несколько раз в финальном запросе, то, ясное дело, и появляется проблема памяти и скорости в Access, чтобы избежать - начальную выборку через VBA - в отдельную таблицу...
Цитата
JeyCi написал: можно, и рассмотреть возможности для Оптимизации работы с БД
:oops: рассмотрела связь многие-ко-многим в своей схеме  8-0 - разрулила, выделив пару измерений И внеся изменения в Схему БД, и пошла оптимизировать сами запросы ... !!! ... один уже ускорила (2мя шагами из этого поста - 1й от TheBestOfTheBest, 2-й от меня) -- и ускорила запрос с 5мин 30сек ДООООООО 4 СЕК !!!...  :D - это ещё более радостная новость, чем в предыдущем посте... (а то всё удивлялась "чего ж так долго")... и кстати, приняла на заметку совет от АндрейVG (из ранних постов) - разделять сложные запросы на части - глазам стало приятнее  8)
ВЫВОД:
Архитектура - Важна Везде !
(теперь осталось перетряхнуть весь проект)
! Спасибо всем (и другим веткам тоже)  ;)
Изменено: JeyCi - 30 Май 2019 16:36:10
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
 
один нюанс хочется ещё уточнить всё-таки - правильно ли я понимаю Секрет Скорости Сервера по сравнению с Access ?? - заключается в том, что передача данных на сервере идёт по TCP/IP протоколу ,  а в Access, видимо, как-то по-другому? -- отсюда отличие в скорости работы движка Access и SQL Server... (вдруг мне так показалось - права ли я в том, что это главное)... и как по-другому?
p.s.
тогда, наверно, хочется во всех кодовых решениях ходить по TCP/IP протоколу  8) коль такая разница в скорости ... прямо везде, где это возможно - жаль, видимо, даже NET ещё почему-то не подумали об этом?.. [так, мечтаю]
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
 
JeyCi, Нельзя в кучу мешать еще и протокол. Допустим файл с базой access лежит на сетевом диске. Для доступа к нему тоже TCP и UDP будет использован, поверх которого SMB и вот после этого начнется работа с файлом. А вот чтоб дать ответ на вопрос что там такого в SQL что  он лучше Ассеss по скорости - нужно погрязнуть в описании формата файла и особенностях оптимизации движка.
Не скажу что прав , но предположу, что придя в тупик с реализацией на базе MDB многопользовательских решений, когда нагрузка на сеть и сам файл возросла в разы, а при определенном объеме просто все вставало, появился сервер, который снизил нагрузку на сеть и клиента, возвращая только результат запросов. А следом всякие индексы и прочие оптимизирующие его работу фичи, которые уже были направлены на снижение нагрузки и на сам сервер, ведь этот ресурс тоже не безграничен.
 
Цитата
БМВ написал: Допустим файл с базой access лежит на сетевом диске.
тогда понятно, что TCP/IP для обмена данными между базой и локал. компом... действительно, легко проверить можно (ускорится ли) - организовав домашнюю сеть между компом и, например, ноутом [полагаю, имитация того же сетевого диска подручными средствами в домашних условиях (речь не о ssd)]
Цитата
БМВ написал: А вот чтоб дать ответ на вопрос что там такого в SQL что  он лучше Ассеss по скорости - нужно погрязнуть в описании формата файла и особенностях оптимизации движка.
значит всё-таки дело в движке... даже когда ещё не успела задать primary keys и индексы - уже имеется прирост некоторых запросов в 10 и более раз... ок, надо пилить дальше, если придётся... спасибо за ваше уточнение - пролили свет!...
Изменено: JeyCi - 12 Июн 2019 15:27:56
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
 
Цитата
JeyCi написал: имеется прирост некоторых запросов в 10 и более раз...
справедливости ради, стоит отметить, что этот долгий запрос по сути реализация Моделирования "что если" для каждого кортежа таблицы - что соответственно для данных за длинный период даёт длительно выполняемый запрос... в принципе, нет ничего сложного в том, чтобы этот один запрос выполнять периодически за мелкие периоды, а результаты сразу сбрасывать в tbl_result... чтобы при импорте за весь длинный период обращаться к tbl_result, а не снова и снова прогонять этот длинный запрос...
p.s.
это при всём том, что выход из #161# помог разобраться со скоростью выполнения остальных запросов... поэтому не так уж всё страшно - просто нужно разработать нормальную схему БД - и способности Access ещё очень даже упрощают работу по сравнению с файловыми "хранилищами данных" Excel (хоть Access тоже файловый, но скорость работы с 1гб существенно лучше, чем excel - 2й гб я бы советовала оставлять на системные таблицы бд и место для выполнения запросов - всё-таки не забивать до отказа файл access) ... тогда и комфорт работы можно сохранить, выполнив несколько шагов ювелирной подгонки (с помощью vba) под имеющуюся память и для достижения максимально возможной скорости  - вполне себе рабочий вариант под задачу необходимости оперировать последними данными (когда глубоко история уже и не актуальна и особо не нужна - разве что в свободное время поковырять аналитику просто потому что свободное время, если найдётся)
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
 
Цитата
БМВ написал:
особенностях оптимизации движка.
Соглашннусь с Михаилом. Основная проблема Access это отсутствие развития движка. Для сравнения SQLite на настроенных индексах выполняет запросы в 3-4 раза быстрее, чем Access. Так что основная проблема в этом. А проблем превратить Access в клиент серверную версию особых нет. Пишем сервис, транслирующий запросы к движку Access и принимающий результат, в C#/VB.NET и устанавливаем на сервер, где установлен Access Engine. Пишем собственный драйвер-клиент, принимающий запросы и отправляющий их нашему сервису, и принимающий результаты выполнения. Будет клиент-серверная версия Access :)  ничем по существу не отличающаяся от MS SQL Server/
Страницы: Пред. 1 2 3 4 5 6
Читают тему (гостей: 1)
Наверх