DBEng32 (5.1.3.2, CodeBase 6.5) - клиент/серверное использование DBFной версии 1С:Предприятие 7.7
Разработка - Разработка внешних компонент
Бесплатные
ВНИМАНИЕ: Файлы из Базы знаний - это исходный код разработки. Это примеры решения задач, шаблоны, заготовки, "строительные материалы" для учетной системы. Файлы ориентированы на специалистов 1С, которые могут разобраться в коде и оптимизировать программу для запуска в базе данных. Гарантии работоспособности нет. Возврата нет. Технической поддержки нет.
Узнавайте о новых бесплатных решениях в нашей телеграм-группе Инфостарт БЕСПЛАТНО
| Наименование | Скачано | Бесплатно |
|---|---|---|
|
BIN_CB_5132.ZIP
.zip 2,74Mb
394
|
394 | Скачать бесплатно |
|
-
.1235784920 2,74Mb
380
|
380 | Скачать бесплатно |
Вы можете заказать платную доработку или адаптацию этой разработки под вашу конфигурацию на «Бирже заказов».
- 0% комиссии — оплата напрямую исполнителю;
- Исполнители любого масштаба — от отдельных специалистов до команд под проект;
- Прямой обмен контактами между заказчиком и исполнителем;
- Безопасная сделка — при необходимости;
- Рейтинги, кейсы и прозрачная система откликов.
Объявление от 30.03.2010.
Выяснилось, слишком поздно, что "CodeBase 6.5" не обеспечивает требования ACID в части Isolation (изоляции). Т.е., например, если в одной сессии 1С проводится документ, то в другой сессии могут быть прочитаны измененные и не изменённые строки документа и движения до полного завершении или отката транзакции в первой сессии. Этого не происходит, если обе сессии выполняют и запись и чтение данных в транзакции, т.к. средствами 1С обеспечивается последовательное выполнение транзакций. Но сессии, в которых, например, формируется отчет, будут получать противоречивые данные.
Кроме того, принятый в "CodeBase 6.5", алгоритм выполнения транзакций не обеспечивает должного уровня надежности в режиме "stand-alone" (в моей разработке названо - ПДБД).
Выводы:
1) Данный "проект" - закрыт.
2) Публикация не удаляется ради данного объявления.
3) Дистрибутивы не удаляются, чтобы дать возможность пользователям использовать последнюю версию разработки для успешного переноса своих баз данных на другие СУБД.
4) Я не стал связываться с разработчиками "CodeBase 6.5" по данной проблеме. Т.к., думаю, они не считают это проблемой, если изначально заложили в своей системе такие алгоритмы работы с транзакциями.
Определение термина Isolation из http://ru.wikipedia.org/wiki/ACID
"Во время выполнения транзакции другие процессы не должны видеть данные в промежуточном состоянии. Например, если транзакция изменяет сразу несколько полей в базе данных, то другой запрос, выполненный во время выполнения транзакции, не должен вернуть одни из этих полей с новыми значениями, а другие с исходными."
В этой цитате, для нашего случая, нужно читать слово "поле" как слово - "запись".
Объявление от 12.09.2007.
Обнаружена ошибка в CodeBase.
В режиме ПДБД при монопольном запуске сессии 1С активизируются, по умолчанию, режим оптимизации операций ввода/вывода. Если при таких условиях выполняется задача по дополнению записей в таблицы с применением транзакций и после ряда успешно выполненных транзакций выполняется откат очередной транзакции, то это приводит к порче DBF файла. Ошибка “плавающая”, т.е. зависит от размера памяти отведённой под оптимизацию операций ввода/вывода, размера и количества успешно выполненных транзакций и т.д. Я предоставил информацию об этой ошибке в Sequiter Inc. Получен ответ: “We have reproduced this problem. We will continue to investigate and let you know what the solution is.”. До окончательного решения проблемы рекомендую установить единицу в строке № 14 файла DBEng32.ini. В режиме клиент/сервер эта ошибка не наблюдается.
Объявление от 28.11.2007.
Ошибка в CodeBase исправлена в версии 5.1.2.8.
Вступайте в нашу телеграмм-группу Инфостарт
См. также
Разработка внешних компонент Разработчик 1С:Предприятие 7.7 1С:Предприятие 8 Абонемент ($m)
PDFConverter — высокопроизводительная нативная компонента для работы с PDF-документами в среде 1С:Предприятие 8.
10 стартмани
20.03.2026 1768 19 v_peroff 8
Разработка внешних компонент Разработчик 1С:Предприятие 7.7 1C77 Абонемент ($m)
Внешняя компонента позволяет в среде 1С 7.7 работать с ZIP-архивами: создавать архивы, читать их и разархивировать.
1 стартмани
29.05.2025 2925 3 mdbruyfn 2
Разработка внешних компонент Разработчик 1С:Предприятие 7.7 1C77 Абонемент ($m)
Компонента позволяет в среде 1С 7.7 генерировать двухмерный QR код из любого текста длиною до 1800 символов и сохранять его в файле BMP формата. Из файла он может быть загружен в объект 1С "Картинка".
1 стартмани
29.01.2025 3404 6 mdbruyfn 4
Разработка внешних компонент Системный администратор Разработчик 1С:Предприятие 7.7 1С:Предприятие 8 Россия Платные (руб)
Аддон "Структура Обмена" (ExchangeStruc) - это компонента, которая обеспечивает доступ к разделяемым процессом структурам, аналогичным структурам 1С. Обеспечивает прозрачную передачу данных примитивных типов, в том числе Двоичных данных, в режиме Реального времени между разными контекстами (формами) или потоками одного процесса. В перспективе функционал будет расширен для обмена между процессами, даже разных версий платформ. Совместим с версиями Windows рабочих станций и серверов, с платформами 1С разных версий и релизов в режиме Native начиная с 8.2, и в режиме COM начиная с версий 7.7. По скорости чтения и записи лишь немногим уступает стандартной структуре 1С. НОВОЕ: Добавлен функционал регистрации компоненты COM в качестве OLE Auto (COMОбъект) для поддержки её работы в серверах старых версий 1С: 8.0 и 8.1, где работа с компонентами исключена. Теперь можно коммуникацию с Фоновыми заданиями на этих версиях проводить.
7320 руб.
19.04.2023 7319 1 0
Разработка внешних компонент WEB-интеграция Разработчик 1С:Предприятие 7.7 1C77 Платные (руб)
Компонента HttpSrv7 позволяет создавать веб-сервисы в среде 1С 7.7 и, используя файлы HTML, несложные веб-сайты. С помощью нее можно обеспечить доступ к данным 1С 7.7 из браузера. Дополнительно используя компоненту HTTP_Async можно наладить обмен данными между удаленными информационными базами по протоколам HTTP, HTTPS и WebSocket. С помощью компоненты HttpSrv7 используя протокол WebSocket можно создавать и поддерживать работу нескольких чатов. С помощью компоненты HTTP_Async можно асинхронно отправлять HTTP-запросы к сайтам, веб-сервисам (в т.ч. к HTTPSrv7) и обрабатывать ответы по мере их поступления. Компонента GISMT в дополнение к HTTP_Async имеет функцию цифровой подписи в формате Base64 и, таким образом, имеет все возможности для работы с API ГИС МТ "Честный знак" непосредственно из среды 1С 7.7.
6100 руб.
27.05.2022 13641 2 20
Разработка внешних компонент Разработчик 1С:Предприятие 7.7 Платные (руб)
Компонента для выбора значения из больших списков значений.
5084 руб.
02.12.2021 8342 3 19
Разработка внешних компонент Файловый обмен (TXT, XML, DBF), FTP Разработчик 1С:Предприятие 7.7 1C77 Абонемент ($m)
Эта внешняя компонента Base64.dll предназначена для платформы 1С версии 7.7. Используется для преобразования файлов из/в кодировку Base64 из встроенного языка 1С Предприятие. Компонента тестировалась на базе конфигурации Бухгалтерский учет для Казахстана, редакции 7.70.257.
10 стартмани
06.04.2021 13299 15 softmaker 18
Разработка внешних компонент Защита ПО и шифрование Обмен с ГосИС Разработчик 1С:Предприятие 7.7 1C77 Абонемент ($m)
Цифровые подписи, шифрование, просмотр сертификатов ключей ЭЦП, работа с различными криптопровайдерами (в т.ч. КриптоПРО ГОСТ 2012) в 1С 7.7, получение ЭЦП в формате BASE64 для работы с API ГИС "Честный знак"
2 стартмани
08.06.2020 12019 33 mdbruyfn 10
Получилось восстановить из кэша гугла обсуждение разработки на 21 декабря 2006 года - почитал дисскусию, так что глупых вопросов задавать не буду.
Я так понял - вы в курсе что 1С++ использует возможность организации прямых запросов к DBFной (xBase'ой версии) 1С Предприятия через объект OleDBData и провайдера vfpOleDB...
вообщем буду изучать...
ЗЫ А как так получилось что обсуждения удалились и на 1С.proclub и здесь... Видимо это намеренно было сделано? Поэтому еще раз прошу прощения за повтор вопросов
“…возможность организации прямых запросов к DBFной…1С Предприятия через объект OleDBData и провайдера vfpOleDB...”
При использовании сервера CodeBase с моей разработкой можно организовать такие прямые запросы. Но для этого надо:
1) Использовать FoxPro совместимый формат DBFов, т.е. вернуться к ограничению размера DBF файла в 1 гигабайт.
2) Отключить оптимизацию ввода/вывода на стороне клиента, т.е. снизить производительность системы на стороне сервера.
3) Учесть, что прямые запросы будут выполняться в режиме файл сервера, т.е. по сети будет передаваться больше информации, чем в случае технологии клиент/сервер.
4) Учесть при программировании такие особенности как, например, недоступность прямому запросу данных обновлённых внутри собственной транзакции.
5) Не выполнять в этих запросах модификацию данных, т.к. могут возникнуть конфликты с алгоритмами модификации данных из штатных средств 1С (клинчи, транзакции и т.д.).
Таим образом “сведутся на нет” основные преимущества моей разработки. Если и делать средства прямых запросов на SQL к серверу CodeBase, то надо использовать SQL надстройку от Sequiter Inc и не через ODBC и прочие аналогичные средства, а на уровне CodeBase Engine API. И включать это средство в РУС.
“А как так получилось что обсуждения удалились и на 1С.proclub и здесь...”
Они удалились вмести с предыдущей публикацией этой разработки. Данная публикация – повторная.
“…насколько стабильно работают… за последние полгода ”
За “отчетный период” никаких нареканий к продукции Sequiter Inc не было. Сервер не заваливался ни разу. Причин для пересоздания индексов не возникало. На стороне клиента были проблемы под управлением Windows ME, но они успешно исправились в текущей версии моей разработки. Ошибки, исправляемые в моей части разработки, на нашей эксплуатации не отражаются т.к. “лежат” в не используемой нами части 1Са. Снижения производительности и устойчивости системы в целом, по сравнению с “родными” DBFами, пользователи не отмечают. К сожалению, за время публикации моей разработки так и не нашлось потенциальных пользователей, сообщивших мне об ошибках в неиспользуемой у нас части 1Са (за исключением проблемы с запросами и длинными ключами). Это меня и настораживает. У меня складывается такое впечатление, что кроме нас никто не использует разработку. А мои оценки качества разработки, думаю, не совсем объективны. Хотелось бы узнать мнение других пользователей не в теории, а в практике.
почему народ молчит - а непонятно потому что все...
сделайте большую статью, где подробно все опишите (скомпилить из ваших топиков, я думаю проблемы не будет).
вопросы интересуют в первую очередь.
- каково быстродействие вашей базы если сравнить на 3-х вариантах:DBF, SQL и CODEBASE?
- каковы основные причины для использования CODEBASE, а не скуля?
- насколько CODEBASE устойчиво работает с 1Сной базой? (у мен яскуль вертится с конца 2003 года, база не падала ни разу - правда и база не сильно небольшая), насколько для CODEBASE критично отваливание 1Ски по выключению, например, локального компа?
- можно ли под CODEBASE использовать 1С++ (простите меня ламера) - у меня есть отчет, который на ВИАу считает очень долго, под 1С++ - очень быстро - смогу я 1С++ заточить под CODEBASE (при наличии соотв.там всяких одбс драйверов и всего прочего или 1С++ принципиально не ложится на CODEBASE)
..итого - расскажите подробно и тщательно.
понятно, что времени у вас немного - вы сами упоминали об этом, но что тогда пенять что "кому-то интересно или нет?"
и прочего побольше всего.
мне, например, оченнь интересно.
по крайней мере на 2 первых вопроса (если не на все) автор настоящей разработки уже отвечал в той или иной мере и не раз в топиках (не только на этом форуме), смотрите поиск, как посмотрел его Lustin,
имхо разработано и ранее сказано достаточно для того чтобы заинтересованным, наконец оторвать свои задницы и попробовать таки разработку в работе...
Спасибо Вам за полезные советы и замечания по моей разработке. Хочу прояснить свою фразу: “У меня складывается такое впечатление, что кроме нас никто не использует разработку”. Эта фраза адресована той части пользователей, которая и без моих пояснений знает, зачем и почему появилась эта разработка. Пробуют её и приходят к какому то выводу, типа “тормозит”, “заваливается”, ”много ошибок” и т.д. А я об этом не узнаю от них. Т.е. речь идёт не об анализе и сравнении самой технологии с пояснением преимуществ моего решения, а о качестве реализации моей части разработки и сервера от Sequiter Inc. Что касается “большой статьи, где подробно все опишу”, то, боюсь, что у меня это не получиться. Т.к. писать с нуля основы СУБД это очень много, а пройтись по конкретным вопросам получиться мало вразумительно, примерно так:
1) “каково быстродействие вашей базы если сравнить на 3-х вариантах:DBF, SQL и CODEBASE?”
Быстродействие решения с применением сервера CodeBase, как правило, медленнее чем “родные” DBFы, но быстрее чем SQLная версия 1Са. Однако на некоторых задачах (алгоритмах) это не так.
2) “каковы основные причины для использования CODEBASE, а не скуля?”
Кроме выше сказанного это стоимость и отсутствие необходимости дополнительного программирования (например, с использованием прямых запросов 1С++) для получения приемлемой производительности клиент/серверного решения по сравнению с SQLной реализацией 1Са.
3) “насколько CODEBASE устойчиво работает с 1Сной базой?”
Трудно провести количественную оценку типа “насколько”. Но это клиент/сервер со всеми вытекающими из этого определения качествами системы. О характеристиках самого сервера - его количественных и качественных показателях, можно узнать на сайте разработчика.
4) “насколько для CODEBASE критично отваливание 1Ски по выключению, например, локального компа?”
Как и для любого, уважающего себя, клиент/сервера. Хотя в свой части разработки я выбрал алгоритм снятия зависших (в результате выключения рабочей станции) “логинов” командой от другой сессии (рабочей станции) в момент выполнения на ней транзактивной операции. Это может в редчайших случаях потребовать от администратора БД воспользоваться утилитой администратора для снятия “логина”. У нас такого за три-четыре месяца эксплуатации не было. Выбранный мной алгоритм меньше нагружает сеть опросами типа “клиент ты жив?”.
5) “можно ли под CODEBASE использовать 1С++”
Полагаю, речь идёт о прямых запросах. Частично ответ был выше. Можно добавить, что если у Вас успешно функционирует 1С в SQLной версии и сделано многое, чтобы это работало с приемлемой, для ваших условий скоростью и деньгами, то я не рекомендую использовать мою разработку. А если рассматривается вопрос перехода с DBFной версии на что-то другое, то имеет смысл пробовать мою разработку. И при этом прямые запросы, наверное, не понадобятся т.к., как я понимаю, они призваны выпрямлять кривизну SQLной версии. А для ускорения самого процесса программирования выходных форм с применением языка запросов придётся пользоваться встроенными в язык 1С средствами. Есть еще вариант – использовать SQL от Sequiter Inc (смотрите в ответе для Lustin от 06.03.2007). Для “хитрого” доступа к файлам 1Са можно использовать средство РУС моей разработки. Но там придётся использовать навигационный способ к данным, что дольше в программирование, но эффективней по скорости обработки данных.
6) “мне, например, оченнь интересно”
С удовольствием отвечу на Ваши вопросы. Жаль, что они только теоретические в том смысле, что “у мен яскуль вертится с конца 2003 года” и причин для реальной пробы моей разработки, наверное, у Вас не появиться.
хочу пояснить на мой взгляд область применимости и отсутствие обратной связи.
есть 2 типа фирм.
1. поставили - должно работать, на деньги на скуль жалко, на программера жалко.. денег нет.. шеф жлобный... базу все время надо переиндексировать и т.д.
2. контора, есть свой более менее постоянный прог.
..имхо п2 - не ваш клиент. там поставят скуль и не будут морочиться.
..имхо п1 и примыкающие к ним - ваш клиент.
для ни х нужно - минимум тех.подробностей. описание которое в комплекте - там никто читать не будет. нужна краткая пошаговая инструкция. взять то-то то-то. скопировать туда-то туда-то. выгрузить базу так-то загрузить так-то.. работать. и кратко но емко - преимущества по сравнению с дбф.
...
лично меня все-таки напрягло то, что надо все-таки переиндексироваться...
на скуле - нет такого.. отваливалось кучу раз - все работает...
...
например, если стойкость базы по сравнению с дбф повышается существенно при некотором небольшом замедлении работы - я бы ряду своих клиентов порекомендовал бы такую разработку.
“…все-таки напрягло то, что надо все-таки переиндексироваться...”
Переиндексировать надо, если завалился сам сервер CodeBase. Заваливание пользователя, благодаря технологии клиент/сервер, не приводит к порче базы данных. Сообщение, которое выдаётся при запуске сессии с предложением выполнить переиндексацию можно игнорировать, а если и согласиться с переиндексацией, то это игнорирует моя программа.
“…на скуле - нет такого.. отваливалось кучу раз - все работает...”
Речь идёт о клиенте или сервере? Если о клиенте, то см. выше. А если о сервере, то это, думаю, как повезёт. Обычно в серверах БД предусматриваются средства диагностики и ремонта БД в случае падения самого сервера. Сервер CodeBase в этом вопросе не исключение. А вот если средства сервера не смогут справиться с ремонтом базы данных, то открытая (DBFная) организация данных имеет больше шансов на восстановление ручками.
“…если стойкость базы по сравнению с дбф повышается существенно…”
Это и есть основная причина, по которой делалась разработка.
имелось именно в виду падение клиентов, а не сервера.
сам сервер у вас, как устойчиво работает? не глючит? проблемы если были - то какие?
О сервере мы вспоминаем только, когда вырубается электричество.
А про “отсутствие обратной связи”, думаю, от контор типа “п1” (по предложенной Вами классификации) не будет поступать конструктивной информации. В прошлой публикации мне приходила куча писем от этой группы пользователей – хорошо, если с конкретными вопросами по настройке и установке разработки, а чаше с вопросами типа “почему не SQL?”.
Если бы моей целью было продажа разработки, то, естественно, надо было бы вовлекать эту группу контор в употребление разработки. У меня, то цель публикации - получить грамотный анализ от сторонних пользователей (с другой конфигурацией, железом, задачами и т.д.).
//ye про то и речь.. кто будет неизвестно зачем юзать да и еще отзывы писать.. только в целях о, блин! инересно...
вот я бы дома, например поставил.. и что получил бы? дома мне дбфина нужна - куча регламентной работы, проводиться/восстанавливаться надо.. скуль - неохота, че-нить попроще..ааа.. и не надо.. комп стабильно работает... вот и получается - вроде и есть разработка и интересно..а не надо..
..а вот было бы типа скачал - запустил, само все инстальнулось, на этапе инсталляции спросила базу - само выгрузило/конвертнуло и ..опа - произвести запуск базы в новом режиме? ДА!..
вот тогда еще может и поставил бы даже ради покрутить-попробовать...
Решение проблемы 1 гигабайта.
Если Вы не решитесь использовать сервер CodeBase, а файлы базы данных подбираются к 1 гигабайту, то можно применить следующее:
1) Поместить в каталог исполнительных модулей 1С файл Kernel33.dll.
2) В библиотеках Seven.dll и DBEng32.dll найти контекст “Kernel32.dll” и заменить двойку на тройку (в Seven.dll – два раза, в DBEng32.dll – один раз).
Можно по подробне про работу Kernel33.dll. А то на рабочей базе тестить страшновато, а на тестовой бесполезно. Файл DBF уже 1.2 ГБ однако. Переход на SQL еще предстоит.
“Можно по подробне про работу Kernel33.dll”
Сначала о самой сути проблемы - FoxPro совместимом формате доступа к DBFам.
Для управления блокировками записи используется функции Win API LockFile() и UnlockFile(). Эти функции обеспечиваю блокировку участка файла “полностью” и по записи и по чтению. Если использовать эти функции непосредственно к участкам файла эквивалентным самим записям DBFа, то теряется возможность чтения записи. Поэтому в FoxPro принят “хитрый алгоритм” – блокируются участки файла начиная со 2GB, упрощенно говоря, отдельные куски файла логически сопоставленные с номерами реальных записей DBFа. Таким образом, реальный участок файла можно читать, т.е. моделируется блокировка по записи, но не по чтению. Если же реальные записи начинают располагаться после 1GB, то “технологические блокировки” наезжают на процесс чтения. Возникает сбой по чтению. В 1С не обрабатывается должным образом аварийный код возврата. Например, в функциях найти по ключу в 1С - получают аварийны код возврата, а в программу пользователя (конфигурацию) возвращают признак – объект не найден.
В Kernel33 делается очень простая вещь. Все обращения к функциям Win API отправляются в kernel32. А для функций LockFile() и UnlockFile() к параметру, указывающему стартовый адрес блокировки, добавляется число 2GB и так отправляется в kernel32. Таким образом, технологические блокировки уходят в 4GB. А так как существует уже другое ограничение на размер DBFов в 2GB, то в 4GB никакая реальная запись не попадёт.
Появилась идея задействовать в качестве серверной системы Linux.
Желающие принять участие в этой работе деньгами (на покупку CodeBase for Linux) и знаниями Linux-a пишите мне на реальный почтовый адрес.
почему не майскуль или постгре, например, или еще что?
сорри за вопросы, не проффессионал я в этом деле (как впрочем и в остальных).
“А вот как писать ттебе на мыло, если мыло в профиле скрыто?”
Для этого надо пролистать описание моей разработки до конца. ;)
“А почему CodeBase тогда?”
Уважаемый Сергей.
Мы с одним товарищем в этом “форуме” уже дискутировали на тему “а почему не SQL?”. Всё, что там сказано с моей стороны применимо и к вопросу “…задействовать в качестве серверной системы Linux”.
короче - поучаствую .. чисто символически..
а скока стоит CodeBase for Linux?
“Тьфу, чтоб дать денег - надо еще так напрячься... ;-)”
Вам совершенно не надо напрягаться. У Вас, полагаю, и так всё нормально работает. А вот тем кто сравнивает затраты на покупку серверного софта можно и напрячься – деньги то экономит он, а не я.
“короче - поучаствую .. чисто символически..”
Я не собираю деньги на покупку CodeBase, а предлагаю заинтересованному человеку приобрести себе “CodeBase for Linux” и участвовать в доработке и тестировании моей разработки под сервер на Linux-е.
“Можно по подробне про работу Kernel33.dll”...
Поэтому в FoxPro принят “хитрый алгоритм” – блокируются участки файла начиная со 2GB, упрощенно говоря, отдельные куски файла логически сопоставленные с номерами реальных записей DBFа.
Не много не понял. "блокируются участки файла начиная со 2GB" это значит начиная с размера 2.0 ГБ и больше
но ведь ДБФ файл не может быть больше 2 ГБ. Как же технологические блокировки будут пересекаться?
“Как же технологические блокировки будут пересекаться?”
Я в своём изложении принял нумерацию GB-ов с единицы.
И имел в виду во фразе “…начиная со 2GB…” именной второй гигабайт.
Т.е. в FoxPro:1GB – реальные записи, 2GB – технологические блокировки.
“Переход на SQL еще предстоит.”
Попробуйте выгрузку базы данных штатными средствам 1С уже сейчас. Т.к. у них существует ограничение в 2GB для рабочего файла. И может оказаться, что Ваша база не выгрузится.
“…на рабочей базе тестить страшновато, а на тестовой бесполезно”
Программы, связанные с базой данных, от неизвестных разработчиков лучше тестировать.
Мне недавно пришло письмо, человек пробует:
Локально в XP – работает. Сервер 2003 и рабочая станция XP – работает. Сервер 2003 локально – заваливается реорганизация базы данных при модификации конфигурации. Исходная база к счастью не пострадала т.к. сбой касался создаваемого рабочего DBFа. Разобраться с причинами этого сбоя мне не удалось т.к. корреспондент пропал. Участие Kernel33 в этом сбое я не представляю т.к. файлы DBF, в этом случае открываются эксклюзивно и блокировки не используются, да и в остальных случаях - работает. На моей тестовой платформе (см. в DBEng32.doc) работало нормально до тех пор, пока не задумались о лимите в 2GB - пришлось менять схему базы данных, а там уложились в 1GB (разделили большой файл по годам, а на год хватало и 1GB). А теперь и этого не хватает – поэтому, в частности, и сделали клиент/серверное решение на CodeBase. Хотя и были мысли делить файл по кварталам, месяцам и т.д. Но к лимиту стали подбираться файлы, который не возможно разделить по периодам. Мой совет Вам – принимайте решение о переходе на другую платформу в смысле СУБД, чего тянуть…
Спасибо все понял. Даже потестил ФайлМонитором. Действительно блокируется область файла с адреса 1073741772.
Т.е. с 1 Гб и выше. Все как и говорил. После использования Kernel33
блокировка производится по адресу (минус)1073741876 т.е. со смещением 4 Гбайта.
Все ок. Пока не идем дальше :-)
Я использую для работы компоненту vk_sleep_1C.dll ( от Romix для
Исправления загрузки 100% процессора. Вот в связке и конфликт т.к. она перехватывает вызов LockFile().
Я конечно попытался тупо заменить перехватываемую kernel32->kernel33 но так не работает. Валится 1с.
Судя по коду компоненты можно в нее попытатся включить прибавление смещения 4 Гбайта,
но тогда надо чтобы она и перехватывала еще UnlockFile() с тем же смещением.
Ну или патчить dbeng32.dll чтоб смещение больше делалось всегда. Что можешь порекомендовать?
“Что можешь порекомендовать?”
Найдете в DDLке от уважаемого Romix текст KERNEL32.dl (соблюдая регистр букв).
Рядом будет текст: DbEng32.dll….. KERNEL32.dl……LockFile.
Измените двойку на тройку для kernel.
Должно работать.
Нет – работать не будет. Надо чтобы вызывалась функция, которую он заменил на свою.
Т.е. моя функция, а не Windows.LockFile(). Сделать это в Delphi мне слабо. Может Romix не откажет в решении этого вопроса?
Это то я сразу и сделал. Не за работало. Посмотрел код. И тож пришел к этому выводу.
Про Romix'a думаю как лучше попросить что именно сделать. Вставить вызов kernel33, или просто прибавлять по константе смещение 2Гб, или вообще попросить найти в dbeng32.dll это смещение и пропатчить его.
Вот склоняюсь к последнему, тогда и kernel33 наверное не потребуется. А зачем вызов kernel33 в Seven.dll делается?
Прибавлять 2GB во внешней компоненте не хорошо, т.к. к моменту её активизации уже сделано несколько обращений к DBFам – поэтому я и отказался от такого способа перехвата. Думаю, лучше заменить вызов Windows.LockFile() на вызов моей (перехваченной) функции. Можно предложить сделать настройку на Kernel33 или Kernel32, чтобы не ковырять пользователю DLLку от Romix'a. А “пропатчить” dbeng32.dll, думаю, сложнее будет. Вызов kernel33 в Seven.dll делается “до кучи”, т.к. когда это делалось не проводилось изучения DBEng32 так, как пришлось это делать при написании клиент/серверного решения.
Идея задействовать в качестве серверной системы Linux оказалась не состоятельной.
Получен ответ от Sequiter Inc:
CodeBase for Linux has client/server support. However, client/server support does not work across different operating systems, such as between Windows and Linux.
Отчет по патчингу DBEng32.Предварительно получилось :-).1С и vk_sleep_1C.dl запускаются. Судя по ФайлМонитору блокировки переместились на +1ГБ (+40000000h). Метод патча: pexplorer->декомпиляция. Нашел вызов FileLock/FileUnlock. Записал адреса(метки) переходов на них. Нашел цифры смещения (3FFFFFCC,3FFFFFFF,400000) В тех местах где после них следовал вызов FileLock/FileUnlock менял смещение (3F->7F,40->80). Завтра буду тестить с пристрастием. На отчетный сервер поставлю.
Поправьте если что то мог не так сделать. Познания в ассемблере 0 и тот от i8080 :-)
Если нужно могу скинуть пропатченную DBEng32.dll+оригинал.
Смещений я видел больше чем 3FFFFFCC,3FFFFFFF,400000 !!!
Я бы не рискнул идти таким путём – база данных, однако. Если же идти таким путём, и Вы не используете Windows 9x, то лучше задействовать третий параметр в вызове LockFile(). Там, где dwFileOffsetHigh (high-order word of lock region offset) положить туда единичку и все проблемы с блокировкой закончатся. А лучше свяжитесь с Romix'ом – может он не откажет в полезном деле помочь.
Смещений я видел больше чем 3FFFFFCC,3FFFFFFF,400000 !!!
Да вот с утра тож об этом подумал. Надо находить все вызовы FileLock/FileUnlock и проверять там смещения.
А как задействовать третий параметр в вызове LockFile()? Я про него думал но т.к. пока асм не освоил не могу определить где этот параметр заполняется. В отличии от 3FFFFFCC и т.п. которые явно видно. Если б можно было перед вызовом ф-ии LockFile() просто вставить инкремент. Вот еще думаю мож 1с в 27 версии пропатчила DBEng32 и вставила еще туда sleep при блокировках :-) (можно же помечтать)
Так и не нашел заполнение dwFileOffsetHigh в коде. Перепроверил все вызовы FileLock/FileUnlock. Вроде должно работать. Явно видно цифру смещения. Она боле менее однообразно заполняется в виде
push 00000001h - это скорее всего кол-во блокируемых байт
push 7FFFFFCCh - смещение(уже патченное), может быть и типа 80000000
push eax
call SUB_L1F10EA30 вызов процедуры, где потом вызывается [KERNEL32.dll!LockFile]
Для установки единички в третий параметр надо ковырять команды загрузки параметров в stack. Но, повторю еще раз. При наличии доступа к авторам обеих разработок ковырять библиотеки на таком уровне –последние дело! Есть несколько 100% решений на уровне исходных текстов. Можно вставлять sleep() в Kernel33, можно перестроить вызовы в vk_sleep_1C на Kernel33 и т.д. И это будут 100% решения в части целостности базы данных. Пишите Romix'у - в его разработке много чего сделано сервисного. В отличие от моей разработки, куда тоже можно воткнуть тупой sleep() без настроек. Но это хуже.
При наличии доступа к авторам обеих разработок ковырять библиотеки на таком уровне –последние дело!
Да ладно, интересно же :-) Но опасно :-(
Чем рискую: если ошибся со смещением то могу получить не правильные блокировки, и вылет 1С с ошибкой. Это нормально и явно видно. Но вот глюк другого рода опасней: если окажется возможно изменение записи в DBF одновременно двумя экземплярами 1С т.к. они заблокировали разные адреса. И типа думают что все ок. Проверил по файл монитору: при проведении документа все блокировки сдвинуты корректно на смещение.
Попробую свою пропатченную DBEng32 поиспользовать если будет глючить, то буду Romix'a просить.
О результатах напишу. Спасибо за помощь.
P.S. Не ужели ни кто с DBF>1Гб не работает в 1С? Все на SQL переползли?
У меня база (торговля) 5.2Гб DBF на терминале+vk_sleep_1C+Core2Duo+8Гб Ram ничего так шевелется
“Но вот глюк другого рода опасней”
При блокировке записей используются не фиксированные смещения, а числа “сопоставленные” с номерами записей. Т.е. их тоже надо сдвигать. Если этого не делать, то….
“Не ужели ни кто с DBF>1Гб не работает в 1С?”
Судя по моей переписке с 1С (года три назад) по поводу этой ошибки – если и используют базы больше 1GB, то ошибки не замечают. Интересно, сама 1С исправила эту ошибку в более поздних версиях. Я ошибку обнаружил в районе 18-25 версии.
“если будет глючить, то буду Romix'a просить.”
Будет. И что хуже – “родная” ошибка или “новая”…
P.S. Вопрос по “8Гб Ram”. На каких Windows?. Если используется PAE, то какая стоит VGA карта и драйвер для неё? (Ответ, думаю, лучше послать по почте).
“…должна ли работать база без запущенного сервера Codebase?”
Да, если в запуске сессии 1С указан каталог информационной базы данных на локальном диске. Например: “C:\BASE”. А сессия 1С запускается на той же машине где лежит сама БД. Это называется “режим ПДБД”. Он описан в DBEng32.doc.
“Работает ли эта компонента с 27 релизом 1с?”
Я в этой версии не пробовал. Несовместимость версий в большинстве случаев должна выявиться в момент запуска сессии 1С.
и ещё почему-то по сети, не запускается, просто нажимаю на базу, секунду идёт как обычно, потом закрывается без ошибок.
видимо что-то я не доделал, знать бы что.
если у меня база лежит c:\test\db то и в dbeng32.ini должна быть эта строчка?
“а в окне сервера codebase должны быть какие-нибудь опознавательные знаки”
Да. В окне должно быть больше нуля для: Users, Connections. И больше двойки для Tables.
“и ещё почему-то по сети, не запускается, просто нажимаю на базу, секунду идёт как обычно, потом закрывается без ошибок”
Только заставка выдаётся? Чего пробегает в нижней строчке заставки? Окно 1Са открывается? Файлы *.lck и *.cdx в каталоге ИБД создаются. На диске С: создаются файлы DBEng32*.log?
“если у меня база лежит c:\test\db то и в dbeng32.ini должна быть эта строчка?”
Да. Это каталог ИБД на сервере. А в запуске 1Са должно быть \\server\ресурс.
“видимо что-то я не доделал, знать бы что”
Напишите мне на реальный почтовый адрес. Опишите последовательность Ваших действий.
теперь вопрос, если я помещу файл dbeng32.ini в каталог каждой базы, и в строке 8 напишу 1 или 0, то можно будет использовать одну и ту же установку 1с с codeBase сервером и обычным dbf-ом?
и просьба дайте ссылку на свою статью, не получается в инете найти, думаю не одному мне интересно почитать будет.
“…если я помещу файл dbeng32.ini в каталог каждой базы, и в строке 8 напишу 1 или 0, то можно будет использовать одну и ту же установку 1с с codeBase сервером и обычным dbf-ом?”
В DBEng32.doc написано: “Например, для сравнения производительности “родной” СУБД и сервера CodeBase.”. Наверно, надо было написать без слова “например”. Т.к. этот режим сделан для удобства отладки программы в “удалённом режиме”. Т.е. если Вы обнаружите ошибку, то я Вас попрошу провести одинаковые действия в “родной” базе данных и в базе под управлением CodeBase с включённым режимом создания файлов *.log и выслать мне эти файлы. При этом “родную” базу данных лучше использовать не из промышленной эксплуатации, а развернуть тестовую базу данных. Использовать этот режим для промышленной эксплуатации я не рекомендую по двум причинам. Во-первых, немного снижается производительность системы. Во-вторых, этот режим не является простым переключением на родную библиотеку. В моей части программы выполняется значительное количество действий, в которых могут быть и ошибки. Не стоит рисковать промышленной базой данных. Для использования одновременно старого и нового формата базы данных (на уровне промышленной эксплуатации) с одной рабочей станции рекомендую сделать вызов 1Са из разных каталогов.
“дайте ссылку на свою статью”
Этой статьи в интернете больше нет.
“использовать бесплатно, это для любого использования? можно ссылку на лицензию для этого варианта сервера?”
В каталоге \BIN_CB\CB есть файл license.txt. А на сайте разработчика написано: “CodeBase allows royalty-free distribution for all supported configurations, including client/server. This means you can even distribute the CodeBase server engine and all associated utilities free from royalties.”. Чем я и воспользовался. Если у Вас возникнет потребность использовать сервер CodeBase для количества пользователей более десяти, то придётся докупить дополнительные лицензии на сайте разработчика.
Вобщем на установку ушло 2 часа на всё, скорость выросла на некоторых операциях в 10 раз (например поиск по артикулу в номенклатуре (биноклем)). путешествия по справочникам, журналам стало комфортным. Отчёты формироваться стали быстрее не в 10 раз, но раза в 3-4. Прошло больше месяца, ошибок нету, работает стабильно.
“…ещё раз выложить, например на этом сайте…”
Я свою статью снял с публикации в конце 2006 года. Она лежала в интернете шесть лет. Статья уже потеряла свою актуальность по следующим причинам:
1) В восьмой версии 1Са устранены (по описанию) большинство проблем обозначенных мной в этой статье.
2) Для седьмой версии разработано много чего, что тоже позволяет её использовать так как, надеюсь, планировалось разработчиками - перехват Esc, гибкие блокировки, прямые запросы (для SQLной версии), 100% загрузка процессора при ожидании блокировок, уменьшение монопольных (технологических) процедур, устранение клинчей и т.д.
3) Появилась моя разработка (DBEng32) которая без всяких статей подтверждает или опровергает моё утверждение: “ …задачи, для которых предназначена 1С, и SQL сервер, мягко говоря, вещи не совместимые…”. Т.е. теперь можно реально сравнить производительность, надежность, финансовые затраты, объемы дополнительного программирования, время на изучение и т.д. А не сотрясать воздух бесполезными спорами.
т.е. если юзать данный сабж в терминальном режиме - будет типа шоколадно?
15 июня запустил в одной конторе. 5 машин, все целероны. Ведущий - Win 2003. Клиенты все XP Prof.
Пока стабильно. Ждемс.
Тестов по скорости еще не проводил, прочих эксперементов тоже.
Впечатления - работа клиента походит на работу терминала - списки тормозят, транзакции летают.
Обнаружил такой нюанс: попытка открыть просмотр заблокированной записи длится несколько секунд.
Владимиру, возможно ли не выкладывать таблицы на общий доступ, а ограничится DBEng32.ini?
“…списки тормозят…”
Посмотрите, какая у Вас стоит версия. Т.к. в предыдущих версиях выполнялась блокировка несуществующих записей в таблице с бесполезным ожиданием их освобождения. Запросы на такую блокировку в мою часть программы передавались из “выше” стоящих программ. В текущей версии есть проверка на реальное существование записи и обход бесполезных попыток блокировки.
“…попытка открыть просмотр заблокированной записи длится несколько секунд.”
Повторюсь – посмотрите, какая у Вас стоит версия. И поставьте в строке № 9 файла DBEng32.ini единицу. Суть явления описана в пункте № 6 раздела “Эксплуатация”. Заодно в строке № 10 поставьте значение 1000. Этого, как правило, достаточно для количества пользователей до десяти. То значение, что стоит по умолчанию (5000) рассчитано на большее количество пользователей.
“…возможно ли не выкладывать таблицы на общий доступ, а ограничится DBEng32.ini?”
К сожалению – нет. Т.е. к файлам LCK, DD, MD и др. происходит, минуя сервер CodeBase. А в момент реорганизации базы данных и к файлам DBF, CDX выполняется “прямое” обращение.
Перешёл на использования в качестве настольной системы на “Windows XP Professional x64 Edition (SP2)” и обнаружил, на мой взгляд, странное поведение этой системы в части мультизадачности по сравнению с настольным использованием “Windows 2000 Advanced Server (SP4+UR1)”. Если в 2000ом, я мог спокойно запустить индексирование базы данных, и это было не заметно для работы в других задачах (Microsoft Word, Internet Explorer Browser и т.д.), то в XP очень часто полностью зависают эти задачи. Или, например, если в моей разработке выдаётся запрос к функции Sleep(Time) в одной задаче то Windows XP не даёт переключится между окнами для других задач, в 2000ом это выполнялось всегда и мгновенно. Мой вопрос в следующем. Это так во всей линейке Windows XP по сравнению с Windows 2000? Или это особенности (намеренные) настройки (по умолчанию) для настольных систем вообще? Вопрос возник, прежде всего, в контексте использования функции Sleep(Time) в моей разработке.
2 hoqik:
Искренне благодарю Вас за Вашу работу.
Мои записи здесь будут иметь одну цель - опсание опыта работы CB на реальной промышленной базе.
Комментариев Вам делать не обязательно, хоть местами и желательно.
Итак:
1. Первый, описанный ниже, безболезненный опыт был произведен над базой новоиспеченной торговой фирмы. База 14 Мб. Преимуществ в скорости codebase не принес. По иронии судьбы через три дня где-то рядом долбанула молния, "упал" весь офис. Без меня не обошлись. Сервер CB не имел желания загружаться в связи с error s4server.log. Что-то я пытался повтыкать в CBAdminе, без результатов.
Удалил я этот log, никто ничего и не заметил. Сейчас исправно работают.
Что дал мне этот опыт: продукт работает.
2. Опыт второй. 7 пользователей. Сервер - Win 2000s Цел 2.4 Гц на 512Мб . 1Сv77r25. Клиенты все XP Prof.
База 400 Мб. DBEng32 (версия 5.1.1.9)
Прирост производительности:
- бухгалтерские запросы - 6-8 раз.
- проведение документов - 1.5-2 раза
- отображение списков - могу ошибиться
Такой момент:
во время запроса по чтению (не cb транзакции) у одного пользователя все остальные заметно подвисают.
Параметры DBEng32.ini по умолчанию.
Кстати, возможно не выкладывать dbf и cdx в расшаренном ресурсе:
- для пользователя - работа клиента с расшаренным каталогом
- для разработчика и админа - работа в режиме ПДБД с реальным каталогом ИБ
md и dd дублируются руками с реального каталога в расшаренный.
Несмотря на некоторую сложность, это есть защита информации от прямого копирования.
Продолжение следует...
“Удалил я этот log, никто ничего и не заметил”
Совершенно верные действия при заваливании сервера, если не использовать средства резервирования сервера CodeBase, а в комплекте данной разработки они выключены. Ну, а если Вы захотите их использовать, то надо чинить файл журнала транзакций (этот самый – LOG) утилитой администратора. В составе сервера CodeBase есть еще пакетная утилита для ремонта этого файла. В комплект моей разработки она не включена. Но очень важно при заваливании сервера пересоздать индексные файлы. Сервер CodeBase не плохо распознаёт противоречия в индексных файлах и сообщает об этом либо клиенту, либо в окне сервера. Но 100% гарантии эта диагностика не даёт. Они предлагают протестировать индексы утилитой администратора. Но время её работы соизмеримо со временем пересоздания индексов, если только утилита не увидит сразу, “встроенные в индексы” средства подтверждения их "порчи". А это и обычная задача увидит. Так, что – переиндексировать!
“во время запроса по чтению (не cb транзакции) у одного пользователя все остальные заметно подвисают.”
Причин для такого явления несколько. Есть объективные для архитектуры клиент/сервер – например, слабое распараллеливание процессов. Есть и субъективные – настройка сети, медленные диски и т.д. Надо смотреть “живьём” и настраивать. Однако смею предположить, что при увеличении размера базы и количества, одновременно работающих пользователях – разрыв в скорости между файл серверным режимом и клиент/серверным будет сокращаться. Для этого в данной версии CodeBase сделано много. Например, то с чем работает сервер CodeBase - это уже не традиционные DBF в части индексов.
“…не выкладывать dbf и cdx в расшаренном ресурсе…”
Если не учитывать “административные” действия с базой данных, то можно, было бы и сделать так. Но обязательно надо положить рядом с MD файл 1SUSERS.dbf и запретить пользователям заходить в систему в монопольном режиме. Если у меня не стоит специально на такое расположение файлов проверки (не помню), то должно работать.
"...при увеличении размера базы и количества одновременно работающих пользователях – разрыв в скорости между файл серверным режимом и клиент/серверным будет сокращаться..."
? или все таки увеличиваться ?
й. Поставил s4server как службу.
Пользовался утилитой AppToService v2.3, с параметром /interact:0.
В результате сервер полностью скрыт от глаз пользователя, вопросов перед остановкой не выдает.
Тест работает нормально.
По каким причинам Вы не рекомендуете ставить s4server как службу?
2. Не дает покоя вопрос: размеры индексных файлов CodeBase существенно (в разы) больше родных, особенно это касается таких монстров как 1SBKTTL.CDX и 1SSBSEL.CDX, в чем такая разбежка?
“или все таки увеличиваться ?”
Разрыв, в смысле – разница. Уменьшается. Сужу об этом по тому, что при нашей базе и количестве пользователей, на основных задачах пользователи не заметили перехода на CodeBase. Т.е. не отметили резкого падения производительности. Однако существуют задачи, которые способны парализовать работу сервера CodeBase почти полностью. Например, если сервер выполняет индексирование для одной базы, то в другую базу даже войти проблематично. Не говоря уже о самой работе. А в файл серверной технологии это, с трудом, но удаётся.
“По каким причинам Вы не рекомендуете ставить s4server как службу?”
Именно по этой причине, что: “В результате сервер полностью скрыт от глаз пользователя, вопросов перед остановкой не выдает.” И завершение и запуск сервера должен контролировать администратор базы данных, а не “старт – стоп” Windows-а.
“…размеры индексных файлов CodeBase существенно (в разы) больше родных, особенно это касается таких монстров как 1SBKTTL.CDX и 1SSBSEL.CDX, в чем такая разбежка?”
Я не обнаружил, в нашей базе, ни одного индекса в CodeBase, по сравнению с “родными”, больше чем на 10%. Это в вашей базе сразу после их создания? Или после активной работы с ними? Если после активной работы, то мне хотелось бы с этим разобраться. Только в сравнении с аналогичной работой в “родной” базе.
Вот сравнительные размеры, конвертация - через выгрузку, после тестирования и т.п.
codebase 1c
1SENTRY.cdx 12 146 176 5 841 408
1SCRDOC.cdx 12 338 176 6 515 712
1SSBSEL.cdx 28 327 242 13 355 008
1SBKTTL.cdx 27 665 408 23 397 888
и 1SBLOB.cdx и 1SCONST.cdx и остальные от полутора до 2.5 а то и трех раз, как здесь
DT13147.CDX 1 172 992 487 424
Очень хороший результат.
Т.к. в 1Се загрузка делается при открытых индексах, то Вы моделируете, тем самым, длительное время работы системы с активным обновление базы данных. После таких процедур над базой, рекомендуется в любых СУБД заняться оптимизацией (дефрагментацией) индексных последовательностей. Либо дожидаться когда продвинутая СУБД это сделает в фоновом режиме. Сервер CodeBase, в этом смысле, не продвинутая СУБД.
Надо, так же, учитывать, что в утилите 1Са “тестирование и исправление ИБД” флажок “выполнить реиндексацию” не приводит к выполнению этих действий при использовании данной разработки. О чем написано в DBEng32.doc в первых трех пунктах раздела “Эксплуатация”. Наверно, мне надо было написать там конкретно, а не “намёками” – но это так.
при установке этого пакета программ я в dbeng32.ini прописал только первую строку
почему-то сегодня при открытии документов начала ругаться "Access denied", создал и прописал юзера дальше продолжила работать нормально. что бы это могло быть? версия правда 5.1.1.9
Если в DBEng32.ini прописана одна строчка, то имя пользователя для сервера CodeBase – PUBLIC. Если “вчера” аварийно закончилась сессия клиента в момент выполнения транзакции, то “сегодня” при входе в сервер производится попытка “убить” зависшую сессию в сервере CodeBase. Это делает клиент, который это обнаружил первым. Если у пользователя PUBLIC нет прав на команду Disconnect, то будет выдано сообщение об этом. Т.е. достаточно пользователю PUBLIC дать права на выполнение команды Disconnect. Признак аварийно завершившейся сессии в момент выполнения транзакции храниться в файле 1SxTTS.lck. Если удалить этот файл то попытки “убить” аварийную сессию производиться не будет. Признак аварийного завершения сессии в момент выполнения транзакции сбрасывается, если запускается система в режиме ПДБД.
Т.е. то, что вы описываете это не “глюк” – так и должно быть. А версию стоит сменить, т.к. “глюк” может возникнуть. См. в файле History.doc первый пункт к описанию изменений в версии 5.1.2.1.
Попробую предположить.
Может в системе есть другие задачи с повышенным приоритетом? Тогда слип действительно не возвращает управление через указанное количество мс (чем выше приоритет у грузящей задачи, тем дольше не возвращает).
Я экспериментировал с простой задачей, которая тупо крутится в цикле, и грузит процессор.
Другая задача в это время делала слипы, и замеряла время, а сколько же в действительности делался этот слип (на практике он делается дольше указанного количества мс, если система загружена чеи-то еще).
Если управлять приоритетом "грузящей" задачи, то соответственно изменяется и время слипа у второй задачи. Если же грузящей задаче поставить приоритет реалтайм, то по-моему даже кнопка "ресет" зависает, приходится питание выключать (шутка). :-)
Тут лежит простенькая программа, которая умеет управлять приоритетами и процессорами запускаемого приложения.
Или можно правым кликом в "диспетчере задач" все это смотреть или изменять.
Вдруг полегчает, если разрешить 1С-ке запускаться только под одним процессором...
Может еще задаче 1С режим совместимости с Windows 95 попробовать поставить.
Мне интересно узнать каков будет результат опыта с изменением приоритета 1C, запуском 1С под определенными процессорами (процессором) и "совместимостью с Windows 95".
Приступил к проведению опытов. Начал со “стандартного” запуска задач, когда всё в системе “замораживалась”. Запустил две 1Са. В одной проводится документ. В другой сессии 1Са тоже пускаю проведение документа. По моему алгоритму блокировок транзакций – вторая задача проверяет блокировку определённого байта в неком файле и делает это в цикле со sleep(5000). И в данный момент всё прекрасно работает - другие окна открываются, переключаются, диспетчер задач удаётся вызвать. А при той картине, что я описывал - даже диспетчер задач можно было вызвать только кнопками “Ctrl+Alt+Del”. Т.е. картина не постоянная. И чего-либо в таком случае выявить мне не удастся. Допускаю, что система приходит в такое состояние (с замораживанием) после выполнения на компьютере каких то других программ. Буду наблюдать. Однако точно могу сказать, что в WinXPx64 не всё хорошо с прерыванием по таймеру. Т.к. если сильно загрузить процессор при активном сетевом соединении, то очень часто соединение, в таком случае, разорвётся. В Win2000 такого я не замечал не разу. Либо они не выделяют достаточные кванты времени другим задачам. Т.е. мне напоминает это работу в Win98.
Извините, пожалуйста, что отвлек Вас от Ваших дел на этот вопрос. Буду ждать и наблюдать - какая последовательность выполнения задач приводит к такой “деградации” системы, влияющей на другие задачи.
Спасибо.
sleep(5000) это по-моему круто... Я делаю иначе - слип 1,2,4,8...1024 мс (счетчик далее не увеличивается) при каждой неудачной попытке блокировки, и счетчик сбрасывается в 1 при удачной попытке блокировки.
А пишите в аську 21709980пять, если честно я не понял какой процесс у Вас так грузит систему.
Если этот некий процесс действительно так грузит, и при этом еще имеет повышенный приоритет, то он может вообще не вернуть управление другим задачам (если приоритет реалтайм). И проблема ск. всего - в нем.
Мне не совсем понятен вопрос. Придётся писать длинный ответ.
1) Сервер CodeBase использует один (в смысле номера) порт - 23165 (по умолчанию). Его можно поменять на стороне сервера и, естественно, поменять в файле DBEng32.ini на стороне клиента.
2) В моей разработке открываются и обрабатываются некие (DD, MD, LCK и т.д.) файлы в каталоге информационной базы. Для этого Windows, тоже использует порты.
3) При работе в конфигураторе устанавливается два соединения с сервером CodeBase Т.е. по одному соединению на каждый процесс “открытия” файл DD. Соединение закрывается вместе с “закрытием” файла DD. С этим связано появление паузы перед сохранением изменённой конфигурации – устанавливается соединение с сервером. С этим же связана одна из причин замедления процесса выполнения логического тестирования ИБД. Т.к. мне поступают запросы на “открытия” файла DD для каждой таблицы базы данных. Исходя из сказанного в данном пункте – лучше использовать режим ПДБД в процессе программирования в среде 1Са и проведения технологических процедур для базы данных.
Если мне не удалось ответить на Ваш вопрос – уточните, пожалуйста, его.
“Запросы - это уже классно.”
Мне даже обидно стало ;-). А индексы со сложными индексными выражениями? А выборка (навигация) не по одному значению реквизита? А выборка (навигация) по любому индексу - не только по доступным в среде программирования 1Са? Чего классного то в этих и других запросах? При использовании, выше названных возможностей, любой отчет будет выполнятся быстрее, чем с применение “запросной системы”. Не говоря уж об других алгоритмах используемых в информационных системах (журналы, списки, “обновление данных” и т.д.). Может быть, запросы ускоряют процесс программирования? Или есть необходимость загрузить на 100% сервер? Или подкупает расхожая фраз – “сеть разгрузить”? Ничего этого нет, если система изначально не проектировалась под “запросные алгоритмы” обработки информации. А в 1С 7.7 этого не делалось! Для эффективной работы системы надо, прежде всего, схему базы данных спроектировать соответствующую задачам. И не использовать ИПСные технологии в АСУПных задачах.
“А есть надежда, что можно будет, в запросе, объеденять таблицы ? Или это принципиально не возможно ?”
Никаких проблем не существует, что бы “вынести наверх” весь xBase. Дольше описывать в документации, чем программировать. Однако, вынося функции xBase в РУС, я преследую цели дать простой инструмент, расширяющий функции 1Са в части работы с БД. А для “Relate/Query” получается очень большое описание функций, которые, на мой взгляд, проще выполнять на встроенном языке 1Са. Да и сервер отдохнет, пока это делается на стороне клиента ;-).
Смотрел 1Сv7 процесс-вьевером (плагин TotalCmd PE)
1С Предприятие (Клиент) в любом режиме работы
задействует два local tcp порта,
например 192.168.0.2:1121 и 192.168.0.2:1121;
на стороне сервера как и описано в доке, remote 23165, без вопросов,
а вот у клиента именно два.
“а вот у клиента именно два”
“конфигуратор при реорганизации использует аж 4 порта”
Вот примерная картина использования портов:
Process-Name Local-Port-Address Remote-Port-Address
1CV7.EXE 1221 192.168.1.10 23165 192.168.1.10
1CV7.EXE 1222 192.168.1.10 23165 192.168.1.10
CBAdmin.exe 1223 127.0.0.1 23165 127.0.0.1
CBAdmin.exe 1224 127.0.0.1 23165 127.0.0.1
s4server.exe 23165 192.168.1.10 1221 192.168.1.10
s4server.exe 23165 192.168.1.10 1222 192.168.1.10
s4server.exe 23165 127.0.0.1 1223 127.0.0.1
s4server.exe 23165 127.0.0.1 1224 127.0.0.1
Специально запустил еще и CBAdmin, что бы показать, что каждое соединение с сервером использует порт 23165 дважды. Т.е. это не особенности 1C+DBEng32, а особенности CodeBase. В случае запуска конфигуратора картина будет “2х2”, что и написано в предыдущем моём ответе. Если данная картина указывает на наличие ошибки в CodeBase или создаёт большие неудобства в его использовании, то давайте это сформулируем, и я отправлю это в Sequiter Inc. Желательно на английском, французском или японском языке, что бы ни мне, ни им не мучится с переводом.
Как проявилась проблема:
ТиС - последняя. Перестали проводиться документы реализации. Т.е. сами документы проводяться и отмечаются как проведенные, а движений регистров нет !!!
Из-за этого, естественно, поплыли остатки.
Вошел в отладчик. До половины кода модуля даже трассировка не доходила. вылетало черте-где.
Осторожнее со внешними компонентами !!! Могут и еще быть не совместимости.
DBEng32 – 5.1.2.6.
ТиС - 7.70.906.
TurboBL - 1.1.0.6 и 1.1.0.4.
TurboMD - 1.0.1.1.
1С:Предприятие 7.7 - 7.70.018.
Windows XP Professional x64 Edition (SP2).
Режим – клиент/сервер на одной машине.
Наблюдал за изменение остатков при проведении существующих и новых документов “Поступление ТМЦ” и “Реализация”. Остатки соответствуют содержанию документов.
Опишите, пожалуйста, Вашу тестовую платформу и манипуляции с документами.
Конфликт возможен именно с TurboBL, если предположить, что в этой обработке делается:
1) Упорядочиваются имена объектов, методов и свойств для применения, например, дихотомического алгоритма поиска.
2) В результате перестановки эти имена приобретают другие порядковые номера.
3) Описание схемы базы данных (из файла 1CV7.DD) подвергается аналогичной обработке. Например, имя таблицы это “объект”, а имена полей и индексов это “свойства”.
4) Решён вопрос поиска имени по его порядковому номеру или в кишках 1Са всегда ищется объект, метод и свойства по их именам.
А т.к. в моей разработке содержимое файла 1CV7.DD хранится самостоятельно, то может образоваться расхождение в порядковых номерах понятий схемы базы данных упорядоченных средствами TurboBL и порядком хранения в моей разработке. В DBEng32 поступают команды воздействия на данные, как по именам, так и по номерам понятий. Чаще - по именам. Если обращение делается по номерам, то будут использоваться не соответствующие понятия. Т.е. будут путаться имена таблиц, полей и индексов.
Если мои предположения верны, то расхождения остатков это мелочи по сравнению с тем, как может испортиться база данных в результате расхождения номеров понятий схемы базы данных.
Надеюсь, что мои предположения не верны…
Надеюсь, что мои предположения не верны…
Может быть в чем-то ты и ошибаешься, но по сути все именно так и обстоит.
Кстати, сейчас функционал turbobl включен в состав 1cpp. А я так часто ее использую во внешних отчетах :-( Уж больно мне нравиться, что вместо 10 минут сложный отчет формируется секунд за 40.
По платформе. Все проблемы у клиента начались когда он с НЕ лицензионного сервера 2003 перешел на лицензионную XP Home Edition. В сети еще два пользователя. У всех XP Home Edition. На "главном" компе, где лежит база сменили мать, поставили новый проц и добавили памяти. В результате этого перехода с Сервера-2003 на XP-Home скорость работы упала раза в три. Для удаленных станций. Это если каждая из них работает поодному. Если двое открывают подбор, то выбор каждой позиции номенклатуры занимает почти по 10 секунд.
В этом режиме (через CodeBase) работают уже месяц. Их впечатление - "Ужастно". Очень часто происходят сбои на "сервере". Иногда по несколько раз в день. В результате всегда ругается на LOG файл. Пока его не удалишь, сервер CodeBase не запускается. Практически каждый день "главный" компьютер подвисает и приходится пересоздавать индексы.
Но я сказал клиенту, что ничего тут не поделаешь, т.к. кроме Торговли на всех трех компах они одновременно работают в базах двух предпринимателей и двух бухгалтериях. А такое количество одновременно открытых файлов ни одна XP не потянет :-( Если честно, то я сам не проверял. Но так чуствую, что скоро придется. Потому что проявился еще один косяк.
Есть в ТиС такая обработка: "Пакетный ввод документов". Клиент использует ее для закупа у собственной фирмы по результатам работы за неделю. Т.е. сейчас стоит контроль остатков "По Компании" и по разным фирмам при продаже с разных складов получаются "Красные" остатки по Фирмам. Так вот, этот пакетный ввод создает документы с несколькими 2-4 сотнями строк товара. После его проведения напрочь слетают остатки. Лечиться через конфигуратор - "Тестирование и исправление" - Пересчет итогов.
Что за косяк ?
Бинарник 1с-ки 25-SQL в режиме DBF.
1. Ядро 1С стандартное, DBEng32 5.1.3.1 ПДБД. 275'220 миллисекунд.
2. Ядро 1С с патченым dbeng32.dll, DBEng32 5.1.3.1 не используется. 13'756 миллисекунд.
Теперь насчет того, что типа использование этого патча даже на локальной машине в терминалке может привести к тому, что другой клиент может прочесть устаревшие данные (то есть пока кэш еще не успел сброситься на диск). То есть то, что автор мне впаривал в посте (89) топика .
Провел еще один эксперимент. В конец процедуры записи документа "ПриемСтоматолога" вставляю Сообщить(_GetPerformanceCounter()), создаю обработку которая в бесконечном цикле опрашивает состояние реквизита конкретного экземпляра документа с упоминанием о том же _GetPerformanceCounter(). В одном сеансе запускаю обработку крутиться, в другом меняю реквизит документа. Сравниваю временные точки. Эксперимент показал, что второй клиент получает новые данные сразу же после их изменения, из кэша, не дожидаясь пока обновленная инфа сбросится на диск. Эксперимент повторил несколько раз.
Объясняется просто. Windows при запросе данных файла ВСЕГДА сначала проверяет, нет ли этих данных в кэше, и уж затем (если их нету) лезет на диск. Патч dbeng32.dll включает родной виндусовый режим кэширования записи на диск, никаких своих кэшей он не использует. Поэтому предоставление противоречивой информации, описанное в посте (89) невозможно в принципе, если все клиенты вертятся на одной машине, а ускорение идет на порядок.
"Патч dbeng32.dll включает родной виндусовый режим кэширования записи на диск, никаких своих кэшей он не использует."
Всё верно. Только есть маленький нюанс. Данный "патч" не включает "виндусовый режим кэширования записи на диск", а отключает в движке 1Са (CodeBase) выдачу функции FlushFileBuffers. И если у Вас есть полная уверенность, что "никаких своих кэшей он не использует", почему бы и не использовать данный "патч". Наверно Вы под термином "он" подразумеваете конкретную версия Windows, а я Вам "впаривал"© информацию о "многопользовательских системах". И мой опыт программирования в этих самых системах подсказывает, что не "ВСЕГДА сначала проверяет". А после разглядывания исходным текстам CodeBase мне показалось, что разработчикам этого движка тоже опыт подсказывает, что - не всегда. Точнее, не во всех "он". Поэтому я и написал - "не рекомендую", а не - "не работает".
А по сравнению времен выполнения Вашего теста - это естественно. Но есть вопросы. В каком режиме запускалась сессия 1С в ПДБД? Файл транзакций на RAM диске? Какие установлены режимы оптимизации?
"ПДБД, то есть без использования CodeBase"
Наверно, без использование сервера CodeBase? В режиме ПДБД тоже используется "CodeBase 6.5", т.е. ограничение в 1(2) гигабайта на таблицу тоже снимается.
"но по максимуму в ущерб надежности"
Если ничего не меняли в настройках, то оптимизация включается только для монопольного запуска сессии 1С. А в разделенном режиме - повышается надежность в ущерб скорости. И лучше эти настройки не менять.
"В разделенном конечно"
В разделенном режиме, если не использовать RAM диск, система работает медленно. Т.к. для файла транзакций очень часто выполняется FlushFileBuffers, что совершенно не требуется в данном случае.
"какой размер RAM-диска нужно иметь"
Нам хватало 32 мегабайт. Для начала, поставьте в строке #13 файла DBEng32.ini единичку - это количество транзакций после которого требуется писать файл транзакций заново.
"Можно что-то еще подкрутить...?"
Думаю, что для "глобального увеличения быстродействия", в моей разработке, уже ничего не сделать :-( Остаётся, только сравнить скорости выполнения с вариантом без "патча" и делать выбор - чего и при каких условиях использовать...
“функционал turbobl включен в состав 1cpp…нравиться, что вместо 10 минут сложный отчет формируется секунд за 40.”
Я могу заняться вопросом совместимости моей разработки с turbobl, если автор расскажет об используемом алгоритме – задайте ему это вопрос.
“Очень часто происходят сбои на "сервере".”
Сбои возникают в сервере CodeBase или виновато железо, Windows и т.д.?
“В результате всегда ругается на LOG файл”
При заваливании “сервере” этот файл часто портится. Его надо удалять. Или, если выполняется перезагрузка Windows, то достаточно его разместить на RAM диске – тогда он будет удаляться автоматически.
“каждый день "главный" компьютер подвисает”
“В сети еще два пользователя”
А зачем тогда использовать технологию клиент/сервер.
“Если двое открывают подбор, то выбор каждой позиции номенклатуры занимает почти по 10 секунд.”
У нас номенклатура в 50000 наименований. Суммарный объем DBF файлов –5 гигабайт. Система используется и для розничной торговли. Чеки поступают в систему в дневное время – одна штука в 5-10 секунд. Кассовых аппаратов 6-10 штук. Чаще выбор товара осуществляется по штрих-коду. Но “бегание” по списку товаров используется продавцами тоже часто. Они не отметили падение производительности системы при переходе на сервер CodeBase по сравнению с “родными” DBF-ами. В какой-то версии моей разработки была ошибка, которая сильно замедляла многопользовательское движение по спискам в справочниках из-за “лишних” блокировок. Но она проявлялась, только если в строке № 9 файла DBEng32.ini установлена величина отличная от нуля.
“…компьютер подвисает и приходится пересоздавать индексы”
У нас с ноября 2006 года индексы не пересоздавались ни разу. Ну, если сервер падает “…по несколько раз в день”, то лучше вообще не использовать такой “сервер” для клиент/серверного режима работы.
“Все проблемы у клиента начались когда он с НЕ лицензионного сервера 2003 перешел на лицензионную XP Home Edition.”
А на 2003-ем какие были проблемы при использовании сервера CodeBase?
“После его проведения напрочь слетают остатки.”
1) Уточните, пожалуйста. Документ проводится в монопольном режиме и в режиме ПДБД? Если это так, то причина может быть в том, что я написал в “Объявление от 12.09.2007” раздела “Дополнительно” данной страницы сайта.
2) Сделайте, пожалуйста, эти манипуляции в “родных” DBF-ах. Там нет этой ошибки?
“Их впечатление - "Ужастно".”
Верните их на “родные” DBF-ы. На мой взгляд, для описываемой Вами, системы совершенно не нужен режим клиент/сервер. Кроме лишних проблем он ничего не даст.
“в случае обнаружения некорректной работы, каким образом вам сообщать об этом”
1) Написать в этом “форуме”.
2) Написать письмо средствами данного сайта.
3) Написать письмо на мой реальный почтовый ящик.
4) Созвониться со мной по телефону, сообщив мне свой телефон в письме.
“и какую информацию предоставлять?”
Сначала сообщите мне о самом факте ошибки. Опишите “тестовую платформу” – версии, режим запуска и т.д. Опишите условия возникновения ошибки. Далее в процессе переписки всё остальное, как правило, выясняется достаточно быстро.
“Периодически 1с на сервере вываливается и ругается на dbeng32.”
Такой режим эксплуатации клиент/серверных СУБД не рекомендуется всеми разработчиками. Надеюсь, сессия 1Са на сервере запускается не в режиме ПДБД?
“Подробностей предоставить не могу, не вижу.”
Жаль. Т.к., если это ошибка не в CodeBase, а в моей части программы то она перетащится и в версию на Advantage.
2. в связи со скользкой темой правомерности такой разработки предлагаю все измененные dll складывать в подкаталок каталог BIN 1с. Оригинальное имя dbeng32 сохранить, а оригинальную dll - в подкаталог. Как реализовано в OpenConf. Все ж оригинальные файлы поставки даже не переименовываются.
“может теперь получится без файлов *.lck”
Да. Этих файлов не будет. Останется из них только 1SxTTS.lck. Но открывать каталог информационной базы данных для общего доступа – придётся.
Уже определено чего не будет:
1) Режима ПДБД.
2) Временного хранилища (операции 32-39).
3) Примитивных запросов (операции 44-50).
4) Низкой скорости чтения БД при большом количестве пользователей.
5) Маленькой стоимости решения в целом.
6) Простоты эксплуатации в части самого сервера БД.
Возможно, не будет:
1) Обратного конвертирования БД в формат 1Са.
2) Контроля типа файлов по расширению (маленькие, большие буквы).
3) Обязательное наличие файла DBEng32.ini в каталоге информационной базы данных.
Возможно, добавится:
1) Прямые SQL запросы.
2) Возможность использования Linux в качестве серверной ОС.
“в связи со скользкой темой правомерности такой разработки предлагаю…”
Сделать так – не составляет труда. У Вас есть информация об таких тонкостях нарушения авторских прав? В чем разница между моим решением и решением в OpenConf? Я не смог найти такого материала. Пришлите мне, пожалуйста, если у Вас есть эти материалы.
Чего не будет написано много :)
Гораздо интереснее услышать "что будет" ;)
Особенно в свете следуюших высказываний:
"Не будет" - Маленькой стоимости решения в целом.
"Возможно не будет" - Обратного конвертирования БД в формат 1Са.
Если есть такая возможность - хотелось бы услышать ожидаемые плюсы.
“Если есть такая возможность - хотелось бы услышать ожидаемые плюсы”
Основной “плюс” написан в разделе “Дополнительно” к данной разработке в виде “Объявление от 11.10.2007”.
“"Не будет" - Маленькой стоимости решения в целом.”
Если сравнивать цены CodeBase 6.5 и Advantage 8.1, то они различаются, примерно, как и скорость их работы.
“"Возможно не будет" - Обратного конвертирования БД в формат 1Са”
Оно появилось только в последних версиях DBEng32 (CodeBase 6.5) по просьбе одного из пользователей разработки. Изначально я задумывал, что и прямое и обратное конвертирование будет выполняться штатными средствами 1Са (загрузка/выгрузка). А прямое конвертирование сделано только из-за ограничения на размеры рабочего файла в этих штатных средствах 1Са. Работы по снятию этого ограничения проводились уважаемым romix и, похоже, успешно завершились. Ну и “возможно” обратное конвертирование - будет ;-).
У меня сложилось впечатление, что если и нарушаются авторские права моей разработкой, то в других моментах. Равно как и в OpenConf. И переименование файла это уже мелочи. Но я воспользуюсь решением от OpenConf, т.к., возможно, что автор этой разработки прорабатывал вопрос нарушения авторских прав больше, чем это удалось сделать мне.
“а вы случайно Advantage 8.1 с MS SQL сервером не сравнивали? как они по скорости?”
Нет. Возможно, на сайте разработчиков Advantage 8.1 есть такое сравнение.
Применительно к 1С (DBF и SQL версиям) "лобовое" сравнение серверов не прояснит вопрос скорости. Т.к. в моей разработке используется навигационный инструмент доступа к данным, а в MS SQL его нет. Сравнение же SQLных алгоритмов в этих СУБД будет интересен, если мне удастся реализовать прямые SQL запросы в РУСе. Но, пока, я об этом не думаю – надеюсь, что “родных” средств 1С будет достаточно (в части скорости).
Моя примерная оценка скорости решений на “родных” DBF, клиент/сервер на DBF (CodeBase), клиент/сервер на DBF (Advantage), клиент/сервер на MS SQL делалась следующим образом:
1) На “родных” DBF система работает быстрее, чем на MS SQL.
2) На CodeBase DBF система работает не медленнее, чем на “родных” DBF.
3) Сравнение навигационного доступа к данным CodeBase и Advantage на моей тестовой задаче (без 1С) показывает пятикратное преимущество Advantage на операциях чтения данных и, примерно, равную скорость на операциях записи.
Отсюда я сделал вывод, что решение на Advantage будет работать быстрее, чем SQLная версия 1С. А как это будет работать в реальных условиях, надеюсь, скоро увидим.
При этом решение на Advantage имеет много других преимуществ по сравнению с решением на CodeBase. Меня, пока, смущает только цена данного продукта. И в этом вопросе надо сравниваться с решением на MS SQL, включая, дополнительные затраты на дописывание в конфигурации прямых запросов для повышения скорости SQLной версии 1С.
Возможно вы могли бы объединить усилия с Александром Орефковым?
“нет ли у Вас планов реализации поддержки одного из бесплатных серверов БД?”
Мне не известно ни одной бесплатной СУБД с навигационным методом доступа к данным поддерживающих клиент/серверный режим. А моделировать SEEK и SKIP с помощью SELECT это очевидный бред.
“Возможно вы могли бы объединить усилия с Александром Орефковым?”
Мне от него предложения не поступало. А то, что он делает по отношению к SQLite это совсем другая задача.
“…поддержки … бесплатных серверов БД…”
"файлы lck... удалились... остались" - так и задумывалось.
"монопольном и немонопольном режиме отличается в разы" - естественно.
""растет" очень медленно..., загрузка...на нуле, размер...не увеличивается." - Оно, наверно, еще и DBFы читает ;-)))
А по сравнению с родными DBFами как изменилась скорость?
Стандартные DBF - время проведения ~1 с.
Codebase (монопольно) - время проведения ~1 с.
Codebase (не монопольно) - ~ 60 c. ожидания пока появится первое сообщение + время проведения ~60 с.
Общий объем DBF файлов базы ~1,5 ГБ.
На моих тестах, после решения проблемы с файлом транзакций, скорости во всех вариантах отличаются на +-10%. Естественно, т.к. мы говорим о локальном режиме, то после перезагрузки системы первый замер отличается от последующих - в разы. Но если сравнивать первые замеры между собой, то они отличаются также, как и последующие между собой - на +-10 процентов.
Поставьте единицу в строке #14 файла INI. ;-))) Интересно, как изменится время в монопольном режиме? Для Вашего теста (проведение "разом" нескольких документов) можно поставить в строке #13 значение больше единицы - это должно положительно повлиять на любой режим запуска сессии 1С. Но сначала посмотрите размер файла транзакций, чтобы N транзакций поместились на RAM диск.
У нас база DBF (самописная) крутится на сервере терминалов W3K. Размер базы свыше 9 Гиг, максимальный размер файла 1.3 Гиг (табличная часть одного из документов) - проблема 1Гига и 100%-загрузке проца решена благодаря замене Kernel32 на Kernel37 (автору - огромный респект :) )
В базе нонче работает 30-40 пользователей одновременно (сервер 2х4-ядерный XEON, RAID10, оперативки 4 Гига, своп отключен). Все бы ничего, но подбираемся к 2 Гигам.
Сейчас тестируем Вашу разработку на тему преодоления барьера 2Гига в терминальном режиме. Сервер СВ даже не ставили, т.к. собираемся работать в режиме ПДБД - только скопировали содержимое каталога BIN_CB\BIN. Базу сконвертировали через предлагаемую утилиту ConvDBF.exe
Попробовали "добить" самый большой DBF до размера свыше 2Гиг. На 9-ти Гигах опыт остановили, т.к. надоело :) - проблем не обнаружили. Попробовали запустить одновременно 30 пользователей, на на 16-ти "споткнулись" об ограничения старого тестово компа. Ближайшее время будем тестить на родном. Сейчас проверяем конвертацию туда-обратно, дабы откатиться в случае чего назад. Вообще - страшновато, т.к. потеря даже одного дня - катаклизм немалого масштаба :))
Хотел бы посоветоваться на тему дальнейшего масштабироваия системы с точки зрения количества пользователей. Будет ли система работать бастрее/надежнее, если задействовать сервер СВ на отдельном компе, соединенном с сервером терминалов по второму сетевому интерфейсу?
Отчеты о результатах буду, по-возможности, выкладывать здесь :)
"Сейчас проверяем конвертацию туда-обратно, дабы откатиться в случае чего назад." - Обратное конвертирование не спасет базу данных от возможных ошибок в моей разработке.
"Вообще - страшновато, т.к. потеря даже одного дня - катаклизм немалого масштаба" - Тогда переходите на SQLную версию 1С.
"Будет ли система работать бастрее/надежнее, если задействовать сервер СВ на отдельном компе, соединенном с сервером терминалов по второму сетевому интерфейсу?" - Немного надежнее, но сильно медленнее, чем в режиме ПДБД. В такой схеме сервер терминалов или сервер CB - лишнее звено.
"Обратное конвертирование не спасет базу данных от возможных ошибок в моей разработке." - Имеется ввиду, например, невозможность работы 30-ти пользователей, сильные тормоза и т.п. Понятно, что ошибка, появившаяся в базе при работе под СВ не будет исправлена при обратном конвертировании.
"Тогда переходите на SQLную версию 1С", - любой переход - катаклизм, а если он сопровождается заваливанием базы - катаклизм вдвойне :) А SQL мы пробовали - база начинает жутко тормозить (раз в 20 замедляется простой интерактивный отбор в общем журнале документов), а для нас это - смерти подобно :)
Сейчас сделали конвертацию в СВ, сделали 150 новых документов, сконвертировали назад - оригинальная 1С все подняла, все видит, все работает, документы на месте. В-общем, будем пробовать дальше :)
"В такой схеме сервер терминалов или сервер CB - лишнее звено.", - т.е. терминальная сессия на одном компе, обращающаяся к серверу СВ на другом компе будет работать медленнее, чем локальная 1С на компе пользователя, обращающаяся к серверу СВ? Странно.
Если скорости будут одинаковые, то у терминала все равно есть выигрыш - требования к локальным станциям минимальные (они вообще могут быть на Линухе), да и 1С на них всех устанавливать не нужно :)
1. Будут ли работать компоненты "бух.учет" и "расчет" в формате СВ? Ибо утилита ConvDBF.exe на базах, содержащих план счетов ругается на невозможность открыть файл *.cdx, а на базе, не содержащей план счетов - конвертирует без вопросов. Сейчас пытаемся обойти это путем стандартной выгрузки/загрузки данных.
2. Возможна ли обратная конвертация из СВ в "родной" формат путем штатной выгрузки/загрузки данных?
"Будут ли работать компоненты "бух.учет" и "расчет" в формате СВ?" - Да.
"...на базах, содержащих план счетов ругается на невозможность открыть файл *.cdx" - А этот файл CDX существует? Какое имя таблицы? Я тестировал конвертирование на комплексной конфигурации - работает. Но если в каталоге базы данных "валяются" DBF без индексных файлов не принадлежащие схеме БД, а в них стоит признак наличия индексных файлов, то будет выдаваться сообщение об ошибке.
"пытаемся обойти это путем стандартной выгрузки/загрузки данных" - Это плохой путь. Работать будет дольше, чем конвертирование. И могут возникнуть проблемы с размером рабочего файла (надо будет использовать разработку от Романа).
"Возможна ли обратная конвертация из СВ в "родной" формат путем штатной выгрузки/загрузки данных?" - Да. Но см. предыдущий абзац.
(135)(Brinya)
Я не об этом говорил. В сообщении (132) данной темы написано "...сильно медленнее, чем в режиме ПДБД". А остальное зависит от железа, задач и т.д.
По поводу "валяющихся DBF" - вполне возможно - проверю. Что-то заваляться за 10 лет могло, тем более что эти конфигурации - второстепенные, и "хозяев" у них было несколько.
По выгрузке/загрузке возникла мысль вернуть стандартную ABBY-бухгалтерию с SQL на рельсы DBF - авось быстрее заработает (перевели в SQL когда-то давно, чтобы преодолеть ограничение 1Гиг). А из SQL "вернуть" можно только выгрузкой. Вот, не люблю я SQL с тех пор, как "познакомился" с лицензионной политикой мелкософта ;)
Завтра переведем одну из "второстепенных" баз (объем 3 Гига, 15 пользователей) на Вашу разработку и покрутим недельку. Будет все ОК - займемся основной базой.
НО есть кучка вопросов, ответы на которые не нашёл в руководстве и здесь, в обсуждении, а именно:
1. касаемо базы: как серверу codebase указать, какую базу он подхватить должен. Я интуитивно сделал в лоб: скопировал всё из папки BIN\CB в каталог базы 1С, помогло :))))))
2. касаемо исполняемых файлов (платформы): как повлияют манипуляции, основанные на kernel33.dll и kernel37.dll на работу оной в windows_vista.
3. как обеспечить работу на сервере нескольких баз. То есть, крутиться на codebase должна только одна база, с которой по сети работают юзеры, другие же базы исключительно локально.Проблема, понятно в том, что после изменений в папке Bin штатной 1С, попытка запустить немодифицированные базы неудаётся по очевидной причине (ошибке): не найден файл DBEng32.ini. Неужели придётся конвертировать и остальные базы то же?
Ответы по пунктам вопросов:
1) См. в файле DBEng32.doc, раздел "Установка", последний абзац.
2) Эти манипуляции решат "проблему 1 гигабайта" ;-) Я не проверял данное решение в "windows_vista". Но, т.к. "проблема 1 гигабайта" и её решение не зависит от версии Windows-а, то, думаю, проблем не возникнет. Если же возникнут - пишите мне, исправлю. Рекомендую проверить работоспособность этой разработки в "windows_vista" на тестовой базе данных (в локальном режиме) с помощью внешней обработки из Test.zip по ссылке
3) Решений два:
а) Воспользоваться текстом их DBEng32.doc, раздел "Настройка", пункт "Строка №8".
б) Использовать два каталога исполнительных файлов 1С и организовать для пользователей удобный выбор вызова 1cv7.exe из каталога соответствующего формату базы данных. Это решение - предпочтительно!
окей, спасибо за разьяснение.
Тогда ещё вопрос. В чём именно заключается конвертация базы хитрой утилитой ConvDBF.exe ? обратима ли эта процедура?
З.Ы. при настройке сервера утилитой CBAdmin.exe где именно указывать путь к базе 1С? ЯВНО инструкция по этому вопросу в инструкции отсутствует, по-моему.
З.З.Ы. запустил базу на клиентской winVista_business. работает. сама база на Win2kserver
1) "В чём именно заключается конвертация базы хитрой утилитой ConvDBF.exe ?"
Эта утилита меняет заголовок DBF файлов и тупо переписывает, без изменения, все записи исходной таблицы в результирующую таблицу. Еще меняет расширение имен файлов с DBF на dbf. Я поленился сделать "прямую" модификацию заголовка DBF файлов для ускорения "конвертирования", т.к. данная утилита выполняется редко.
2) "обратима ли эта процедура?"
См. в DBEng32.doc раздел "Установка", пункт № 3. Но если размер таблицы в "родном формате" превысит 1 гигабайт, то придется пользоваться разработкой "Kernel3x". А если превысит 2 гигабайта, то 1С работать не будет.
3) "где именно указывать путь к базе 1С?"
"Вызвать CBAdmin.exe"->"Нажать клавишу F1"->"Menu Reference"->"Server"->"Settings"->"Files/Directories"->"Default Directory". Еще смотреть в DBEng32.doc раздел "Настройка", пункт "Строка № 15". Далее читать раздел, ссылка на который, дана в данном пункте.
(141)
1) "имеет ли смысл ставить Вашу разработку под управлением WinXP_HOME ?"
Если в Вашей конторе используют в качестве серверной ОС такую версию Windows-а, то мою разработку не надо использовать. Будет, только, хуже...
2) "...если, прямого обращения к dbf-файлам нет...большее количество юзеров смогут работать без тормозов?"
По теории - да. А по практики одни причины "тормозов" устранятся, а другие причины "тормозов" - появятся. Подробнее см. предыдущий абзац. ;-)
(142)
"устал ждать. часа 2,5 крутилась. вырубил."
Я не совсем понял к чему это (142-ое) сообщение. Но мне кажется, что Вам надо посмотреть описание причины "проблемы 1 гигабайта" в и задать мне вопросы по существу.
1. обьясните мне, плиз, почему под WinXP_HOME будет хуже работать? файлов же меньше открывается (только *.lck) и данных меньше по сети бегает..... что-то не понимаю я. Это для меня наиболее важный вопрос.
2. 142е сообщение в ответ на 139 п2. я потестил под вистой kernel3x - работает :)
3. если запустить сервер CB, потом вызвать CBAdmin.exe и настроить, как Вы сказали, то после перезапуска, сервер не видит свои служебные файлы (ACCOUNT4.dbf и иже с ними) и вылетает/закрывается. Я предлагаю прописать подробнее этот пункт в DBEng32.doc :)
1) "обьясните мне"
Прежде всего, дело не в "WinXP_HOME", а в самой "организации" выч. процесса в Вашей конторе :-(
2) Я не понимаю - зачем Вы тестируете Kernel3x.
3) "настроить, как Вы сказали, то после перезапуска, сервер не видит свои служебные файлы"
Я не сказал - как настроить. Я дал Вам ссылки на документацию - где надо читать. Там ВСЁ написано. А для использования моей разработки в "штатном режиме" настраивать сервер в части пути к базе 1Са - не требуется.
++2) Я не понимаю - зачем Вы тестируете Kernel3x.++
см (139), Ваши же, hogik, слова:
++2) Эти манипуляции решат "проблему 1 гигабайта" ;-) Я не проверял данное решение в "windows_vista". Но, т.к. "проблема 1 гигабайта" и её решение не зависит от версии Windows-а, то, думаю, проблем не возникнет. Если же возникнут - пишите мне, исправлю. Рекомендую проверить работоспособность этой разработки в "windows_vista" на тестовой базе данных (в локальном режиме) с помощью внешней обработки из Test.zip по ссылке
++А для использования моей разработки в "штатном режиме" настраивать сервер в части пути к базе 1Са - не требуется.++
Что ;t такое штатный режим? исполняемые файлы codebase (из папки BIN\CB) скопированы в пакку с dbf-базой? Ибо в противном случае откуда сервер codebase узнает ГДЕ БАЗА ЛЕЖИТ?
* имея ввиду "настроить, как Вы сказали" я предполагаю ровно это "Я дал Вам ссылки на документацию - где надо читать. Там ВСЁ написано."
* вычислительный процесс в сетевой dbf-базе 1С7_бух организован стандартно,ничего не изменить тут. база на сетевой шаре и всё.
--
З.Ы. пока решал, ставить ваше детище или нет, натолкнулся на ограничение LanServer в XP_Home - всего 5 подключений одновременно, больше нельзя. Придётся, видимо "подготовить" винду, пользуя Half-open_limit_fix_4.1.exe и LanServer_NoConnectionLimit.rar для снятия ограничений на максимальное количество полуоткрытых TCP-соединений и на макс. количество входящих сессий :)
Извините, я устал давать ссылки на описания. Буду их "отображать" для Вас прямо в обсуждении данной разработки. Всё, что помечено символом "(с)" - взято из описаний разработок или сообщений данной темы!!! Но начну с конца Вашего (151) сообщения.
0) "натолкнулся на ограничение LanServer в XP_Home"
Это и есть самое первое, что надо делать при организации "выч. процесса в Вашей конторе"(с). Надо "натолкнуться" на информацию и начать её изучать, понимать, задавать вопросы, правильно её использовать и т.д. А еще, мне кажется, имеет смысл уважать свободное время другого человек (т.е. автора разработки) и не путать "бесплатное использование разработки" с "б... использованием разработчика".
1) Был мой вопрос к Вам: "зачем Вы тестируете Kernel3x" и Вы его не поняли.
Ответы:
а) "Одним из недостатков DBFной версии “1С:Предприятие 7.7” является ограничение на размер файлов – 1 гигабайт."(с) - У Вас ВСЯ база "общим размером ~156МБ"(с)
б) "Установка Kernel33.dll не требуется при использовании сервера CodeBase."©
2) Вы N-ый раз спрашиваете: "откуда сервер codebase узнает ГДЕ БАЗА ЛЕЖИТ?" и "Что ;t такое штатный режим? исполняемые файлы codebase".
Ответы:
а) "После подготовки базы данных необходимо в каталоге информационной базы (рядом с DBFами) создать “каталожный” файл DBEng32.ini. В нем необходимо набить одну строчку – полный маршрут к DBF файлам с реальным именем диска на сервере (в смысле компьютере). Этот же маршрут должен быть определен как Shared ресурс для всех рабочих станций. В окне запуска 1С можно использовать две формы задания пути к базе данных:
\\сервер\ресурс - для доступа к базе с рабочей станции или сервера.
диск:\каталог – для доступа из задач, запускаемых на сервере.
Использовать “Map Network Drive” нельзя."(с)
б) "Строка № 15: Флаг управления “форматом” пакетов от клиентов к серверу.
Значение 1 – не включать в пакеты полный маршрут к DBF файлам, 0 или пустое значение включать в пакеты полный маршрут к DBF файлам. Подробнее смотрите в пункте № 6 раздела “Производительность”."(с)
в) При передаче информации от клиента к серверу CodeBase включает в пакеты полный маршрут к DBF файлам. В связи с этим рекомендую размешать информационную базу данных в каталогах с коротким маршрутом. Это немного снизит объем передаваемой информации от клиента к серверу. С помощью настроек в файле DBEng32.ini можно, вообще, отменить помещение в пакеты маршрута к DBF файлам, установив единицу в строку № 15. В этом случае система будет искать файлы в “Default Directory” сервера CodeBase и вступит в силу ограничение ”один сервер – одна база”. Это понятие описано в разделе “Прямой доступ к базе данных (ПДБД)”. При использовании этой возможности не отменяется заполнение строки № 1 файла DBEng32.ini. Хотя она и не используется для режима работы с сервером, но её корректность проверяется программой. А в случае работы в режиме ПДБД значение этой строки используется для доступа к файлам.©
вообще, имеет ли смысл ставить Вашу разработку на "сервер" под управлением WinXP_HOME ? в диспетчере сервера видно, что клиентом открыты только lck-файлы, то есть, я правильно понимаю если, прямого обращения к dbf-файлам нет, соответственно уменьшится нагрузка на сервачок в плане перекачивания по сети кучи dbf-файлов, то есть большее количество юзеров смогут работать без тормозов?
{"B","0","0","12","0","0"," 1100448 "} - вот последняя строчка, которую выдала одна обработка.
{"B","0","0","12","0","0"," 1100435 "} - а это соответственно, на втором экземпляре проги.
З.Ы. релиз 27й вертелся на Vista Business со всеми последними обновлениями (соответственно и OrdNoChk.prm то же присутствует)
- поясните плиз ситуацию поподробнее.
:) Ваши пред[поло]ложения, CheBurator
- имхо, эта ситуация свидетельствует о чем-то очень-очень неправильном.. такая простая задача как экспорт в текстовый файл пары платежек...
.. что значит "не могла экспортировать"...??? какие ошибки вываливались? что именно не могла...?
1) См. в комментариях к данной разработке:
Сообщение 63 после слова "Итак:" первый пункт.
Сообщение 64 первый абзац.
2) См. в файле DBEng32.doc из архива BIN_CB_xxxx.ZIP:
В разделе "Установка" текст после первой картинки.
В разделе "Производительность" 4-ый и 5-ый пункт.
Моя часть разработки бесплатна. А сам сервер - цитата из DBEng32.ddoc:
"Купить CodeBase 6.5 for Windows можно на сайте www.codebase.com. Цена системы на десять пользователей около 300 долларов, а без ограничения количества пользователей около 1000 долларов. Есть еще и другие варианты лицензий. Можно ничего не покупать – пользоваться сервером на 10 пользователей включенного в мою разработку."
В режиме ПДБД (локальный режим, например, для терминал сервера) разработка не имеет ограничения на количество пользователей.
вот здесь товарищ в 22 посте упоминает сабж
Цитаты из ссылки в (164):
«разработчик его нашел какую-то фигню в кодебазе сервере»(с)
«это решение стоит 2 года минимум в 30 магазинах, и никаких проблем»(с)
А разработчики «CodeBase 6.5» лет 10 продают свою систему по всему миру. Думаю, у меня другие представления о «проблемах». Знал бы об их «гениальном» алгоритме транзакций раньше – вообще не делал бы свою разработку на «кодебазе сервере»(с) :evil:
В "CodeBase 6.5" два формата DBF+CDX файлов:
1) Стандартный формат, совместимый с FoxPro. И его можно читать, как Вы указали в цитате из #166 сообщения.
2) Формат "Large File Support" со снятыми ограничениями на размер DBF файла. Именно этот формат используется в данной разработке. В этом формате изменена структура CDX-ов и другой алгоритм блокировки. Сам DBF файл совместим (до размера в 2 гигабайта) с форматом FoxPro. Т.е. его можно читать в однопользовательском режиме без активизации индексов. Кроме этого, при создании, DBF файлов установлена кодировка "cp1252 - Windows ANSI code page used in Visual FoxPro", а в "родных" DBF-ах установлено "cp0 - Supports FoxPro 2.x file formats which do not use a code page". Но средствам чтения 1С-а это безразлично.
Уточните, пожалуйста, Вашу задачу. Т.к. если требуется читать в среде 1С, при использовании моей разработки, то можно использовать средства РУС. А если "автономно", то только средствами "CodeBase 6.5" с установкой "Large File Support" или писать программу чтения DBF-а как обычный файл с "разборкой" заголовка DBF-а.
Хорошее дополнение к сообщению #168 - "Записать, Удалить". ;-)
Вы не уточнили задачу. :-(
Файл принадлежит конфигурации или он внешний?
Как этот файл образовался?
Если файл принадлежит конфигурации, то можно читать "операциями" РУС-а: 41,42,43. Но писать и удалять записи можно только "родными" средствами 1С-а.
Если файл внешний, то надо делать его обработку средствами API самого "CodeBase 6.5", особенно, если требуется обновление данных.
Можно ли раскрыть суть предложения,а то вроде многие работали и работают,и ничего страшного..
Сергей.
В "CodeBase 6.5" в процессе выполнения транзакции производится реальное изменение DВF и CDX, а "старое" состояние записей запоминается в журнале. В случае фиксации транзакции производится просто очистка журнала, а обновления уже лежат в таблицах БД. В случае отката транзакции - читается журнал и производится "обратная" модификации таблиц БД. При таком алгоритме, в случае "обрушения" сессии 1С-а, необходимо обязательно произвести откат транзакции на основании журнала транзакций. При использовании "CodeBase 6.5" в режиме клиент-сервер это сделает сервер БД. А в режим ПДБД (stand-alone) это никто не сделает, т.к. журнал транзакций - это рабочий файл о котором запуск новой сессии ничего не знает. И "кусок" транзакции останется в базе данных. А т.к. в наших задачах транзакции большие и долго выполняются, то вероятность "обрушения" сессии в момент выполнения транзакции - очень велика.
Изначально режим ПДБД задумывался как (текст из DBEng32.doc):
"Режим ПДБД предназначен, в основном, для проведения регламентных работ с базой данных (пакетное проведение документов, восстановление последовательностей документов, запуск срочных к предъявлению отчетов, тестирование и исправление информационной базы данных и т.д.)."(с)
Т.е. использовать ПДБД можно только для работ, проводимых под контролем администратора БД с обязательным копированием и восстановлением копии в случае аварийного завершения сессии 1С-а. Иначе говоря - нельзя использовать ПДБД в многопользовательском режиме.
1) "есть ли в адвантедж и датабэйз,блокировка 1cjournal как в дбф"(с)
В самих СУБД (CodeBase 6.5 и Advantage x.x) в момент выполнения транзакций возможна блокировка на уровне отдельных записей таблицы. В "DBEng32" версий 5.х.х.х/6.х.х.х блокировка выполняется на уровне отдельных записей. Но перед выполнением любой транзакции (не только при проведении документа) выполняется блокировка некоторых байт служебного файла 1SxTTS.lck и таким образом обеспечивается последовательное выполнение любых транзакций. Т.е. ожидание блокировки журнала (файл 1SJOURN.DBF), в штатном алгоритме 1С-а, монополизирует работу системы меньше, чем принятый алгоритм в "DBEng32". Но, таким образом, обеспечивается более устойчивая работы системы.
2) "я прочитал что sql позволяет читать измененные таблицы"(с)
Не "измененные", а "изменяемые" таблицы в процессе выполнения транзакции в части не "затронутых" транзакцией записей, т.е. позволяет читать "старое" состояние данных. Аналогично работает и штатный "движок" для DBF-ной версии 1С-а. И, естественно, "DBEng32" работает аналогично. Читать таблицы можно в любом варианте "движка" 1С-а вне транзакции при выполнении транзакции в другой сессии 1С-а.
0) Блокировка таблицы 1SJOURN это искусственный прием. Эта блокировка выполняет функции "семафора транзакций" для упрощения проблемного программирования. Существуют алгоритмы/разработки т.н. "Гибкие блокировки". Реализуются они на SQL-ной версии 1С-а. Но при использовании такого инструмента проблемному программисту (на уровне конфигурации) придётся прописывать "ручками" логику блокировок в алгоритмах, начиная от "нумераторов" и кончая "проверкой остатков" при проведении документа.
Возможна реализация инструмента "гибкие блокировки" для любого движка 1С 7.7 (кроме штатного "движка" на DBF-ах). Но, я в своих разработках "не открыл" эту возможность для проблемного программиста, т.к. это сильно усложняется процесс программирования проблемному программисту... ;-)
"...что лучше использовать ADS или Codebase ?"(с)
Если говорить о "1С 7.7" и не рассматривать SQL-ну версию.
То однозначно - ADS, если у Вас использовался сетевой (не терминал-сервер) режим эксплуатации. Иначе оставаться на "родном" движке (DBF-ном) и заниматься снятием количественных ограничений СУБД на уровне предметной области. И в качестве "костылей" для СУБД применять мои решения опубликованные на данном ресурсе.
Вы можете заказать платную консультацию или разработку у автора. Будет создан приватный заказ на «Бирже заказов» для автора.
№ 14664
Создание 01.03.07 00:00
Обновление 30.03.10 00:00
Просмотры 63101
Загрузки 774
Рейтинг
59
Комментарии 180
Код открыт Не указано
Рубрики Внешние источники данных Разработка внешних компонент
Кому
Системный администратор
,
Разработчик
Тип файла Компонента, плагин (dll, vbs,..)
Платформа
Оперативный учет 7.7
,
Бухгалтерский учет 7.7
,
Расчет 7.7
Конфигурация 1C77
Операционная система Windows
Страна Россия
Отрасль Не имеет значения
Налоги Не имеет значения
Вид учета Не имеет значения
Доступ к файлу Бесплатно (free)