Меню

1sjourn что за таблица



Состав информационной базы 1С:Предприятие 7.7

Состав информационной базы В данном разделе приводится перечень и описание наиболее важных для системы 1С:Предприятие файлов, размещаемых в каталоге информационной базы. Указанная информация приводится для того, чтобы дать специалистам осуществляющим конфигурирование и администрирование 1С:Предприятия лучшее представление о внутренней организации информационных массивов. Например, она может быть использована для оценки использования ресурсов теми или иными объектами информационной базы или механизмами системы.
Создавать решения построенные на манипулирование данными, хранящимися в файлах информационной базы системы 1С:Предприятия средствами не штатными для 1С:Предприятия категорически не рекомендуется . Это объясняется сложностью поддержания логической целостности объектов информационной базы и возможностью изменения структур данных в последующих версиях. А также особенностями организации таких механизмов 1С:Предприятия, как «Управление распределенными информационными базами», возможностью хранения таблиц базы данных как в файлах DBF/CDX так и в среде сервера баз данных MS SQL Server и другими подобными причинами.

Итак в каталоге информационной базы размещаются:
Файл конфигурации (1 CV7.MD) Файл словаря данных (1С V7.DD или 1 CV7.DDS в зависимости от формата хранения таблиц базы данных)
Файл списка пользователей ( USRDEF\USERS.USR)
Файлы таблиц и индексов базы данных
В файле конфигурации (1 CV7.MD ) находится конфигурация системы: метаданные, интерфейсы и права.
Имя файла словаря данных зависит от формата хранения таблиц базы данных. В случае, если для хранения таблиц базы данных используются файлы DBF/CDX , словарем данных является файл 1 CV7.DD . Если же таблицы базы данных размещаются в среде MS SQL Server , то имя файла словаря данных — 1 CV7.DDS . Словарь данных содержит описание структуры таблиц и индексов базы данных системы 1С:Предприятие. Для MS SQL Server словарь данных содержит также описание хранимых процедур.
Файл списка пользователей — USERS.USR размещается в подкаталоге USRDEF каталога информационной базы. Данный файл содержит список пользователей с указанием для каждого пользователя набора прав, интерфейса и другой информации, связанной с пользователем. В случае, если для хранения таблиц и индексов базы данных используются файлы DBF/CDX , то указанные файлы также размещаются в каталоге информационной базы. Каждой из таблиц соответствует файл . DBF . Если у таблицы имеются индексы, то к ней также относится соответствующий файл CDX . Файлы . DBF и . CDX , относящиеся к одной таблице имеют одинаковые имена. Например, таблице 1 SJOURN соответствуют файлы 1 SJOURN.DBF и 1 SJOURN.CDX.

Ниже приведен перечень таблиц, которые могут входить в базу данных системы 1С:Предприятие(Файлы Назначение):
1SUSERS Системная таблица: отслеживание числа соединений с базой данных, счетчик изменений данных пользователями.
1SSYSTEM Системная таблица: содержит общие параметры информационной базы (точку актуальности, рассчитанный период бухгалтерских итогов, периодичность оперативных итогов и т. п.).
1SCONST Содержит значения констант, периодических реквизитов справочников и бухгалтерских счетов.
1SJOURN Содержит заголовки всех документов (внутренний идентификатор, номер, дату, время, общие реквизиты, по которым установлен отбор)
1SCRDOC Содержит вхождения документов в графы отбора, списки подчиненных документов, вхождения документов в общие журналы, для которых определен состав документов.
1SDNLOCK Содержит временный список номеров документов, которые в данный момент вводятся, для автоматической нумерации документов с учетом вводимых.
1SUIDCTL Используется для дополнительного контроля уникальности внутренней идентификации объектов (документов, справочников, бухгалтерских счетов).
1SBLOB Содержит значения реквизитов справочников, документов, счетов имеющих тип «Строка неограниченной длины». Также содержит описания шаблонов типовых операций.
SC* Содержит данные справочника конкретного вида. Каждый справочник хранится в отдельном файле.
DH* Содержит данные реквизитов шапки и общих реквизитов без признака «Отбор» документа конкретного вида. Создается при наличии у документа соответствующих реквизитов.
DT* Содержит данные реквизитов табличной части документа конкретного вида. Создается при наличии у документа соответствующих реквизитов.
1SACCS Содержит список бухгалтерских счетов всех планов счетов .
1SOPER Содержит данные бухгалтерских операций (сумму, содержание, дополнительные реквизиты). Содержит одну строку на документ, по которому создана операция.
1SENTRY Содержит бухгалтерские проводки.
1SBKTTLC Содержит рассчитанные бухгалтерские итоги оборотов между синтетическими счетами.
1SBKTTL Содержит рассчитанные бухгалтерские итоги остатков и оборотов по синтетическим счетам и объектам аналитики.
1SCORENT Содержит список корректных проводок.
1SACCSEL Содержит вхождения проводок в отборы по бухгалтерским счетам.
1SSBSEL Содержит список вхождений проводок в отборы по субконто.
1STOPER Содержит список типовых операций.
RA* Содержит движения регистра конкретного вида.
RG* Содержит итоги регистра конкретного вида (остатки для регистров остатков, обороты для оборотных регистров).
CJ* Содержит данные журнала расчетов конкретного вида.
CJPROP Содержит свойства журналов расчетов (расчетный период, глубина просмотра и т.п.)
CL Содержит данные календарей всех видов.
1SUPDTS Системная таблица компоненты «Управление распределенными ИБ». Содержит таблицу регистрации изменений. Создается только для распределенных ИБ.
1SDWNLDS Системная таблица компоненты «Управление распределенными ИБ». Содержит таблицу регистрации произведенных выгрузок изменений. Создается только для распределенных ИБ.
1SDBSET Системная таблица компоненты «Управление распределенными ИБ». Содержит список информационных баз, входящих в распределенную ИБ. Создается только для распределенных ИБ.

Читайте также:  Система конституционного права таблиц

В случае, если таблицы базы данных системы 1С:Предприятие размещаются в среде MS SQL Server , то в каталоге информационной базы появляется файл 1 CV7.DBA , содержащий ссылку на соответствующую базу данных, находящуюся на сервере баз данных. Состав таблиц, хранимых в среде сервера баз данных практически идентичен приведенному выше составу файлов в формате DBF/CDX . Исключение составляет хранение строк неограниченной длины, которое в формате MS SQL Server не выделяется в отдельную таблицу.

Источник

ТиС 9.2. 1SJOURN

ПРи тестировании базы выдается ошибка

Таблица — 1SJOURN. Не сходится количество полей

Проверка физической целостности таблиц ИБ. Неисправимая ошибка.

При этом вроде бы работает все нормально. Чтобы это могло быть?

1. Возможно правили файл 1Cv7.DD (и изменили в нем описание этого файла)

2. Может быть открывали 1SJOURN из какой-то другой программы и изменили его структуру.

3. Физическая ошибка в файле.

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

ничего точно не правилось.Выгрузка и загрузка не помогла.Может есть еще какие-то предположения?

Ну.у.у тут может быть помогут «танцы с бубном» (естественно сначала сделав копию, что-б не потерять ничего).

Например попробовать восстановить структуру этого файла.

1. Загрузить в чистую папку мд-шник твоей базы (в конфигураторе). Получится чистая база, в которой этот файл 1SJOURN.DBF будет иметь «правильную» структуру.

2. Залить в этот файл данные из «неправильного» файла.

3. Положить полученный файл на место «неправильного». И попробовать протестировать.

(при этом файл 1SJOURN.CDX после этих манипуляций убить, чтобы 1С заново его создала)

По поводу п.2, залить можно например через FoxPro.

Могу даже привести пример команд, например «битый» файл лежит в папке C:\DB а чистая копия в C:\tmp

use C:\tmp\1SJOURN тут Foxpro может спросить про кодовую страницу,

выберем 1251 Russian Windows, попутно Foxpro

может сообщить что удалена ссылка

delete all Удалим все записи в «хорошем» файле

pack упаковали «хороший» файл

append from C:\db\1SJOURN добавили записи из «плохого» файла

quit вышли из foxpro

Потом копируем файл 1SJOURN из папки C:\tmp в папку C:\db

в папке C:\db удаляем файл 1SJOURN.CDX

Заходим монопольно в 1С и смотрим, или сразу в конфигураторе тестируем.

Источник

Изменение принадлежности документа к последовательности при загрузке данных (1С-SQL)

Довольно часто при загрузке данных в непустую базу данных возникает следующая проблема — в таблице журналов документов изменяется поле принадлежности документа к последовательности. Вот краткий комментарий изменений.

Как известно, признак принадлежности определенного документа к определенной последовательности хранится в таблице «Журналов документов» « _1sjourn ». Для каждой последовательности в данной таблице существует поле с типом « tinyint » и названием DS , где — это идентификатор последовательности из таблицы « _1sstream ». В том случае, если документ принадлежит последовательности, то в этом поле ставится « 1 », иначе « 0 ».

Во время загрузки данных в конфигураторе в непустую базу данных возникает следующая ситуация: в тех строках таблицы, где в поле последовательности должна стоять цифра « 1 », стоит « 2 ».

Теперь о том, как это выглядит у пользователей. При попытке восстановления последовательности встроенными средствами 1С в монопольном режиме, 1С быстро пересчитывает итоги и передвигает ТА , причем очевидно, что документы не проводятся (для контроля можно выставить пометку для выдачи сообщений о проведенных документах).

Читайте также:  Вес мет труб таблица

Как определить наличие ошибки. Открыть MS SQL Query Analizer ( QA ), выбрать свою базу данных и выполнить следующий запрос:

Вместо соответственно нужно подставить реальное название колонки. Если в результате запроса у вас вышло « 0 », что значит, что нет ни одного документа по данной последовательности, или « 1 », что значит что документы есть, то это нормально. Если же вышло максимальное значение « 2 », то значит описываемая ошибка присутствует.

Ее можно быстро исправить, выполнив следующий скрипт:

Теперь о том, в каких случаях данная ошибка возникает. После проведения ряда проверок было выяснено, что ошибка возникает в случае загрузки данных в базу данных, которая инициализирована для УРБД , независимо от наличия в конфигурации распределенных баз. Короче говоря – достаточно того, чтобы база была помечена в качестве « Центральной ». Ошибка возникает как на 21 , так и на 23 релизе. На других я не проверял в связи с отсутствием необходимости.

Источник

v7: Нарушена структура таблицы 1SJOURN

Проделай плиз на копии, а?

На каком релизе работаете и на каком была сохранена конфига? Не 27 ли случайно с 25-м?

Вот специально для тебя (давно это было, кое как вспоминаю. ) :

1. Создал пустую SQL базу
2. В конфигураторе создал нового пользователя, сохранил
П.С.
Данные не проверял, делай на копии.

ВСЕМ ОГРОМНОЕ СПАСИБОЧКИ.
ВСЕ ОТКРЫЛОСЬ, ВСЕ СРАБОТАЛО, БУДУ ПРОВЕРЯТЬ ДАЛЬШЕ.

АНТ-1970 — делай копию каталога базы, остановку SQL сервера и копию 2х файлов (SQL базы и SQL лога). Выполни эту инструкцию БУКВАЛЬНО, без всяких бекапов.

потом по этим данным может можно будет все вернуть назад!

зы
если все порушишь, пиши, почта в личке

(52) *.mdf и *.ldf — это два файла твоей базы на SQL сервере (вместо * название твое базы)
и весь каталог где ты находил DDS.

п.с.
Таки копию не сделал, дятел.

(64) сделай как я сказал, иначе потеряешь лог файл, а по нему почти все можно откатить назад.

а уж после копирования делай бекапы как хочешь

(66) при удалении юзердеф инфа о коннекте к SQL базы не удаляется, просто 1с говорит — «типа был взлом» и я не буду работать.

а вот если попробовать сохранить список пользователей в конфигураторе, то кирдык.

кстати из DBA все параметры подключения достаються элементарно и по этому все можно востановить пока не произвели перезапись

(80) как я понял, автор вообще не 1с-ник, спеца который все настраивал турнули в кризис и как я понял он ушел не сам и не хорошо.

по этому мне пользовательей не жалко ни грамма!

на 99% счас будут пытатся поднять вчерашний бекап и вчерашний день колотить вручную!

Автору посоветую при любой просьбе начальников что-то сделать в 1с слать их в эротическое путешествие

(92) это «мягкий» вывод из почтовой переписки. Мое ихмо — контора сама виновата в этой ситуации, так сказать «период полураспада баз 1с без программиста = 1 год»

зы
надеюсь ничего секретного я не выбалтал

Всем приает!Возвращаюсь к вопросу. Вчера и сёдня юзы работали в файловом режиме на восстановленой из бекапа. Один день работы до сих пор практически отсутствует.
По совету vde69 скопированы БД целиком, LDF и MDF файлы из SQL базы.

О предыстории: 1с-ника поерли года два, как. Поперли «нехорошо». С тех пор с базой ничего не делали, только работали юзали. Теперь приспичило внести некоторые обновления и попросили меня заняться.
Теперь так, я устал пока знакомился с базой, все время дергать юзера набрать пароль, а что база SQL не предположил (вот тут я полностью виноват), и поступил, как всегда с файловой (убрал юзердеф). Когда понял, что база SQL, было уже все сделано.
Все правильно подмечено было, что при входе без юздеф очистились настройки параметров подключения к SQL. Как было настроено, есессно, никто не знает. Сисадмин есть (приходящий), но 1с ваще не знает.
Вот такая в общих чертах картинка. И, кстати, все это пока что бесплатно, т.к. меня попросили только внести пока только «важные» изменения, а платить собирались раз в месяц (по результатам так сказать. )

Читайте также:  Ачивки викинги таблица белый волк

Так что можно сделать на данный момент?

Источник

1sjourn что за таблица

В предыдущей статье по «гибким» блокировкам я пожалуй не сделал акцент на то ,что блокировки в контексте 1С бываю двух видов. Первый вид это блокировки данных на уровне SQL servera. Второй вид это блокировки объектов 1С(клиентских форм). Хочу исправить свою ошибку и остановиться на описании второго вида блокировок подробнее.

Для чего вообще 1С реализовала внутренний механизм блокировок ? Ну во первых для того ,что бы не решать вопрос разрешения конфликтов отображения и записи данных из разных экранных форм одного и того же объекта. То есть предполагается, что если пользователь открыл расходную накладную №5 то никто другой не сможет открыть экранную форму этой накладной пока он ее не закроет. На попытку открыть документ выведется на экран сообщение «Запись заблокирована». Аналогичные по смыслу сообщения будут выводиться в обработках при попытках изменить объект данных который заблокирован.Это кстати многие не учитываю в своих обработках.

Давайте теперь попытаемся понять как устроен механизм «внутренней» блокировки 1С. Ну во первых при каждом открытии формы документа создается, если он еще не существует, временный файл 1sjourn.$lk. Размер этого файла всегда 0 и казалось бы в нем вряд ли может быть заложена информация по блокировкам. На самом деле это заблуждение. 1С используя функцию LockFile блокирует конкретный байт в фале указывая тем самым что тот или иной документ заблокирован. Номер байта соответствует Row-Id(первичный ключ) данного документа. Перед открытием формы или исполнением метода объекта 1С пытается заблокировать байт. Если попытка проходит то он остается заблокированным до завершения операции если же нет то выдается соответствующее сообщение. Вот простейший пример на Delphi отображения заблокированных объектов в 1С.

Для того чтобы понять какой у документа номер и вид для этого достаточно выполнить простейший select.

Где @i это номер байта полученный вышеописанной процедурой.

Для справочников это будет файл не 1sjourn.$lk а scXXX.$lk где ХХХ — внутренний идентификатор объекта метаданных.

Также нужно отметить что блокировку установить или снять в пределах своей сессии можно с помощью метода Блокировать(). Значение которое возвращает этот метод собственно и указывает на то заблокирован он или нет. Нужно отметить что пример приведенный на Delphi гораздо производительней т.к. в этом случае не нужно открывать выборку данных и проверять каждый элемент на блокировку а достаточно лишь взять заведомо заблокированные байты и сопоставить их объектам данных в 1С.

Возникает вопрос а можно ли снимать блокировки не из своей сессии и что произойдет например если мы попытаемся удалить файл 1sjourn? Сразу нужно отметить что просто так удалить нам его не удастся если он задействован хотя бы в одном сеансе 1С. Даже если мы возьмем и удалим все хэндлы на него и затем удалим его то и в этом случае нас постигнет неудача т.к. в этом случае при обращении ко всем документа будет появляться надпись «запись заблокирована». Косвенные причины этого понятны , неудача в LockFile(h,i,0,1,0) ,а в данном случае хэндл теряется , 1С интерпретируется как блокировка объекта. И даже если мы создадим заново этот файл то блокировок не будет только у тех клиентов которые загрузили 1С после создания файла. Скорее всего это происходит потому что 1С хранит в локальной переменной информацию об открытии файла. Если он уже открывался, то 1С не пытается за нового его открыть и получить новый хендл. Однако принципиальная возможность создания такого менеджера управления блокировками существует(возможно он уже и написан).

Источник

Adblock
detector