При работе с документами в 1С очень часто возникает необходимость просматривать их движения по регистрам. И при работе с обычными формами в режиме толстого клиента никаких проблем не возникало. Кнопка Перейти и далее можно выбрать по какому регистру будем смотреть движения или сформировать отчет о движениях документа по всем регистрам.

Но когда в первый раз сталкиваешься с такой необходимостью в управляемом приложении, то оказывается, что не все так просто. И на первый взгляд кажется, что это вообще невозможно, т.к. в меню никаких подходящих команд обнаружить не удается. Конечно же сразу приходит в голову вариант воспользоваться консолью запросов. И этот вариант вполне рабочий. Правда постоянно писать запросы для выборки движений по каждому конкретному документу не очень удобно.
И тем не менее с помощью определенных настроек мы можем добиться нашей цели и переходить к движениям регистров непосредственно из документа. Рассмотрим это на примере демо версии конфигурации ЗУП 3.1.

Итак, откроем любой документ Начисление зарплаты и взносов. В Шапке документа нет кнопки ПЕРЕЙТИ и нет ссылок на регистры движений, добавим их: выберем пункт меню Вид – Настройка панели навигации формы

В открывшемся окне выберем регистры, движения которых нам надо видеть и перенесем их в правую панель

В результате этих манипуляций шапка документа будет отображать названия регистров движений документа

И теперь, щелкнув по этим ссылкам, можно просматривать движения документа.

Однажды вылетело: "Ошибка СУБД. Превышен максимально допустимый размер внутреннего файла .../1CV8.CD"

И Все! Данных больше ввести никаких нельзя. Размер Файла 1Cv8.1CD 4,5 ГБ.

Ответ: Про ограничения в файловой версии можно прочитать на последнем ИТС. Действительно - 4 Гб.

Решение: Переходить на MS SQL. В серверном варианте размер базы ограничен возможностями MS SQL сервера.

Дополнение от Andy1981:

Столкнулся с проблемой только сейчас. До этого постоянно работал на серваках, даже тестовая база была развернута на собственном скуле, который крутился у меня локально :-)

В общем-то, решение тривиально, переход на клиент-серверный вариант, и всех делов. Но! Меня задело за живое. Даже если решение очевидно, нужно сначала обосновать его, а не слепо следовать предложенному варианту. Прежде чем выносить вердикт, относительно того, как нужно поступить, исполнил элементарный скрипт на SQL, получил табличку в виде ИмяТаблицыБД|РазмерТаблицы. Прекрасно, но это позволит лишь определить, в каком классе объектов метаданных проблема. Далее, используя Enterprise Integrator получил имя справочника (в моем случае), имеющего проблемный размер. Далее дело за малым - всего-то и делов - определиться, каким образом можно оптимизировать хранение данных? В моем случае ответ оказался практически очевиден. Оптимизировать можно и нужно, и использование сервера БД нецелесообразно. Вполне возможно, что таблица распухает вполне обоснованно, тогда переход на SQL (например), является неизбежным.

Скрипт для вычисления объемов таблиц БД:

 USE MyInfoBase --Имя БД





DECLARE @tbl TABLE (

name nvarchar(128),

[rows] char(11),

reserved varchar(18),

data varchar(18),

index_size varchar(18),

unused varchar(18)

)





DECLARE @name sysname





DECLARE CUR CURSOR FOR SELECT name FROM sys.tables

OPEN CUR

FETCH NEXT FROM CUR INTO @name

WHILE @@FETCH_STATUS = 0 BEGIN

INSERT @tbl EXEC sp_spaceused @name

FETCH NEXT FROM CUR INTO @name

END

CLOSE CUR 

DEALLOCATE CUR





SELECT

name,

[rows],

reserved,

data,

index_size,

unused,

reserved_kb

FROM

(SELECT  

name,

[rows],

reserved,

data,

index_size,

unused,

CONVERT(bigint, REPLACE(reserved, ' KB', '')) AS reserved_kb

FROM @tbl

) Q

ORDER BY

reserved_kb DESC

COMPUTE SUM(reserved_kb)