Аналогичная разработка: http://infostart.ru/projects/1359/
Объявление от 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.
Related Posts
Получение логина и пароля техподдержки 1С из базы
Класс для вывода отчета в Excel
Счет-фактура для УПП
Библиотека классов для создания внешней компоненты 1С на C#- Акт об оказании услуг (со скидками) — внешняя печатная форма для Управление торговлей 11.1.10.86
Прайс-лист с артикулом в отдельной колонке
хм… уже ведь была эта разработка ранее… если сейчас новее, скажите, пожалуйста, что изменилось ?
А работают ли в данном случае прямые запросы 1С++ через OLEDB?
ИМХО отказываться от вкусностей 1С++ в угоду этой разработке не с руки, а вот в связке можно попробовать
(Lustin)
“А работают ли в данном случае прямые запросы 1С++ через OLEDB?”
А в 1С++ есть поддержка прямых запросов для DBFной версии 1С:Предприятие 7.7 ?
Для работы с сервером CodeBase есть средства SQL:
(andrey995)
“уже ведь была эта разработка ранее…”
Это она и есть.
“что изменилось ?”
Изменения описаны в History.doc.
2hoqic
Получилось восстановить из кэша гугла обсуждение разработки на 21 декабря 2006 года — почитал дисскусию, так что глупых вопросов задавать не буду.
Я так понял — вы в курсе что 1С++ использует возможность организации прямых запросов к DBFной (xBase’ой версии) 1С Предприятия через объект OleDBData и провайдера vfpOleDB…
вообщем буду изучать…
ЗЫ А как так получилось что обсуждения удалились и на 1С.proclub и здесь… Видимо это намеренно было сделано? Поэтому еще раз прошу прощения за повтор вопросов
(Lustin)
“…возможность организации прямых запросов к 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 и здесь…”
Они удалились вмести с предыдущей публикацией этой разработки. Данная публикация – повторная.
автор, спасибо за разработку, если можно немного слов о том как сейчас поживают вверенные Вами базы работающие на CodeBase, насколько стабильно работают и т.п. вобщем поведение сервера CodeBase за последние полгода
(andrey995)
“…насколько стабильно работают… за последние полгода ”
За “отчетный период” никаких нареканий к продукции Sequiter Inc не было. Сервер не заваливался ни разу. Причин для пересоздания индексов не возникало. На стороне клиента были проблемы под управлением Windows ME, но они успешно исправились в текущей версии моей разработки. Ошибки, исправляемые в моей части разработки, на нашей эксплуатации не отражаются т.к. “лежат” в не используемой нами части 1Са. Снижения производительности и устойчивости системы в целом, по сравнению с “родными” DBFами, пользователи не отмечают. К сожалению, за время публикации моей разработки так и не нашлось потенциальных пользователей, сообщивших мне об ошибках в неиспользуемой у нас части 1Са (за исключением проблемы с запросами и длинными ключами). Это меня и настораживает. У меня складывается такое впечатление, что кроме нас никто не использует разработку. А мои оценки качества разработки, думаю, не совсем объективны. Хотелось бы узнать мнение других пользователей не в теории, а в практике.
Читал все посты по ваше разработке.
почему народ молчит — а непонятно потому что все…
сделайте большую статью, где подробно все опишите (скомпилить из ваших топиков, я думаю проблемы не будет).
вопросы интересуют в первую очередь.
— каково быстродействие вашей базы если сравнить на 3-х вариантах:DBF, SQL и CODEBASE?
— каковы основные причины для использования CODEBASE, а не скуля?
— насколько CODEBASE устойчиво работает с 1Сной базой? (у мен яскуль вертится с конца 2003 года, база не падала ни разу — правда и база не сильно небольшая), насколько для CODEBASE критично отваливание 1Ски по выключению, например, локального компа?
— можно ли под CODEBASE использовать 1С++ (простите меня ламера) — у меня есть отчет, который на ВИАу считает очень долго, под 1С++ — очень быстро — смогу я 1С++ заточить под CODEBASE (при наличии соотв.там всяких одбс драйверов и всего прочего или 1С++ принципиально не ложится на CODEBASE)
..итого — расскажите подробно и тщательно.
понятно, что времени у вас немного — вы сами упоминали об этом, но что тогда пенять что «кому-то интересно или нет?»
и прочего побольше всего.
мне, например, оченнь интересно.
Ув. Сергей (Сhe Burashka)
по крайней мере на 2 первых вопроса (если не на все) автор настоящей разработки уже отвечал в той или иной мере и не раз в топиках (не только на этом форуме), смотрите поиск, как посмотрел его Lustin,
имхо разработано и ранее сказано достаточно для того чтобы заинтересованным, наконец оторвать свои задницы и попробовать таки разработку в работе…
спасибо за ответ.
хочу пояснить на мой взгляд область применимости и отсутствие обратной связи.
есть 2 типа фирм.
1. поставили — должно работать, на деньги на скуль жалко, на программера жалко.. денег нет.. шеф жлобный… базу все время надо переиндексировать и т.д.
2. контора, есть свой более менее постоянный прог.
..имхо п2 — не ваш клиент. там поставят скуль и не будут морочиться.
..имхо п1 и примыкающие к ним — ваш клиент.
для ни х нужно — минимум тех.подробностей. описание которое в комплекте — там никто читать не будет. нужна краткая пошаговая инструкция. взять то-то то-то. скопировать туда-то туда-то. выгрузить базу так-то загрузить так-то.. работать. и кратко но емко — преимущества по сравнению с дбф.
…
лично меня все-таки напрягло то, что надо все-таки переиндексироваться…
на скуле — нет такого.. отваливалось кучу раз — все работает…
…
например, если стойкость базы по сравнению с дбф повышается существенно при некотором небольшом замедлении работы — я бы ряду своих клиентов порекомендовал бы такую разработку.
(Сhe Burashka)
“…все-таки напрягло то, что надо все-таки переиндексироваться…”
Переиндексировать надо, если завалился сам сервер CodeBase. Заваливание пользователя, благодаря технологии клиент/сервер, не приводит к порче базы данных. Сообщение, которое выдаётся при запуске сессии с предложением выполнить переиндексацию можно игнорировать, а если и согласиться с переиндексацией, то это игнорирует моя программа.
“…на скуле — нет такого.. отваливалось кучу раз — все работает…”
Речь идёт о клиенте или сервере? Если о клиенте, то см. выше. А если о сервере, то это, думаю, как повезёт. Обычно в серверах БД предусматриваются средства диагностики и ремонта БД в случае падения самого сервера. Сервер CodeBase в этом вопросе не исключение. А вот если средства сервера не смогут справиться с ремонтом базы данных, то открытая (DBFная) организация данных имеет больше шансов на восстановление ручками.
“…если стойкость базы по сравнению с дбф повышается существенно…”
Это и есть основная причина, по которой делалась разработка.
Соответственно найденный кэш в гугле — для тех кто как и я решил ознакомится с разработкой — там описаны многие моменты…
ок. спсб.
имелось именно в виду падение клиентов, а не сервера.
сам сервер у вас, как устойчиво работает? не глючит? проблемы если были — то какие?
Автору, м.б. имеет смысл просто аккумулировать обсужденияи запихивать их общим потоком в доку в виде приложения?
(Сhe Burashka)
О сервере мы вспоминаем только, когда вырубается электричество.
А про “отсутствие обратной связи”, думаю, от контор типа “п1” (по предложенной Вами классификации) не будет поступать конструктивной информации. В прошлой публикации мне приходила куча писем от этой группы пользователей – хорошо, если с конкретными вопросами по настройке и установке разработки, а чаше с вопросами типа “почему не SQL?”.
Если бы моей целью было продажа разработки, то, естественно, надо было бы вовлекать эту группу контор в употребление разработки. У меня, то цель публикации — получить грамотный анализ от сторонних пользователей (с другой конфигурацией, железом, задачами и т.д.).
> меня, то цель публикации — получить грамотный анализ от сторонних пользователей (с другой конфигурацией, железом, задачами и т.д.).
//ye про то и речь.. кто будет неизвестно зачем юзать да и еще отзывы писать.. только в целях о, блин! инересно…
вот я бы дома, например поставил.. и что получил бы? дома мне дбфина нужна — куча регламентной работы, проводиться/восстанавливаться надо.. скуль — неохота, че-нить попроще..ааа.. и не надо.. комп стабильно работает… вот и получается — вроде и есть разработка и интересно..а не надо..
..а вот было бы типа скачал — запустил, само все инстальнулось, на этапе инсталляции спросила базу — само выгрузило/конвертнуло и ..опа — произвести запуск базы в новом режиме? ДА!..
вот тогда еще может и поставил бы даже ради покрутить-попробовать…
Сhe Burashka может и ленивый, но точно не глупый… А лень, как известно, двигатель прогресса. Я бы тоже, «ради интересу», «инстальнул» собранный пакет. 🙂
Из документации на разработку DBEng32.doc
Решение проблемы 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 тогда?
почему не майскуль или постгре, например, или еще что?
сорри за вопросы, не проффессионал я в этом деле (как впрочем и в остальных).
А вот как писать ттебе на мыло, если мыло в профиле скрыто?
(Сhe Burashka)
“А вот как писать ттебе на мыло, если мыло в профиле скрыто?”
Для этого надо пролистать описание моей разработки до конца. 😉
“А почему CodeBase тогда?”
Уважаемый Сергей.
Мы с одним товарищем в этом “форуме” уже дискутировали на тему “а почему не SQL?”. Всё, что там сказано с моей стороны применимо и к вопросу “…задействовать в качестве серверной системы Linux”.
Тьфу, чтоб дать денег — надо еще так напрячься… 😉
короче — поучаствую .. чисто символически..
а скока стоит CodeBase for Linux?
(Сhe Burashka)
“Тьфу, чтоб дать денег — надо еще так напрячься… ;-)”
Вам совершенно не надо напрягаться. У Вас, полагаю, и так всё нормально работает. А вот тем кто сравнивает затраты на покупку серверного софта можно и напрячься – деньги то экономит он, а не я.
“короче — поучаствую .. чисто символически..”
Я не собираю деньги на покупку CodeBase, а предлагаю заинтересованному человеку приобрести себе “CodeBase for Linux” и участвовать в доработке и тестировании моей разработки под сервер на Linux-е.
(hogik)
“Можно по подробне про работу 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. Хотя и были мысли делить файл по кварталам, месяцам и т.д. Но к лимиту стали подбираться файлы, который не возможно разделить по периодам. Мой совет Вам – принимайте решение о переходе на другую платформу в смысле СУБД, чего тянуть…
(hogik)
Спасибо все понял. Даже потестил ФайлМонитором. Действительно блокируется область файла с адреса 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 не откажет в решении этого вопроса?
(hogik)
Это то я сразу и сделал. Не за работало. Посмотрел код. И тож пришел к этому выводу.
Про 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.
(hogik)
Отчет по патчингу 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’ом – может он не откажет в полезном деле помочь.
(hogik)
Смещений я видел больше чем 3FFFFFCC,3FFFFFFF,400000 !!!
Да вот с утра тож об этом подумал. Надо находить все вызовы FileLock/FileUnlock и проверять там смещения.
А как задействовать третий параметр в вызове LockFile()? Я про него думал но т.к. пока асм не освоил не могу определить где этот параметр заполняется. В отличии от 3FFFFFCC и т.п. которые явно видно. Если б можно было перед вызовом ф-ии LockFile() просто вставить инкремент. Вот еще думаю мож 1с в 27 версии пропатчила DBEng32 и вставила еще туда sleep при блокировках 🙂 (можно же помечтать)
(hogik)
Так и не нашел заполнение 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() без настроек. Но это хуже.
(hogik)
При наличии доступа к авторам обеих разработок ковырять библиотеки на таком уровне –последние дело!
Да ладно, интересно же 🙂 Но опасно 🙁
Чем рискую: если ошибся со смещением то могу получить не правильные блокировки, и вылет 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 карта и драйвер для неё? (Ответ, думаю, лучше послать по почте).
а вот я сделал вроде как по инструкции, запустилась 1с 3 окна и конфигуратор, а в окне сервера codebase должны быть какие-нибудь опознавательные знаки что к нему кто-то подконнектился? например поля users, transactions, connections ?
или даже так, должна ли работать база без запущенного сервера Codebase? меня по крайней мере запускается. Работает ли эта компонента с 27 релизом 1с?
(angro)
“…должна ли работать база без запущенного сервера Codebase?”
Да, если в запуске сессии 1С указан каталог информационной базы данных на локальном диске. Например: “C:BASE”. А сессия 1С запускается на той же машине где лежит сама БД. Это называется “режим ПДБД”. Он описан в DBEng32.doc.
“Работает ли эта компонента с 27 релизом 1с?”
Я в этой версии не пробовал. Несовместимость версий в большинстве случаев должна выявиться в момент запуска сессии 1С.
а в окне сервера codebase должны быть какие-нибудь опознавательные знаки что к нему кто-то подконнектился? например поля users, transactions, connections ?
и ещё почему-то по сети, не запускается, просто нажимаю на базу, секунду идёт как обычно, потом закрывается без ошибок.
видимо что-то я не доделал, знать бы что.
если у меня база лежит c: estdb то и в dbeng32.ini должна быть эта строчка?
(angro)
“а в окне сервера codebase должны быть какие-нибудь опознавательные знаки”
Да. В окне должно быть больше нуля для: Users, Connections. И больше двойки для Tables.
“и ещё почему-то по сети, не запускается, просто нажимаю на базу, секунду идёт как обычно, потом закрывается без ошибок”
Только заставка выдаётся? Чего пробегает в нижней строчке заставки? Окно 1Са открывается? Файлы *.lck и *.cdx в каталоге ИБД создаются. На диске С: создаются файлы DBEng32*.log?
“если у меня база лежит c: estdb то и в dbeng32.ini должна быть эта строчка?”
Да. Это каталог ИБД на сервере. А в запуске 1Са должно быть \serverресурс.
“видимо что-то я не доделал, знать бы что”
Напишите мне на реальный почтовый адрес. Опишите последовательность Ваших действий.
разобрался, я фразу что локальный путь можно использовать для запуска задач на сервере, понял как «можно запускать на сервере и так и этак».
теперь вопрос, если я помещу файл dbeng32.ini в каталог каждой базы, и в строке 8 напишу 1 или 0, то можно будет использовать одну и ту же установку 1с с codeBase сервером и обычным dbf-ом?
и просьба дайте ссылку на свою статью, не получается в инете найти, думаю не одному мне интересно почитать будет.
у вас написано, что сервер codebase идущий в комплекте можно использовать бесплатно, это для любого использования? можно ссылку на лицензию для этого варианта сервера? сам не нашёл.
(angro)
“…если я помещу файл dbeng32.ini в каталог каждой базы, и в строке 8 напишу 1 или 0, то можно будет использовать одну и ту же установку 1с с codeBase сервером и обычным dbf-ом?”
В DBEng32.doc написано: “Например, для сравнения производительности “родной” СУБД и сервера CodeBase.”. Наверно, надо было написать без слова “например”. Т.к. этот режим сделан для удобства отладки программы в “удалённом режиме”. Т.е. если Вы обнаружите ошибку, то я Вас попрошу провести одинаковые действия в “родной” базе данных и в базе под управлением CodeBase с включённым режимом создания файлов *.log и выслать мне эти файлы. При этом “родную” базу данных лучше использовать не из промышленной эксплуатации, а развернуть тестовую базу данных. Использовать этот режим для промышленной эксплуатации я не рекомендую по двум причинам. Во-первых, немного снижается производительность системы. Во-вторых, этот режим не является простым переключением на родную библиотеку. В моей части программы выполняется значительное количество действий, в которых могут быть и ошибки. Не стоит рисковать промышленной базой данных. Для использования одновременно старого и нового формата базы данных (на уровне промышленной эксплуатации) с одной рабочей станции рекомендую сделать вызов 1Са из разных каталогов.
“дайте ссылку на свою статью”
Этой статьи в интернете больше нет.
“использовать бесплатно, это для любого использования? можно ссылку на лицензию для этого варианта сервера?”
В каталоге BIN_CBCB есть файл 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 для количества пользователей более десяти, то придётся докупить дополнительные лицензии на сайте разработчика.
Есть одна знакомая фирма, там 7 пользователей 7.7-ТиС. Сервер WinXP prof, он же рабочая станция. Есть получение остатков в номенклатуре при выводе строки, раскрашиваются заявки с помощью FormEx. Вобщем стало тормозить. База небольшая 400-500 Мб. Отключение кэшев, восстановление системы и так далее (советы по форуму) не помогли. Сравнив стоимость Server-а машина + лицензии решили попробовать эту разработку (да и просто интересно).
Вобщем на установку ушло 2 часа на всё, скорость выросла на некоторых операциях в 10 раз (например поиск по артикулу в номенклатуре (биноклем)). путешествия по справочникам, журналам стало комфортным. Отчёты формироваться стали быстрее не в 10 раз, но раза в 3-4. Прошло больше месяца, ошибок нету, работает стабильно.
вобщем спасибо вам.
«Этой статьи в интернете больше нет.» — а ещё раз выложить, например на этом сайте.
(angro)
“…ещё раз выложить, например на этом сайте…”
Я свою статью снял с публикации в конце 2006 года. Она лежала в интернете шесть лет. Статья уже потеряла свою актуальность по следующим причинам:
1) В восьмой версии 1Са устранены (по описанию) большинство проблем обозначенных мной в этой статье.
2) Для седьмой версии разработано много чего, что тоже позволяет её использовать так как, надеюсь, планировалось разработчиками — перехват Esc, гибкие блокировки, прямые запросы (для SQLной версии), 100% загрузка процессора при ожидании блокировок, уменьшение монопольных (технологических) процедур, устранение клинчей и т.д.
3) Появилась моя разработка (DBEng32) которая без всяких статей подтверждает или опровергает моё утверждение: “ …задачи, для которых предназначена 1С, и SQL сервер, мягко говоря, вещи не совместимые…”. Т.е. теперь можно реально сравнить производительность, надежность, финансовые затраты, объемы дополнительного программирования, время на изучение и т.д. А не сотрясать воздух бесполезными спорами.
Спасибо Angro за инфу о внедрении. Просьба отражать свои впечателения и в дальнейшем.
т.е. если юзать данный сабж в терминальном режиме — будет типа шоколадно?
Слегка медленнее проводится документы стали.
Не знаю, а смысл тогда в терминале есть?
(angro)
«Слегка медленнее проводится документы стали»
А RAM диск для журнала транзакций используете ?
(Сhe Burashka)
А как запустить терминал сервер на Windows XP ?
Angro то пишет, что — «Сервер WinXP prof».
«А RAM диск для журнала транзакций используете ?» — нет, не использую, надо попробовать. Просто замедление некритичное, может секунда добавилась.
я думаю Сhe Burashka имеет ввиду терминал в принципе.
Обновлен раздел “Тестовая платформа” в DBEng32.doc (описание разработки).
Спасибо автору еще раз.
15 июня запустил в одной конторе. 5 машин, все целероны. Ведущий — Win 2003. Клиенты все XP Prof.
Пока стабильно. Ждемс.
Тестов по скорости еще не проводил, прочих эксперементов тоже.
Впечатления — работа клиента походит на работу терминала — списки тормозят, транзакции летают.
Обнаружил такой нюанс: попытка открыть просмотр заблокированной записи длится несколько секунд.
Владимиру, возможно ли не выкладывать таблицы на общий доступ, а ограничится DBEng32.ini?
и сильно у вас списки тормозят? у меня наоборот стали быстрее работать.
(Item)
“…списки тормозят…”
Посмотрите, какая у Вас стоит версия. Т.к. в предыдущих версиях выполнялась блокировка несуществующих записей в таблице с бесполезным ожиданием их освобождения. Запросы на такую блокировку в мою часть программы передавались из “выше” стоящих программ. В текущей версии есть проверка на реальное существование записи и обход бесполезных попыток блокировки.
“…попытка открыть просмотр заблокированной записи длится несколько секунд.”
Повторюсь – посмотрите, какая у Вас стоит версия. И поставьте в строке № 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 дублируются руками с реального каталога в расшаренный.
Несмотря на некоторую сложность, это есть защита информации от прямого копирования.
Продолжение следует…
(Item)
“Удалил я этот log, никто ничего и не заметил”
Совершенно верные действия при заваливании сервера, если не использовать средства резервирования сервера CodeBase, а в комплекте данной разработки они выключены. Ну, а если Вы захотите их использовать, то надо чинить файл журнала транзакций (этот самый – LOG) утилитой администратора. В составе сервера CodeBase есть еще пакетная утилита для ремонта этого файла. В комплект моей разработки она не включена. Но очень важно при заваливании сервера пересоздать индексные файлы. Сервер CodeBase не плохо распознаёт противоречия в индексных файлах и сообщает об этом либо клиенту, либо в окне сервера. Но 100% гарантии эта диагностика не даёт. Они предлагают протестировать индексы утилитой администратора. Но время её работы соизмеримо со временем пересоздания индексов, если только утилита не увидит сразу, “встроенные в индексы” средства подтверждения их «порчи». А это и обычная задача увидит. Так, что – переиндексировать!
“во время запроса по чтению (не cb транзакции) у одного пользователя все остальные заметно подвисают.”
Причин для такого явления несколько. Есть объективные для архитектуры клиент/сервер – например, слабое распараллеливание процессов. Есть и субъективные – настройка сети, медленные диски и т.д. Надо смотреть “живьём” и настраивать. Однако смею предположить, что при увеличении размера базы и количества, одновременно работающих пользователях – разрыв в скорости между файл серверным режимом и клиент/серверным будет сокращаться. Для этого в данной версии CodeBase сделано много. Например, то с чем работает сервер CodeBase — это уже не традиционные DBF в части индексов.
“…не выкладывать dbf и cdx в расшаренном ресурсе…”
Если не учитывать “административные” действия с базой данных, то можно, было бы и сделать так. Но обязательно надо положить рядом с MD файл 1SUSERS.dbf и запретить пользователям заходить в систему в монопольном режиме. Если у меня не стоит специально на такое расположение файлов проверки (не помню), то должно работать.
(hokiq)
«…при увеличении размера базы и количества одновременно работающих пользователях – разрыв в скорости между файл серверным режимом и клиент/серверным будет сокращаться…»
? или все таки увеличиваться ?
й. Поставил s4server как службу.
Пользовался утилитой AppToService v2.3, с параметром /interact:0.
В результате сервер полностью скрыт от глаз пользователя, вопросов перед остановкой не выдает.
Тест работает нормально.
По каким причинам Вы не рекомендуете ставить s4server как службу?
2. Не дает покоя вопрос: размеры индексных файлов CodeBase существенно (в разы) больше родных, особенно это касается таких монстров как 1SBKTTL.CDX и 1SSBSEL.CDX, в чем такая разбежка?
(Item)
“или все таки увеличиваться ?”
Разрыв, в смысле – разница. Уменьшается. Сужу об этом по тому, что при нашей базе и количестве пользователей, на основных задачах пользователи не заметили перехода на CodeBase. Т.е. не отметили резкого падения производительности. Однако существуют задачи, которые способны парализовать работу сервера CodeBase почти полностью. Например, если сервер выполняет индексирование для одной базы, то в другую базу даже войти проблематично. Не говоря уже о самой работе. А в файл серверной технологии это, с трудом, но удаётся.
“По каким причинам Вы не рекомендуете ставить s4server как службу?”
Именно по этой причине, что: “В результате сервер полностью скрыт от глаз пользователя, вопросов перед остановкой не выдает.” И завершение и запуск сервера должен контролировать администратор базы данных, а не “старт – стоп” Windows-а.
“…размеры индексных файлов CodeBase существенно (в разы) больше родных, особенно это касается таких монстров как 1SBKTTL.CDX и 1SSBSEL.CDX, в чем такая разбежка?”
Я не обнаружил, в нашей базе, ни одного индекса в CodeBase, по сравнению с “родными”, больше чем на 10%. Это в вашей базе сразу после их создания? Или после активной работы с ними? Если после активной работы, то мне хотелось бы с этим разобраться. Только в сравнении с аналогичной работой в “родной” базе.
2 hoqik
Вот сравнительные размеры, конвертация — через выгрузку, после тестирования и т.п.
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
(Item)
Очень хороший результат.
Т.к. в 1Се загрузка делается при открытых индексах, то Вы моделируете, тем самым, длительное время работы системы с активным обновление базы данных. После таких процедур над базой, рекомендуется в любых СУБД заняться оптимизацией (дефрагментацией) индексных последовательностей. Либо дожидаться когда продвинутая СУБД это сделает в фоновом режиме. Сервер CodeBase, в этом смысле, не продвинутая СУБД.
Надо, так же, учитывать, что в утилите 1Са “тестирование и исправление ИБД” флажок “выполнить реиндексацию” не приводит к выполнению этих действий при использовании данной разработки. О чем написано в DBEng32.doc в первых трех пунктах раздела “Эксплуатация”. Наверно, мне надо было написать там конкретно, а не “намёками” – но это так.
вот первый глюк,
при установке этого пакета программ я в dbeng32.ini прописал только первую строку
почему-то сегодня при открытии документов начала ругаться «Access denied», создал и прописал юзера дальше продолжила работать нормально. что бы это могло быть? версия правда 5.1.1.9
(angro)
Если в DBEng32.ini прописана одна строчка, то имя пользователя для сервера CodeBase – PUBLIC. Если “вчера” аварийно закончилась сессия клиента в момент выполнения транзакции, то “сегодня” при входе в сервер производится попытка “убить” зависшую сессию в сервере CodeBase. Это делает клиент, который это обнаружил первым. Если у пользователя PUBLIC нет прав на команду Disconnect, то будет выдано сообщение об этом. Т.е. достаточно пользователю PUBLIC дать права на выполнение команды Disconnect. Признак аварийно завершившейся сессии в момент выполнения транзакции храниться в файле 1SxTTS.lck. Если удалить этот файл то попытки “убить” аварийную сессию производиться не будет. Признак аварийного завершения сессии в момент выполнения транзакции сбрасывается, если запускается система в режиме ПДБД.
Т.е. то, что вы описываете это не “глюк” – так и должно быть. А версию стоит сменить, т.к. “глюк” может возникнуть. См. в файле History.doc первый пункт к описанию изменений в версии 5.1.2.1.
Я с вас торчу! Реально штырит! Читаю как дюдуктив.. регулярно. Молодцы. Так как сам не юзаю сабж — до сих пор так м не смог для себя сделать вывод — в чем основные преимущества…
(70) теперь понятно что произошло
(hogik) Насчет 64-разрядной XP я затрудняюсь что-то сказать, ибо не работал.
Попробую предположить.
Может в системе есть другие задачи с повышенным приоритетом? Тогда слип действительно не возвращает управление через указанное количество мс (чем выше приоритет у грузящей задачи, тем дольше не возвращает).
Я экспериментировал с простой задачей, которая тупо крутится в цикле, и грузит процессор.
Другая задача в это время делала слипы, и замеряла время, а сколько же в действительности делался этот слип (на практике он делается дольше указанного количества мс, если система загружена чеи-то еще).
Если управлять приоритетом «грузящей» задачи, то соответственно изменяется и время слипа у второй задачи. Если же грузящей задаче поставить приоритет реалтайм, то по-моему даже кнопка «ресет» зависает, приходится питание выключать (шутка). 🙂
Тут лежит простенькая программа, которая умеет управлять приоритетами и процессорами запускаемого приложения.
Или можно правым кликом в «диспетчере задач» все это смотреть или изменять.
Вдруг полегчает, если разрешить 1С-ке запускаться только под одним процессором…
Может еще задаче 1С режим совместимости с Windows 95 попробовать поставить.
Мне интересно узнать каков будет результат опыта с изменением приоритета 1C, запуском 1С под определенными процессорами (процессором) и «совместимостью с Windows 95».
(romix)
Приступил к проведению опытов. Начал со “стандартного” запуска задач, когда всё в системе “замораживалась”. Запустил две 1Са. В одной проводится документ. В другой сессии 1Са тоже пускаю проведение документа. По моему алгоритму блокировок транзакций – вторая задача проверяет блокировку определённого байта в неком файле и делает это в цикле со sleep(5000). И в данный момент всё прекрасно работает — другие окна открываются, переключаются, диспетчер задач удаётся вызвать. А при той картине, что я описывал — даже диспетчер задач можно было вызвать только кнопками “Ctrl+Alt+Del”. Т.е. картина не постоянная. И чего-либо в таком случае выявить мне не удастся. Допускаю, что система приходит в такое состояние (с замораживанием) после выполнения на компьютере каких то других программ. Буду наблюдать. Однако точно могу сказать, что в WinXPx64 не всё хорошо с прерыванием по таймеру. Т.к. если сильно загрузить процессор при активном сетевом соединении, то очень часто соединение, в таком случае, разорвётся. В Win2000 такого я не замечал не разу. Либо они не выделяют достаточные кванты времени другим задачам. Т.е. мне напоминает это работу в Win98.
Извините, пожалуйста, что отвлек Вас от Ваших дел на этот вопрос. Буду ждать и наблюдать — какая последовательность выполнения задач приводит к такой “деградации” системы, влияющей на другие задачи.
Спасибо.
(hogik)
sleep(5000) это по-моему круто… Я делаю иначе — слип 1,2,4,8…1024 мс (счетчик далее не увеличивается) при каждой неудачной попытке блокировки, и счетчик сбрасывается в 1 при удачной попытке блокировки.
А пишите в аську 21709980пять, если честно я не понял какой процесс у Вас так грузит систему.
Если этот некий процесс действительно так грузит, и при этом еще имеет повышенный приоритет, то он может вообще не вернуть управление другим задачам (если приоритет реалтайм). И проблема ск. всего — в нем.
(hoqik)
Из любопытства
Зачем клиент dbeng используется 2 tcp порта?
Запросы — это уже классно.
А есть надежда, что можно будет, в запросе, объеденять таблицы ?
Или это принципиально не возможно ?
(Item)
Мне не совсем понятен вопрос. Придётся писать длинный ответ.
1) Сервер CodeBase использует один (в смысле номера) порт — 23165 (по умолчанию). Его можно поменять на стороне сервера и, естественно, поменять в файле DBEng32.ini на стороне клиента.
2) В моей разработке открываются и обрабатываются некие (DD, MD, LCK и т.д.) файлы в каталоге информационной базы. Для этого Windows, тоже использует порты.
3) При работе в конфигураторе устанавливается два соединения с сервером CodeBase Т.е. по одному соединению на каждый процесс “открытия” файл DD. Соединение закрывается вместе с “закрытием” файла DD. С этим связано появление паузы перед сохранением изменённой конфигурации – устанавливается соединение с сервером. С этим же связана одна из причин замедления процесса выполнения логического тестирования ИБД. Т.к. мне поступают запросы на “открытия” файла DD для каждой таблицы базы данных. Исходя из сказанного в данном пункте – лучше использовать режим ПДБД в процессе программирования в среде 1Са и проведения технологических процедур для базы данных.
Если мне не удалось ответить на Ваш вопрос – уточните, пожалуйста, его.
(slawa)
“Запросы — это уже классно.”
Мне даже обидно стало ;-). А индексы со сложными индексными выражениями? А выборка (навигация) не по одному значению реквизита? А выборка (навигация) по любому индексу — не только по доступным в среде программирования 1Са? Чего классного то в этих и других запросах? При использовании, выше названных возможностей, любой отчет будет выполнятся быстрее, чем с применение “запросной системы”. Не говоря уж об других алгоритмах используемых в информационных системах (журналы, списки, “обновление данных” и т.д.). Может быть, запросы ускоряют процесс программирования? Или есть необходимость загрузить на 100% сервер? Или подкупает расхожая фраз – “сеть разгрузить”? Ничего этого нет, если система изначально не проектировалась под “запросные алгоритмы” обработки информации. А в 1С 7.7 этого не делалось! Для эффективной работы системы надо, прежде всего, схему базы данных спроектировать соответствующую задачам. И не использовать ИПСные технологии в АСУПных задачах.
“А есть надежда, что можно будет, в запросе, объеденять таблицы ? Или это принципиально не возможно ?”
Никаких проблем не существует, что бы “вынести наверх” весь xBase. Дольше описывать в документации, чем программировать. Однако, вынося функции xBase в РУС, я преследую цели дать простой инструмент, расширяющий функции 1Са в части работы с БД. А для “Relate/Query” получается очень большое описание функций, которые, на мой взгляд, проще выполнять на встроенном языке 1Са. Да и сервер отдохнет, пока это делается на стороне клиента ;-).
(hoqik)
Смотрел 1Сv7 процесс-вьевером (плагин TotalCmd PE)
1С Предприятие (Клиент) в любом режиме работы
задействует два local tcp порта,
например 192.168.0.2:1121 и 192.168.0.2:1121;
на стороне сервера как и описано в доке, remote 23165, без вопросов,
а вот у клиента именно два.
(hoqik)
Еще
У меня конфигуратор при реорганизации использует аж 4 порта
(Item)
“а вот у клиента именно два”
“конфигуратор при реорганизации использует аж 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. Желательно на английском, французском или японском языке, что бы ни мне, ни им не мучится с переводом.
(hoqik)
«…Если данная картина указывает на наличие ошибки в CodeBase или создаёт большие неудобства в его использовании, то давайте это сформулируем…»
Давайте не будем.
Будем проще.
Будем ждать от Вас новых новостей.
автору: а вот здесь
.. м.б. пригодится
Поставил у клиента. Оказались проблемы при совместной работе с компонентами turbobl и turbomd. Я всегда ставлю их парой. Из за какой возникла проблема — незнаю. Удалил обе — все опять заработало.
Как проявилась проблема:
ТиС — последняя. Перестали проводиться документы реализации. Т.е. сами документы проводяться и отмечаются как проведенные, а движений регистров нет !!!
Из-за этого, естественно, поплыли остатки.
Вошел в отладчик. До половины кода модуля даже трассировка не доходила. вылетало черте-где.
Осторожнее со внешними компонентами !!! Могут и еще быть не совместимости.
Проверил на версиях:
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).
Режим – клиент/сервер на одной машине.
Наблюдал за изменение остатков при проведении существующих и новых документов “Поступление ТМЦ” и “Реализация”. Остатки соответствуют содержанию документов.
Опишите, пожалуйста, Вашу тестовую платформу и манипуляции с документами.
Продолжение ответа-вопроса для Mikhail.
Конфликт возможен именно с TurboBL, если предположить, что в этой обработке делается:
1) Упорядочиваются имена объектов, методов и свойств для применения, например, дихотомического алгоритма поиска.
2) В результате перестановки эти имена приобретают другие порядковые номера.
3) Описание схемы базы данных (из файла 1CV7.DD) подвергается аналогичной обработке. Например, имя таблицы это “объект”, а имена полей и индексов это “свойства”.
4) Решён вопрос поиска имени по его порядковому номеру или в кишках 1Са всегда ищется объект, метод и свойства по их именам.
А т.к. в моей разработке содержимое файла 1CV7.DD хранится самостоятельно, то может образоваться расхождение в порядковых номерах понятий схемы базы данных упорядоченных средствами TurboBL и порядком хранения в моей разработке. В DBEng32 поступают команды воздействия на данные, как по именам, так и по номерам понятий. Чаще — по именам. Если обращение делается по номерам, то будут использоваться не соответствующие понятия. Т.е. будут путаться имена таблиц, полей и индексов.
Если мои предположения верны, то расхождения остатков это мелочи по сравнению с тем, как может испортиться база данных в результате расхождения номеров понятий схемы базы данных.
Надеюсь, что мои предположения не верны…
(hogik)
Надеюсь, что мои предположения не верны…
Может быть в чем-то ты и ошибаешься, но по сути все именно так и обстоит.
Кстати, сейчас функционал 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.
Уточнение. Перед «Пакетным вводом» делается перенос ТА назад, формируются документы, а затем ТА возвращается обратно.
Может быть и из-за этого что-нибудь происходит ? Обычно это все делается в монопольном режиме.
(mihast)
“функционал 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-ы. На мой взгляд, для описываемой Вами, системы совершенно не нужен режим клиент/сервер. Кроме лишних проблем он ничего не даст.
Читаю по-прежнему с большим интересом.
вопрос: в случае обнаружения некорректной работы, каким образом вам сообщать об этом и какую информацию предоставлять?
(desty)
“в случае обнаружения некорректной работы, каким образом вам сообщать об этом”
1) Написать в этом “форуме”.
2) Написать письмо средствами данного сайта.
3) Написать письмо на мой реальный почтовый ящик.
4) Созвониться со мной по телефону, сообщив мне свой телефон в письме.
“и какую информацию предоставлять?”
Сначала сообщите мне о самом факте ошибки. Опишите “тестовую платформу” – версии, режим запуска и т.д. Опишите условия возникновения ошибки. Далее в процессе переписки всё остальное, как правило, выясняется достаточно быстро.
Провел очередной эксперимент. Конфигурация «1С:Аналит», проведение 100 документов «ПриемСтоматолога» на локальной машине.
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) невозможно в принципе, если все клиенты вертятся на одной машине, а ускорение идет на порядок.
(119)(maljaev)
«Патч dbeng32.dll включает родной виндусовый режим кэширования записи на диск, никаких своих кэшей он не использует.»
Всё верно. Только есть маленький нюанс. Данный «патч» не включает «виндусовый режим кэширования записи на диск», а отключает в движке 1Са (CodeBase) выдачу функции FlushFileBuffers. И если у Вас есть полная уверенность, что «никаких своих кэшей он не использует», почему бы и не использовать данный «патч». Наверно Вы под термином «он» подразумеваете конкретную версия Windows, а я Вам «впаривал»© информацию о «многопользовательских системах». И мой опыт программирования в этих самых системах подсказывает, что не «ВСЕГДА сначала проверяет». А после разглядывания исходным текстам CodeBase мне показалось, что разработчикам этого движка тоже опыт подсказывает, что — не всегда. Точнее, не во всех «он». Поэтому я и написал — «не рекомендую», а не — «не работает».
А по сравнению времен выполнения Вашего теста — это естественно. Но есть вопросы. В каком режиме запускалась сессия 1С в ПДБД? Файл транзакций на RAM диске? Какие установлены режимы оптимизации?
(120) В смысле в каком режиме? В разделенном конечно, если это имеется ввиду. ПДБД, то есть без использования CodeBase, режимы оптимизации уж не помню какие но по максимуму в ущерб надежности. Файл транзакций на RAM-диске не размещал, но вопрос во сколько раз может вырости призводительность в этом случае? В несколько раз? И какой размер RAM-диска нужно иметь под этот файл транзакций? Описанных 32Мб хватит?
(121)(maljaev)
«ПДБД, то есть без использования CodeBase»
Наверно, без использование сервера CodeBase? В режиме ПДБД тоже используется «CodeBase 6.5», т.е. ограничение в 1(2) гигабайта на таблицу тоже снимается.
«но по максимуму в ущерб надежности»
Если ничего не меняли в настройках, то оптимизация включается только для монопольного запуска сессии 1С. А в разделенном режиме — повышается надежность в ущерб скорости. И лучше эти настройки не менять.
«В разделенном конечно»
В разделенном режиме, если не использовать RAM диск, система работает медленно. Т.к. для файла транзакций очень часто выполняется FlushFileBuffers, что совершенно не требуется в данном случае.
«какой размер RAM-диска нужно иметь»
Нам хватало 32 мегабайт. Для начала, поставьте в строке #13 файла DBEng32.ini единичку — это количество транзакций после которого требуется писать файл транзакций заново.
(122) Вынесение файла транзакций на RAM-диск увеличило скорость проведения в 3 раза по сравнению с примером (119), но это все равно оставляет разницу с патчем dbeng32.dll в 7 раз. Можно что-то еще подкрутить для столь же глобального увеличения быстродействия?
(123)(maljaev)
«Можно что-то еще подкрутить…?»
Думаю, что для «глобального увеличения быстродействия», в моей разработке, уже ничего не сделать 🙁 Остаётся, только сравнить скорости выполнения с вариантом без «патча» и делать выбор — чего и при каких условиях использовать…