Страницы: Пред. 1 2 3 4 5 6 7 8 9 След.
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 - 03.05.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.03.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.03.2019 15:51:46
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
 
а вот и для SQL Server Спецификация (правдв для 64x):
Длина строки, содержащей инструкции SQL (размер пакета) - 65 536 * размер сетевого пакета (??)
p.s.
и даже на пользователей ограничения (внизу страницы)
p.p.s
когда-то на заре юности  8) ещё здесь у меня возникал этот вопрос... надежда остаётся
(!! хотя работает ведь в Access, только ADO его скушать не хочет длинным !)
Изменено: JeyCi - 15.03.2019 16:09:05
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
 
Непонятно в чем проблема. Можно сделать представление для выборки типа "срез последних", и обращаться к представлению как к таблице. Нет?
Неизлечимых болезней нет, есть неизлечимые люди.
 
Цитата
TheBestOfTheBest написал: Непонятно в чем проблема.
TheBestOfTheBest, я вскрыла глюк, но воспроизвести в малом примере для форума не могу пока... вобщем, проблема в вычисляемом выражении с использованием функции EXP()... без этой обёртки в EXP() ИЛИ с тестовым EXP(100) - всё проходит... но внутри должны быть вычисления... сейчас пойду проверять все типы данных - там длинное целое умножается на двойное с плавающей точкой, потом обёртка EXP() - думаю, , может где null'и проскочили и пропустила и не обработала ошибку... думаю, дело всё-таки в шибке, допущенной в функцию -- т.к. встречаются активы-неликвид и в них и считать-то не проходит, как по формуле... только странно, что Access пропускает, а ADO такой же SQL-запрос даёт E_FAIL...
8) пошла оптимизировать... спасибо, (всем!) что заглянули и за ваш view  ...
p.s.
значит дело не в длине запроса, судя по всему...!
Изменено: JeyCi - 17.03.2019 10:55:50
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
 
Вывод: Access может показать записи с #Ошибка, ADO из-за них выдаёт E_FAIL без выполнения запроса...
Выход: банально отфильтровать все #Ошибка записи с помощью WHERE и/или JOIN
(в рабочем файле заменила LEFT JOIN на INNER JOIN, и через WHERE не пропускала значения=0 в операцию деления)
всё стало гут ! всем спасибо !
Изменено: JeyCi - 19.03.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.05.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.06.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/
 
Андрей VG, спасибо за ТЗ  8) на перспективу... не обязательно с Access... хотя пока ещё смутно представляю такую реализацию... - ? зачем мне заводить сервер для Access Engine... суть в том, чтобы без сервера (или сервером использовать имя локал пк - хотя, в таком случае мы ведь на нём и находимся, когда думаем, что стучим из приложения на c#/vb.net в бд на тот же сервер где находимся - нестыковка получается) ??
(sorry что долго не отвечала - давно была в ветке)
Изменено: JeyCi - 01.07.2019 19:29:03
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
 
Цитата
JeyCi написал:
. суть в том, чтобы без сервера (или сервером использовать
ms sql compact edition не смотрели? работает локально, нужны только dll которые можно хранить вместе с приложением.
но он похоже уже не развивается.
 
Цитата
pharmaprofi написал: ms sql compact edition не смотрели? работает локально, нужны только dll которые можно хранить вместе с приложением.но он похоже уже не развивается.
смотрела... но уже не развивается...
p.s.
спросила, потому что не собираюсь Access ставить на сервер [даже не знаю как], а имею Access на локал пк. - удивилась, зачем по предложенной реализации мне вешать его на сервер и как (если хостинг не имею и не собираюсь) - всё на локал пк .. поэтому суть реализации меня смутила (не уверена что средствами ОС можно сымитировать серверное окружение для Access - понимаю что идея, наверно, глупая, но ради любопытства - а вдруг)...
в принципе прописать connection из c#/vb.net можно как к Access, так и к MS SQL Server... а потом штамповать запросы для выгрузки в txt
Изменено: JeyCi - 02.07.2019 17:25:24
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
 
Цитата
JeyCi написал:
но уже не развивается
ну дак и не для этого он был, писался для мобильных устройств на платформе Windows CE  (собственно и есть Compact Edition), но работал и на старшей ОС, но для старшего брата есть sql server express и функционал конечно не тот что у Standard, но для хранения и запросов достаточен ибо ни реплик, ни
Always On обычно не требуется.
По вопросам из тем форума, личку не читаю.
 
Цитата
JeyCi написал: проблема памяти и скорости в Access
ВЫВОД:
ХОТЬ И в п.2 по линку из #160 - вариант:
Цитата
перенос части вычислений на сторону клиента
- т.к. БД в принципе для хранения данных более чем для сложных математических вычислений...
НО ВСЁ-ТАКИ просто убрав из дооолгих запросов ORDER BY получила ускорение с 8 min до 4 sec  :D ... значит всё дело в этой дурной Автоиндексации, которая выполняется при Order By...
p.s.
чувствовала я, что дело не в RAM здесь в этой ветке... - кстати замеряла потом:
- просто ОС - 37% RAM used при 2гб оперативки
- при открытом Access и выполнении одного из долгих запросов - 47% RAM used
(вот и думала - ну зачем мне наращивать оперативку, если и так 1гб свободен при обычной работе на дом. пк)
p.s.
всё-таки склоняюсь к тому, что 4гб RAM нужны только если на очень динамические и графически объёмные игрушки-стрелялки и др... а для ежедневных задач и 2гб оказывается достаточно... да ещё и один гб в запасе...
p.p.s.
хотя, конечно, для комфортной работы с PQ и PP из БД - (ввиду функциональной, aka рекурсивной, природы PQ) - RAM может дать выигрыш, полагаю... (не замеряла)...
p.p.p.s
сердце болит
Изменено: JeyCi - 09.08.2019 13:54:58
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
 
Цитата
JeyCi написал:
в принципе прописать connection из c#/vb.net можно как к Access, так и к MS SQL Server... а потом штамповать запросы для выгрузки в txt
Вы бы определились чего надо. Access в принципе не быстрый движок, и скорость его работы зависит, в том числе, от железа. Как правило, серверные машины мощнее рабочих станций, плюс к этому внутри SQL серверов есть технологии само оптимизации. Поэтому сервера работаю быстрее не только как отдельная машина, но и на локальной станции. Всякие локальные сервера и БД удобны только тогда, когда требуется разработки переносить на реальный SQL сервер, будет проще адаптировать код, а в некоторых случаях это делается автоматически. Но Access в любом случае пишется на своем коде и здесь вряд ли будет выгода.
На практике для ускорения Access'а используют промежуточные физические таблицы. Пишется процедура, которая формирует физическую таблицу с данными, которые нужны в запросах (одном или нескольким), которые будут предварительно сгруппированы и проиндексированы в этой таблице до выполнения запросов к ней. Далее к ней пишутся запросы. Понятно, что такой подход не гарантирует, что в этой таблице всегда будет свежий массив, но поскольку мы практически в однопользовательском режиме, то вероятность изменения данных в источниках за время исполнения всех запросов ничтожно мала. После получения данных можно таблицу удалить, работать только  рекордсетами запросов.
Что качается дружбы Excel и Access, то кроме драйвера ODBC разработчик ничего не предусмотрел, и это не спроста. Иначе как бы он продавал системы типа Cognos, которые позволяют не только извлекать данные, но и писать их обратно на сервер.
Я лично пользуюсь сторонним драйвером SaveToDB и меня это вполне обеспечивает всем необходимым. Например, я храню историю ежедневного изменения базы в 4000-5000 записей в MSServerLocalDB за 2018-2019 гг, не парюсь по ограничению в 1 млн. записей Excel, вместе с этим получаю в экселе отчеты по любой статистике этих изменений в хорошем компактном виде, могу отборами управлять срезами, в тоже время могу из Excel пополнять этот массив данных. А также:
могу извлекать данные не только Excel, но любым SQL клиентом, например тем же ODBC, который есть у всех сотрудников в офисе;
могу настроить триггеры в MSServerLocalDB таким образом, чтобы промежуточные таблицы обновлялись автоматически при изменении их источника, обновлялись не целиком, а только в той части, которая изменилась - такой функционал предоставляет сервер;
при необходимости весь этот код можно перенести на MSSQLServer 20Ххх 1:1 если вдруг проект требует резкого расширения количества пользователей.
Изменено: TheBestOfTheBest - 09.08.2019 14:48:12
Неизлечимых болезней нет, есть неизлечимые люди.
 
Цитата
TheBestOfTheBest написал: На практике для ускорения Access'а используют промежуточные физические таблицы. ... После получения данных можно таблицу удалить,
да, я в принципе так и сделала - вынесла нужные измерения в отдельные таблицы (оно в принципе и по логике должно быть как Справочники)... просто сначала не хотела отдельно update'ить всегда справочники... думала просто с FlatTable по сути обойдусь... но пришлось делать БД по уму... и конечно даже не удаляю потом эти справочные таблицы... - сначала update их, потом FactTable - чтобы не нарушать целостности, заложенной в схеме БД...
+ какие-то запросы выполняю по мере поступления данных и скидываю в таблицы results - чтобы потом для рабочих моментов просто брать оттуда, без выполнения запросов лишний раз...
стоит и MS SQL Server Express, но всё руки не доходят обустроить его на хороший толк (для объёмов и скорости) - уже проверено - скорость лучше (даже ещё без индексации)... на него - если придётся масштабировать логику на бОльшее количество входных данных... а так инфа за 4мес ~1гб .accdb ... достаточно для рабочих моментов... но иногда хочется и историю видеть ...
===
оптимизирую и исправляю свои косяки...  :oops:
===
а MSServerLocalDB - смущает меня её memory-share природа... наверно же ж в оперативке там что-то крутится??  :oops: не люблю захламлять лишний раз оператив - когда и без оного действа можно справиться... имхо
Изменено: JeyCi - 10.08.2019 17:52:54
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
 
Цитата
JeyCi написал: всё дело в этой дурной Автоиндексации, которая выполняется при Order By...
- это и есть злосчастный вопрос скорости
- в рамках VBA в Access решается с помощью ArraySort - СОМ библиотека на С++ от bedvit
thanks a lot !!! разработчику
Изменено: JeyCi - 22.08.2019 07:42:29
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
 
Рад, что пригодилась. Код должен работать, а не отдыхать в библиотеке :) По всем замечаниям жду обратную связь.
Изменено: bedvit - 22.08.2019 09:44:04
«Бритва Оккама» или «Принцип Калашникова»?
 
сама очень рада, что сработало :)
только arr в который собираем из RS
надо объявить как
Dim arr() As String
иначе  Type значений переменных в массиве, как Variant/String не является допустимым, только String...
а так  - всё very good и очень скоростными темпами...
для сортировки выборок из Access по vba - самое то!...
а если переходить на сервер, то там и родной Order By вроде должен справляться - не тормозить...
P.S.
2 млн строк не отсортирует на 2х гб RAM 2.8 ггц 2ядра (даёт out of memory) - но 500 000 всё ок - хотя у меня даже столько не бывает... по столбцам не помню сколько тестила - из вашего примера там ... и что-то ещё открыто было (т.е. тоже занимало RAM)... вот такие results
Изменено: JeyCi - 22.08.2019 12:13:27
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
 
Да, сейчас только String.
Цитата
JeyCi написал:
2 млн строк не отсортирует на 2х гб RAM 2.8 ггц 2ядра (даёт out of memory)
на каком массиве, с какими параметрами? Пример сможете приложить? В Excel отрабатывает такой же массив?
Этот код отрабатывает на 2 млн. строк?
Изменено: bedvit - 22.08.2019 17:22:07
«Бритва Оккама» или «Принцип Калашникова»?
 
bedvit, вспомнила - брала тот ваш массив и ваш код, получала сбои на разных этапах вашего тестирования... ArraySort1 ещё не видела - посмотрю...
p.s.
кстати в Borland книге, куда оставляла линк в той ветке, - видела ~121стр, есть какие-то обработчики для такого рода исключений - т.е. при приближении к этому (out of memory) выкинуть предупреждение о нехватке памяти...  8) и в скобках (~123 стр) о том, что "ниже" описано, что обработчик делает, чтобы выделить ещё памяти -- но не нашла это "ниже" ещё  :oops: ... пока много всего перетрясти надо в своих кодах - смотрю новый яз лишь на досуге, но уж очень интересный он...
Изменено: JeyCi - 23.08.2019 17:57:37
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
 
на этот раз 2млн отсортировались... а 3млн дали сбой... и после сбоя - проблема IVBA failed при повторном запуске сортировки... пока что так... на 2х COM...
на скринах отметила последовательность возникновения проблемы - скрин1 и скрин2
Скрытый текст

P.S.
может как-то такое поможет?.. если связано с bad_alloc?.. но после отлова - всё равно что-то надо делать - может как-то скидывать в файл-подгрузки на жёсткий диск?
Изменено: JeyCi - 24.08.2019 11:27:16
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
 
JeyCi, это тестируются разные сочетания с разными размерностями массива. Попробуйте потестировать, только нужный вам вариант, а не все. Видимо где-то заканчивается память. Спасибо за описание, нужно разобратся в каком варианте это происходит. У вас, случаем, не х32 система?
Скажу по секрету скоро будет вариант сортировки через Variant.
Изменено: bedvit - 24.08.2019 14:23:27
«Бритва Оккама» или «Принцип Калашникова»?
Страницы: Пред. 1 2 3 4 5 6 7 8 9 След.
Наверх