Вообще, то общий доступ в Excel реализован крайне неудачно.
Общий доступ здесь нипричем , машины не в одной рабочей группе . Access навряд ли даст дает преимущества, т.к. трудно будет переписывать уже имеющиеся макросы под новую среду.
Требуется просто отделить имеющиеся макросы от листа ввода данных, в смысле разнести их на 2 разных компа.
Вообще, то общий доступ в Excel реализован крайне неудачно.
Общий доступ здесь нипричем , машины не в одной рабочей группе . Access навряд ли даст дает преимущества, т.к. трудно будет переписывать уже имеющиеся макросы под новую среду.
Требуется просто отделить имеющиеся макросы от листа ввода данных, в смысле разнести их на 2 разных компа.easy_employer
Сообщение отредактировал easy_employer - Вторник, 24.12.2013, 17:36
easy_employer, несколько дополнений: - FTP-сервер надо сразу поднимать прямо на компьютере S. Это, кроме прочего, даст однозначность в вопросе того, что S функционирует и может обрабатывать данные. - дополнительная сигнализация на нижних уровнях о выгрузке пакета тоже становится ненужной... вообще, процесс может быть примерно таким: -- коллизии U разрешаются присвоением каждому клиенту уникального имени/ID, используемого при обмене -- U формирует файл с именем по некоторому шаблону (напр., input<userId><datetime>) и выгружает на FTP -- S периодически опрашивает каталог входящих на предмет появления файлов от user'ов -- при появлении входящего файла - S его забирает (возможно, с удалением из каталога), обрабатывает, сохраняет результат, выкладывает результат на FTP. Исходящие имена тоже формируются по некоторому шаблону (напр., output<userId><datetimeInputFile>) -- U по событию (или периодически) опрашивает каталог исходящих на предмет появления обработанных файлов. При этом U может ожидать как просто поступления информации для себя, так и обработки конкретного загруженного файла -- при появлении выходного файла - U его скачивает, а затем импортирует, куда надо -- естественно, та же FTPшка может хранить и лог обработки данных сервером (например, чтобы U был в курсе того, что на каком этапе процесса находится)
easy_employer, несколько дополнений: - FTP-сервер надо сразу поднимать прямо на компьютере S. Это, кроме прочего, даст однозначность в вопросе того, что S функционирует и может обрабатывать данные. - дополнительная сигнализация на нижних уровнях о выгрузке пакета тоже становится ненужной... вообще, процесс может быть примерно таким: -- коллизии U разрешаются присвоением каждому клиенту уникального имени/ID, используемого при обмене -- U формирует файл с именем по некоторому шаблону (напр., input<userId><datetime>) и выгружает на FTP -- S периодически опрашивает каталог входящих на предмет появления файлов от user'ов -- при появлении входящего файла - S его забирает (возможно, с удалением из каталога), обрабатывает, сохраняет результат, выкладывает результат на FTP. Исходящие имена тоже формируются по некоторому шаблону (напр., output<userId><datetimeInputFile>) -- U по событию (или периодически) опрашивает каталог исходящих на предмет появления обработанных файлов. При этом U может ожидать как просто поступления информации для себя, так и обработки конкретного загруженного файла -- при появлении выходного файла - U его скачивает, а затем импортирует, куда надо -- естественно, та же FTPшка может хранить и лог обработки данных сервером (например, чтобы U был в курсе того, что на каком этапе процесса находится)AndreTM
Skype: andre.tm.007 Donate: Qiwi: 9517375010
Сообщение отредактировал AndreTM - Вторник, 24.12.2013, 18:00
Как вариант,если IP видны с инета,они статичны(этот вопрос можно с провайдером решить). Создать клиент-сервер на компах(аналог аськи) и весь обмен без проблем.
Как вариант,если IP видны с инета,они статичны(этот вопрос можно с провайдером решить). Создать клиент-сервер на компах(аналог аськи) и весь обмен без проблем.doober
Вот не всё так просто. Если делать без сигнального пакета, то S должен сканировать каталог (или FTP) ежесекундно, что нецелесообразно, а с FTP затруднительно. Плюс, при работе по FTP надо сообщать о конце выгрузки файла, иначе сканирующий S возьмет недовыгруженный файл. (Правда это можно обойти с помощью переименования файла после выгрузки).
Да и собственно , если есть возможность работы VBA с TCP, почему бы не сделать всё этим методом ?
Вот не всё так просто. Если делать без сигнального пакета, то S должен сканировать каталог (или FTP) ежесекундно, что нецелесообразно, а с FTP затруднительно. Плюс, при работе по FTP надо сообщать о конце выгрузки файла, иначе сканирующий S возьмет недовыгруженный файл. (Правда это можно обойти с помощью переименования файла после выгрузки).
Да и собственно , если есть возможность работы VBA с TCP, почему бы не сделать всё этим методом ?
Могу создать Аналог аськи. Условие я выше описал IP видны с инета(белые), и статичны. Если не статичны,то при каждом включении надо IP прописывать на компах. Если интересно,поищу у себя ,и сброшу то.что есть для теста. Только обмен сообщениями реализован.но обмен файлами добавить не проблема
Могу создать Аналог аськи. Условие я выше описал IP видны с инета(белые), и статичны. Если не статичны,то при каждом включении надо IP прописывать на компах. Если интересно,поищу у себя ,и сброшу то.что есть для теста. Только обмен сообщениями реализован.но обмен файлами добавить не проблемаdoober
Машина S будет полностью поглощена сканированием каталога ?
Кстати, а какие именно расчёты делаются на S? Может, имеет смысл пересмотреть конфигурацию в сторону полноценного клиент-сервера? То есть на S поднимем SQLExpress, с нужными ХП для обработки, а клиенты - будут просто клиентами БД...
Машина S будет полностью поглощена сканированием каталога ?
Кстати, а какие именно расчёты делаются на S? Может, имеет смысл пересмотреть конфигурацию в сторону полноценного клиент-сервера? То есть на S поднимем SQLExpress, с нужными ХП для обработки, а клиенты - будут просто клиентами БД...AndreTM
Специфические расчеты, которые на сегодняшний день выполняются в рамках одной книги Excel, примерно до 5 секунд на обработку одного запущенного макроса, до 10 запусков у одного юзера в день, а часто и 0. Затык происходит в связи с тем, что поскольку таблицей пользуются 10 человек в разных регионах, то проблематично обновлять синхронно у всех макросы и данные, проблематично проверять обновленность. Соответственно требуется переложить вычисления и данные на сервер.
SQL поднимать по-моему это слишком жирно для данной задачи.
Специфические расчеты, которые на сегодняшний день выполняются в рамках одной книги Excel, примерно до 5 секунд на обработку одного запущенного макроса, до 10 запусков у одного юзера в день, а часто и 0. Затык происходит в связи с тем, что поскольку таблицей пользуются 10 человек в разных регионах, то проблематично обновлять синхронно у всех макросы и данные, проблематично проверять обновленность. Соответственно требуется переложить вычисления и данные на сервер.
SQL поднимать по-моему это слишком жирно для данной задачи.easy_employer
Сообщение отредактировал easy_employer - Вторник, 24.12.2013, 19:21
Реально все,но на скуле удобнее и проще,можно его напрягать в работе процедурами. Вам надо было проинформировать,что не только здесь,но и на других форумах вы опубликовали заказ.
Реально все,но на скуле удобнее и проще,можно его напрягать в работе процедурами. Вам надо было проинформировать,что не только здесь,но и на других форумах вы опубликовали заказ.doober
Если задача "сервера" состоит только в обработке данных пользователя (т.е. нет накопления пользовательских данных на сервере) - то обработка прямо на клиенте будет всегда быстрее. Тем более, если производительность клиентских машин такова, что они способны поддерживать "Офис 2003 и выше". Ибо самое узкое место псевдоКС-системы - это каналы связи, и пересылка данных (плюс достаточно надёжная логика синхронизации) будет занимать больше всего времени. Плюс возможные аварийные ситуации, которые в итоге приводят к возрастанию трафика на пересинхронизацию, переобработку... Если же "сервер" ведёт накопление поступающих и обработанных данных с своей "базе" - то переход к полноценному серверу БД и есть самый эффективный путь решения вашей задачи...
Если задача "сервера" состоит только в обработке данных пользователя (т.е. нет накопления пользовательских данных на сервере) - то обработка прямо на клиенте будет всегда быстрее. Тем более, если производительность клиентских машин такова, что они способны поддерживать "Офис 2003 и выше". Ибо самое узкое место псевдоКС-системы - это каналы связи, и пересылка данных (плюс достаточно надёжная логика синхронизации) будет занимать больше всего времени. Плюс возможные аварийные ситуации, которые в итоге приводят к возрастанию трафика на пересинхронизацию, переобработку... Если же "сервер" ведёт накопление поступающих и обработанных данных с своей "базе" - то переход к полноценному серверу БД и есть самый эффективный путь решения вашей задачи...AndreTM
Если задача "сервера" состоит только в обработке данных пользователя
Да, только обработка данных пользователя. Требуется, чтобы пользователь только заполнял лист "input" и получал готовый новый лист "output". Накопления данных нет. При этом на стороне сервера остается возможность оперативного редактирования таблиц и макросов.
Если задача "сервера" состоит только в обработке данных пользователя
Да, только обработка данных пользователя. Требуется, чтобы пользователь только заполнял лист "input" и получал готовый новый лист "output". Накопления данных нет. При этом на стороне сервера остается возможность оперативного редактирования таблиц и макросов.easy_employer
Тогда я вообще ничего не понимаю... А "на клиентах" есть какое-либо накопление информации (тех же обработанных и импортированных листов)? Или идёт только некое "потоковое заполнение форм", типа "набрали-обработали-напечатали-забыли"?
Просто создается впечатление, что вы придумали ненужную схему. Если вам нужно оперативно распространять меняющуюся бизнес-логику (макросы для обработки вводимых данных, выходные формы и т.д.) - то это проще всего делается с помощью подключения к рабочему клиентскому файлу собственной надстройки, содержащей нужные макросы В вашем случае - дополнительно скачиваемой с ресурса, по какому-либо событию (открытие рабочего файла; нажатие кнопки; сверки штампа файлов перед критической операцией...) и переподключаемой. Если же данные не сохраняются даже на клиенте - то нужно просто "при начале работы" скачивать на клиента копию распространяемого файла, и всё. Для уменьшения нагрузки - можно встроить механизм проверки на изменение версии (запустили загрузчик-сверили версии(-несовпадает-запустили скачку-скачали)-запустили файл).
Тогда я вообще ничего не понимаю... А "на клиентах" есть какое-либо накопление информации (тех же обработанных и импортированных листов)? Или идёт только некое "потоковое заполнение форм", типа "набрали-обработали-напечатали-забыли"?
Просто создается впечатление, что вы придумали ненужную схему. Если вам нужно оперативно распространять меняющуюся бизнес-логику (макросы для обработки вводимых данных, выходные формы и т.д.) - то это проще всего делается с помощью подключения к рабочему клиентскому файлу собственной надстройки, содержащей нужные макросы В вашем случае - дополнительно скачиваемой с ресурса, по какому-либо событию (открытие рабочего файла; нажатие кнопки; сверки штампа файлов перед критической операцией...) и переподключаемой. Если же данные не сохраняются даже на клиенте - то нужно просто "при начале работы" скачивать на клиента копию распространяемого файла, и всё. Для уменьшения нагрузки - можно встроить механизм проверки на изменение версии (запустили загрузчик-сверили версии(-несовпадает-запустили скачку-скачали)-запустили файл).AndreTM
не хотелось бы , чтобы клиент имел доступ к макросам, по крайней мере к значительной их части
Вот это и есть главное в вашем ТЗ, с этого и надо было начинать. Исходя из этого - становится понятным ваше желание разделения техпроцесса именно на такие части. Что же - тогда процесс реализации возможен и так, как предлагалось сначала (через FTP). Кстати, я всё же отказался бы от "сигнальных пакетов" - ведь это актуально только для "сервера", а для него каталог может находиться локально, и доступ к нему - быстрый. "Клиенты" же всё равно будут вынуждены опрашивать каталог по каналам связи, и это убьет весь выигрыш времени. Можно поднять VPN между клиентами и сервером, будет просто общий доступ к SMB-шаре для обмена файлами. Поскольку у вас инициация сеансов всё равно завязана на клиентскую сторону - реализация приватной сети никакой сложности не представляет, вплоть до использования встроенных средств ОС. Естественно, серверная часть обработок не будет присутствовать на этой шаре. :))) Ну или всё же начать реализацию связки Excel-MSSQL. В этом случае получаете полноценное КС-приложение, с масштабируемостью и кроссплатформенностью, хоть на планшетах и утюгах ввод данных делайте...
не хотелось бы , чтобы клиент имел доступ к макросам, по крайней мере к значительной их части
Вот это и есть главное в вашем ТЗ, с этого и надо было начинать. Исходя из этого - становится понятным ваше желание разделения техпроцесса именно на такие части. Что же - тогда процесс реализации возможен и так, как предлагалось сначала (через FTP). Кстати, я всё же отказался бы от "сигнальных пакетов" - ведь это актуально только для "сервера", а для него каталог может находиться локально, и доступ к нему - быстрый. "Клиенты" же всё равно будут вынуждены опрашивать каталог по каналам связи, и это убьет весь выигрыш времени. Можно поднять VPN между клиентами и сервером, будет просто общий доступ к SMB-шаре для обмена файлами. Поскольку у вас инициация сеансов всё равно завязана на клиентскую сторону - реализация приватной сети никакой сложности не представляет, вплоть до использования встроенных средств ОС. Естественно, серверная часть обработок не будет присутствовать на этой шаре. :))) Ну или всё же начать реализацию связки Excel-MSSQL. В этом случае получаете полноценное КС-приложение, с масштабируемостью и кроссплатформенностью, хоть на планшетах и утюгах ввод данных делайте...AndreTM
Вход
Регистрация
Напомнить пароль
Автосумма
Часто используемые
ВПР
ЕСЛИ
СУММЕСЛИ
Финансовые
Логические
Текстовые
Даты и времени 
Ссылки и массивы 
Математические
Другие функции
Проверка свойств и значений
Баз данных
Математические
Обработки массивов
Обработки строк
Преобразования типов данных 
Загрузки данных
Работы с файлами
Обработки системных параметров
Обработки цвета
Работы с датами и временем
Преобразования в системы счисления
Финансовые
