kos

платформа 8.3.8.2088
при подключении к 1с77 для полей "Строка(Х), Х>100" выдает сообщение

ВнешнийИсточникДанных Поле XXX: Для строки фиксированной длины запрещено задавать длину строки более 100 символов

Что делать ?

Прикрепленные файлы:

error.png

платформа 8.3.8.2088
при подключении к 1с77 для полей "Строка(Х), Х>100" выдает сообщение

ВнешнийИсточникДанных Поле XXX: Для строки фиксированной длины запрещено задавать длину строки более 100 символов

Что делать ?

Прикрепленные файлы:

error.png

платформа 8.3.8.2088
при подключении к 1с77 для полей "Строка(Х), Х>100" выдает сообщение

ВнешнийИсточникДанных Поле XXX: Для строки фиксированной длины запрещено задавать длину строки более 100 символов

Что делать ?

Прикрепленные файлы:

error.png

просьба добавить еще одну ссылочку в дисклаймер
(по теме "переустановка офиса 2003-2010)

Траблы и решения описаны здесь:
https://blogs.technet.microsoft.com/the_microsoft_excel_support_team_blog/2012/11/12/microso­ft-excel-or-microsoft-word-does-not-appear-in-dcom-configuration-snap-in/

просьба добавить еще одну ссылочку по теме в дисклаймер (важно для excel 2003-2010 при переинсталяциях)
https://blogs.technet.microsoft.com/the_microsoft_excel_support_team_blog/2012/11/12/microso­ft-excel-or-microsoft-word-does-not-appear-in-dcom-configuration-snap-in/

сенкс

по сути сабжа

вот нарыл еще очень хорошую статью на ту же тему, может кому пригодится
http://www.avtomat.biz/blog/nastroyka-klastera-1s-83
( Модераторам: оставляю здесь не как рекламу, а как полезную ссылку по той же теме )

Мне "та" статья помогла "побороть" вылеты 1с8.3 при больших нагрузках
(конечно же с применением мозгов 8))

В чем отличие от ДАННОЙ ?

В ТОЙ статье - человек привёл реальные параметры настроек своего кластера
которые у него используются в "продакшн"
и (самое главное) ОБЪЯСНИЛ ПОЧЕМУ они отличаются от значений "по-умолчанию"

В ЭТОЙ же статье (по сути) разжевывается тот же самый "хелп" - нет практических указаний.
Как обычно = "у каждого свои настройки, обращайтесь, помогу, за $"
(Автору: не в обиду сказано, просто факт, извините.)

Еще раз по поводу отключения статистики.
Мои аргументы, так сказать:

аргумет первый, "железный" (админский)
* используем RAM (что изначально быстрее HDD)
* не хочу хранить в памяти "лишннюю" информацию (место, пусть мало, но всё же)
* не хочу нагружать CPU расчетами планов - хочу заставить работаь его безалтернативно = строго по индексам

аргумент второй, "программный" (программистский)
* предполагаю что все запросы, "вшитые" в 1С - ничтожно микроскопические (а значит уже оптимальны)
* запросы (которые пишет программист) ОБЯЗАНЫ "попадать" в кластерные индексы таблиц (иначе он не программист)

Аргумент третий, админский
* не забываем про регламентные задачи на ночь, куда входит sp_updatests, в том числе.

Как-то так.
При соблюдении всех этих условий - считаю что статистика не нужна (оптимизировать просто - нечего)

(18) slazzy,

1с77 - да, криво, однопоточно.
Не зря ведь все (или почти все) "прикрутили" 1С++ и ПрямыеЗапросы к 77,
и получили побольше вольностей в отношении SQL на стороне клиента....Запросы пишем САМИ, не 1С.
При проведении документов: "ВременныеРегистры" считаю оптимизировать бессмысленно: единственное что может ускорить проведение: правильная расстановка измерений (чтобы select отрабатывал быстрее) и отказ на регистрах от лишних галочек (чтобы не тормозил insert/delete/update).
На этом оптимизация проведения документов заканчивается
(ну кроме - как всегда - собственно "бизнес" логики, и запутанных циклов/ветвлений/.....)
Дальше: начинаем лезть во внутренности 1С77, кишки ей накручивать, оптимизировать SQL сервер...

1С8х
А разве "язык запросов" в снеговике не "просто парсится" самой 1С-кой в обычный SQL и отдается ODBC?
Или Вы про те запросы, которые отвечают за стандартные 1С-вские диалоги ?
Ну так их много и они очень коротки, там параллелится собственно нечему....

У меня = только те, что больше 1й секунды = exec sp_configure 'cost threshold for parallelism',1
Остальные автоматом будут последовательными.....

РЕБЯТА!!!! ОПЯТЬ ВЫ ПРО "ТОЛЩИНУ БАЗЫ" !!!!
Параллелизм не зависит от толщины базы - он зависит от времени выполнения запроса.

А в случае сервера 1С (который типа кластер): разве там не используется параллелизм?
Они явно указывают MAXDOP=1 для всех и всегда ????
Не верится что-то ... Неужели настолько всё запущено.......
уж 2015 год, 2014 SQL, 2012 Win..... а 1С всё в ХХ веке?

Я действительно - не знаю, может Вы и правы....
Внутренности 1С8 не исследовал, но тогда....... Блин, что же делать???
Нужно переходить на OpenERP ! или SAP ....
Шутка....

(16) vasyak319,

1) предполагается что будут использоваться родные 1С-кие кластерные индексы "из коробки"
и в (собственно) запросах никаких хинтов писать не будем.
Естественно: не забываем про порядок полей в запросах (как в индексах).....и т.д.

2) как я уже говорил
* "родные индексы" (как правило) - изначально оптимальны в большинстве случаев
* или Вы хотите еще что-то ускорить ? может insert/update при помощи статистики ? 8))

3) Еще раз:
* физически скорость носителя RAM "без статистики" выше чем HDD "со статистикой"
* конкретно в случае с RAM: нагружать процессор расчетами статистики - считаю абсолютно лишним (+память сьедает)
* индексы никто не отменял (по крайней мере я)
* настаиваю - в структуры и процедуры от 1С (на строне SQL) не нужно "лазить"

4) прочитайте на том же MSDN как влияет статистика на производительность
* как в сторону ускорения - о чем говорят все (в том числе и Вы, и я)
* а также в сторону ухудшения - о чем тоже написано, но никто об этом не говорит (Вот я хочу сказать, но не дают)
Не зря ведь в самом видимом места свойств базы есть флажек "ON/OFF" ?

Не нужно носом тыкать других, читать умеют все (ну или почти).
Да, и простите за мой "футуристический" язык.

Хотелось бы больше услышать "практиков" ( а не умеющих читать теоретиков ).
Коллеги, больше конструктивизма.

(10) Gilev.Vyacheslav,

Конечно же, это не универсальный рецепт на все случаи жизни.
Это ПОДХОД для решения конкретной задачи:

Условия:
* размер БД позволяет "засунуть" ее в RAM
* высокая интенсивность (нагрузка) на SQL - большое количество МЕЛКИХ запросов (у меня иногда до 5000/сек)
* крутится несколько "разношерстных" баз на одном SQL - оптимизировать каждую (средствами 1С) затратно (time=mony)
* в данных условиях узким местом являются: (а) дисковая система (б) процессор

Решение:
1. снять нагрузку на процессор: убираем ВСЁ что заставляет его пересчитывать и оптимизировать
2. отказываемся от тяжеловесных механизмов (таких как CHECKPOINT-ы)
3. помещаем БД в память

Требования:
1. памяти должно быть достаточно
2. память обязательно должна быть ECC !!!!!
3. обязательно "шедулим" бекапы БД из памяти на диск (чаще, чем это предполагает делать SQL авто-CHECKPOINT-ом)

Замечание1:
* у меня замечено, что даже при запуске "бухами" всяких там "концемесячных"
регламентов в 1С8 УПП = нагрузка на сервер сохраняется равномерная
* поэтому (конечно же, прежде всего) такой "подход подходит" (каламбурчик) к 1С77 (особенно при перепроведении БД)
* а уж если их (77) несколко запустить на перепроведение одновременно , тогда держитесь....
* да собственно и пользователи (если оставить БД в памяти на всегда) будут ОЧЕНЬ благодарны за скорость 8))

Замечание2:
* конечно же эти "мои" 1с77 давно используют "костыли": такие как 1С++, "ПрямыеЗапросы" и т.д.
* "ПрямыеЗапросы" (однозначно) использовать в 2х случаях: для форм (параметризованные) и для отчетов (select-ы всякие)
* а вот если говорить про модуль проведения: не думаю, что они будут эффективней "временных регистров" от 1С....
(кстати, известный всем, кто в теме 1с++ = ЁПРСТ = тоже так думает = это я о проведении и прямых запросах....)

ЭТА СТАТЬЯ НЕ РЕЦЕПТ - ЭТО ПОДХОД !!!! И ДЛЯ 1С8 = ОН ТОЖЕ РАБОТАЕТ.

А рецепты - действительно - каждый должен варить сам: по своему вкусу..... и своей ситуации 8))

P.S. Думаю этот подход позволит прожить 1С77 еще 20 лет, к тем которые уже она прожила... 8))