Привет!
При установке пометки на удаление или при отмене проведения документа движения в регистре не очищаются. При этом флаг "Автоматическое удаление движений" стоит.
Из-за чего так может быть?

(318) еще немного и дорастешь до своих вьюх\триггеров\прямой записи...

Хотя, всё потом в снеговике пригодится, там те же грабли вид сбоку.
Борьба за универсальность ограничивает возможности платформы.
Хотя могли бы на селезнёвке выпускать релизы 1с-ины чисто под контретную бд - сскуль\постриги\..и т.д Где использовался весь функционал того же tsq в запросах + создание своих индексов, а не там где галочка "индексировать" ну и т.д

(319) Я уже setattrs переделал на прямую запись в скуль...

(320) Скинь, плз, какую-нибудь свою обработку с разворачиванием 1с++ и формекса из этой обработки.
домашний архив пока недоступен, а знакомая попросила наваять ей отчетик...

(322) на вот, тока там не совсем актуальные версии
http://catalog.mista.ru/public/79515/

тут бесплатно, тока мыло надо ввести, на мыло придёт ссылка

в поделке есть описание, чем запакованы dll, или в коде не помню.

(324) попробовал отключить бух учет штатно, выдает сообщение "Бухгалтерский учет не может быть отключен. Есть проведенные документы..."

Как сейчас получается APPCODE 21 ?
Из описания:
Число, отражающее принадлежность документа к компонентам. Возможные значения:
0 - не принадлежит никакому учету.
(1) 000001 - опер учет.
(2) 000010 - расчет.
(4) 000100 - бух учет.
(8) 001000 - движения периодических реквизитов.
(16) 010000 - существует документ операция у документа (документ может быть не проведен, но тогда должно быть выбрано "Создавать операцию - Всегда" в окне свойств документа).
(32) 100000 - Выполнен метод Операция.Записать(); в документе, принадлежащем бух. учету.
(20) 010100 - Это документ "Операция".
Возможна их комбинация, например 6 = 2+4 (бух. учет + расчет), 7 = все три компоненты. Тип - Число(2).

(323) Спасибо!

(326) Существует операция+проведен по бухучету+проведне  по оперучету

(325) апдейтом замени все CLOSED>0 на 1

(328) при отключении бух. учета (оставить только опер. уч) нужно проставить appcode = 1 и удалить таблицу _1Soper ?

(329) это зачем?

(330) я не помню, проверяет ли он аппкод. емнип, только проведение проверяет
(331) чтоб был проведен только по упручету

Сейчас Closed = 4 это не проведен
Closed = 5 это проведен

(333) 4 - проведен по бухучету

(332) так получится что все документы проведенные, а нужно непроведенные оставить непроведенными.

(333) Closed = 4 - проведен, по бух

(329) не корректно. Например так можно 20 превратить в 1, а это фигня.

(333) ну проверь на копии. вот чесслово, не помню - лет 20 назад делал
(335) значит,  CLOSED&1=1 на 1

Мне нужны значения которые нужно поставить в поле closed при отключении  бух. учета

надо так
update _1sjourn
set closed = closed&1

А CLOSED&1=0 заменить на 0 ?

CLOSED&1=1 на 1, а CLOSED&1=0 на 0
записывается так (340)

(341) - см (340)

аппкод - аналогично

(344) Так?

update _1sjourn
set appcode = 1

(345) update _1sjourn
set appcode = appcode&1

Хотя по идее, без принадлежности документов быть не должно

(346)
Select
21&1

Возвращает 1

(348) через метаданные обойди доки и сделай условие, что если есть галка опер учет, то апкоде =1 иначе 0 и привет
в запросе условие на iddocdef и case воткнешь и всё

а можешь и еще тупее, 2 запроса и

update _1sjourn set appcode = 1 where iddocdef in ($ВидДокумента.Один,....$ВидДокумента.Y)

для тех кто в опер учете и 0 для всех остальных

ну и truncate table _1soper и 1sentry

Уже поправил такими запросами:
update _1sjourn
set closed = closed&1
where IDDOCDEF = 130

update _1sjourn
set AppCode = 1
where IDDOCDEF = 130

Но сообщение осталось, truncate не делал

При желании, можешь и на пустышке нужный мд и словарик создать и хоть на ходу подсунуть в рабочую базу

эт чтоб оно реструктуризацию потом не делало

(355) все удалил, заменил, и все равно ругается...

(254) подсунуть только мд? dd от пустышки не подойдет

(357) чей та ? словари тоже нужен

очисти еще таблицы итогов и итоги по субконто

и табличку плана счетов до кучи

(358) у меня dds файл со своими добавленными индексами. Структура DD сильно отличается от DDS

(361) дык пустышку вскуле создай, и добавь свои поля

а что меняется в словаре, если я отключаю бу в МД?

Не достаточно перетащить МД из скульной базы в файловую и там внести исправление?

(363) на подобные вопросы лучше (полезнее) отвечать самому. Делаешь да смотришь

Да, блин, без опенконнфа - пофигуратор 7.7 действительно неприятен...

(365) Ну вроде сделал: все работает в моем варианте.

(367) это в каком ? просто с мд ?

(368) да, создал файловую пустышку, там поменял признак, вернул мд на место в скуль

(369) по-уму, еще надо в пустышке удалить план счетов, тогда вообще бух учет улетит

(370) да надо бы, но тогда может код править придется: когда новую базу делаешь он автоматически заполняется...

(0) НА инфостарте есть моя обработка  "Поиск Ошибок в регистрах 7.7.
Обработка как раз для Вашей базы. Прогоните базу по всем кнопкам.
Обработка писалась по поиску ошибок ( которые  я смог представить )

(0 , 110 ) В 110 найдите ошибку, лучше найдите сами и это не потому что не хочу сказать,
а потому что пока свои шишки не набъешь не поймешь.
Подсказка: ошибка не с точки зрения правильности выполнения запроса, а сточки зрения производительности.

+ 372  в 128 ссылка дана на 372

(274)  >>> У нас есть как раз такой собственный некластерный индекс в таблице _1sjourn. Может в этом проблема?
Если дополнительный индекс уникальный то скорее всего в нем проблема, уникальность не выполнима вот и получаешь ошибку обновления,
если индекс неуникальный то он никак не может влиять на ситуацию.

(297) назвать индекс IDDIC в таблице где и поля такие есть - это сильно.
Лучеше переименуйте как нибудь по другому.

+ 375 так это его так 1с назвала. Вот уж не разу на это пристально не смотрел.

(330) да не трогай бы бы учет : там есть еще счета и оборотка по счетам.
Если к ним не обращаешься лишние таблицы не мешают а при удалении еще что нибудь поломаешь.

(375) вроде разобрались: переставление строки индекса в файле dds решило проблему

(364) обработка из 128 только ищет ошибки и не исправояет. Я ее запускал. Мне не нужно устранять все ошибки , а решить конкретную проблему.

(376) индекс не называется iddic

(376) индекс K_IX1

(380) Ну это Ваша база, Ваша ответственность, Вам решать что нужно а что нет

(382)
индекс
I=K_IX1                    |              |0     |IDDOC,DATE_TIME_IDDOC,SP652                                |0  

если это индекс на таблицу _1sjourn и описание индекса совпадает с тем что прописано в ms sql
то этот индекс бесполезный - он только замедляет работу сервера ms sql

(384) Почему он замедляет работу сервера, он делался для какого-то отчета для выполнения прямого запроса. Состав индекса не обсуждается.

(385) Отчёт у тебя выполняется раз в неделю, а индекс обновляется на каждую запись документа... Любого...

(386) я ХЗ, индекс не мой, я его не могу просто так удалить. Какие конкретно претензии к данному индексу?

Так можно про любой индекс сказать, что избыточные индексы замедляют проведение.

(385) "Состав индекса не обсуждается."
А почему бы и нет?
Вот я вижу наличие этих полей в порядке индекса (IDDOC,DATE_TIME_IDDOC), и в таком порядке совершенно бессмысленным.

Значение IDDOC однозначно определяет значение DATE_TIME_IDDOC.
Если в условии запроса не указываем IDDOC, то индекс не работает
Если в условии запроса указываем IDDOC, то ему будет соответствовать одно и только одно DATE_TIME_IDDOC, при этом DATE_TIME_IDDOC нужно будет указывать обязательно, когда хотим чтобы и SP652 работало.

(389) как  понимаю Индексы работают если такой же состав полей указан в условии связи с другими таблицыми или секции where. Этот индекс был создан человеком, на основании анализа планов запроса.

Абсолютно пофиг что "Значение IDDOC однозначно определяет значение DATE_TIME_IDDOC".
Даже у 1С есть индексы которые включают IDDOC и DATE_TIME_IDDOC

(391) А кто тебе сказал такую чушь, что у 1с нормальные индексы?

Отсюда рассмотрим два варианта:
1. (IDDOC, SP652)
При указании в запроса IDDOC = А и SP652 = В - индекс будет работать.
2. (DATE_TIME_IDDOC, SP652)
При указании в запроса DATE_TIME_IDDOC = А и SP652 = В - индекс будет работать, но для этого достаточно п.1
Если рассматривать запрос на интервал DATE_TIME_IDDOC между А и Б, то в ключе SP652 - работать все равно не будет, а для интервала уже есть штатный индекс.

Отсюда вывод. Имеет смысл только (IDDOC, SP652)

(390) Знаешь, почему-то мне кажется, что trad разбирается в индексах на порядок лучше как тебя, так и того человека...

Если есть Join по IDDOC,DATE_TIME_IDDOC,SP652 то этот индекс будет использоваться

(394) Еще раз, я не могу удалить индекс, т.к. он был создан не мной. Это требует согласования и обоснования.

(390) "Этот индекс был создан человеком, на основании анализа планов запроса."
Значит анализ был так себе.
См. (393) - почему этот индекс не имеет смысла

(396) Индекс можешь и не удалять, но понять не помешает, что бы потом самому делать правильно

(393) Почему индекс будет работать "При указании в запроса DATE_TIME_IDDOC = А и SP652 = В" ?

(395) правильно, будет.
Но он также отлично будет работать если будет таким (IDDOC,SP652)

(399) в предложенном, гипотетическом варианте (DATE_TIME_IDDOC, SP652) - будет

(401) но ты же предлагаешь индекс IDDOC, SP652. Он не будет использоваться если нет фильтра на IDDOC

(391) "Даже у 1С есть индексы которые включают IDDOC и DATE_TIME_IDDOC"
Приведи пример.
На _1sjourn нет таких индексов. Все штатные индексы на этой таблице нормальные и не лишены смыла

(402) при индексе  (IDDOC, SP652) я не предлагаю писать условие DATE_TIME_IDDOC = А и SP652 = В

(403) ладно, в _1sJourn нет ни одного индекса на IDDOC

(405) а где есть?

Плюсом ко всему добавлю, что для отбора SP652 на интервале не лишен смысла индекс (SP652, DATE_TIME_IDDOC)
И для этого существует штатный индекс.

IDDOC есть в таблицах документов

Вообщем индекс создавался для ускорения каких-то отчетов в базе 7.7, каких уже никто не помнит, и лучше этот индекс не трогать

(408) индекс на IDDOC конечно есть. Есть он в 1sjourn.
Речь идет про совместное использование IDDOC,DATE_TIME_IDDOC в одном индексе, что лишено смысла

(0, 409)  Порядок полей в составном индексе имеет огромное значение.здесь не применимо  от перемены мест слагаемых ...
Для понимания работы индексов решите самостоятельно (373)

(411) эта дурь в (110), на которую ты сделал замечание, кмк, из какого-то букваря распространяется

не знаю что там за ошибка в (110), я этот запрос н запускал

(413) там скан всей таблицы журнала, т.к. через такое индексы не работают
Cast(Left(Жур.DATE_TIME_IDDOC, 8) AS datetime) >= :Дата1

(414) какая разница, если это разовый запрос. Понятно что конструкцию IN не желательно использовать.

(414) тогда уж и Left() не желательно использовать

(415) "какая разница," да не вопрос

ps
к IN вопросов нет

(416) ты не понял.
Проблема в применении условия не к X, а к f(X)