Галактика в вопросах и ответах

Нужно к накладной на отпуск добавить 5 дополнительных параметров, так чтобы их было легко заполнять. Что лучше использовать внешние аттрибуты, создать дополнительные поля в таблице katsopr или создать свою таблицу с привязкой к katsopr. Чисто практически, что удобней, быстрей и надежней с точки зрения администрирования и поддержки?

Своя таблица с привязкой к KatSopr, однозначно ...
Внешние аттрибуты - долго по ним шариться ..
Докомпиляция словаря с измением Katsopr- не особо хорошо, в случае перехода на другую версию могут быть глюки, ежели в новой версии в Katsopr сами разработчики добавят что-то(придется выгружать в DBF, убирать свои поля,переходить на новую, докомпилять и загружать - в общем геморрой)

>Своя таблица с привязкой к KatSopr, однозначно ...
Я тоже сначала склонялся к такому варианту, но если использовать свою таблицу, то нужно будет переписывать стандарный интерфейс Накладная на отпуск. Тоже геморой не малый, к тому же надо где-то нарыть его исходники.

Если не боишься последующей работы, которой описал выше Туманов О.В., то спокойно изменяй катсопр и все. Почему? Все просто: если докомпилишь новую таблу в словарь у тебя встанет проблемма с выносом полей в фейс для заполнения. Допустим ты нарыл исходники, подправил их и скомпил, вышел патч с исправлениями в этом же фейсе и перекрыл твой, поэтому тебе прийдется искать новые исходники или не использовать фейс из патча и смириться с ошибками. Но если просто добавил поля в таблицу, то мпокойно конфигуратором их в фейсе вынес и делов то. Только поля называй так, как никогда не пришло бы в голову разработчиком их назвать

2 Vitas
Вот тут немножко неправда - конфигуратор видит только те таблицы, которые объявлены в исходнике того интерфейса из которого вызван был конфигуратор - т.е. чтоб эти таблы в конфигураторе были видны из накладных, нужно опять же ковырять исходники - добавлять в описание Create View свои таблички.
Я, например бы, переписал интерфейс без добавления табличек - заюзав для этой вещи стандартные дополнительные таблицы, используемые в модуле кадры - единственное что нужно - это внести свой тип модуля )))
поля генерятся автоматом.
Кто не понял о чем говорю - зайдите в УП и гляньте в карточке сотрудника что вызывается по ALT+I - туда по идее любые данные пихать можно - по 5 полей всех типов кроме мемо есть!

Ой не внимательны вы господин:)
Я как раз и написал, что конфигуратором можно, если подправил табличку, т.е. добавил поля, если же создал новую тоблицу, то треба переделка фейса )

Кста, например, на сколько дольше переписать фейс или конфигом подправить после того, как добавил поля в КатСопр?

Использовать внешние атрибуты или внешние классификаторы все же удобнее
Их легко конфигом вытащить в стандартный интерфейс накладной Они доступны для обработки в настройках ТХО и ТФО И несложно нарисовать их в печатные формы документа
И при переходах в новую версию нужно будет только перекомпилировать печатные формы и перенастроить конфиг

Гульзина, а потом копаться Exclassname,Exclassseg и Exclassval для построения собственных отчетов пробовали ?
Особливо если иерархические внешние классификаторы и их несколько видов на одну таблицу ...

)
Все на любителя )))
Я все-таки делал бы используя стандартный функционал галки.
а насчет копаться в Exclassname,Exclassseg и Exclassval - достаточно 1 раз сесть, разобраться и написать. а потом инклюдом цеплять в нужном месте )))

Мы поначалу тоже попробовали использовать аттрибуты, то когда конфигуратором подправили интерфейс, то тормоз стал такой, что пришлось пользователей перекинуть в терминальный режим и это помогло лишь отчасти. Так что может быть использовать 1 аттрибут это не заметно, а пять - полный тормоз ( к тому же кроме аттрибутов есть еще 6 других дополнительно вставленных поля с сылками на basedoc и dogovor). Мы даже уже отчеты все написали с использованием аттрибутов, но .... быстродействие при работе с интерфейсом - УЖАС! Я тут попробовал, добавить поля и их вынести конфигуратором ... быстродействие увеличилось в разы. Вот и задумался, что лучше оставить так как есть и слушать смешки пользовтелей по поводу быстродействия или добавить себе гемороя с конвертацией и т.п., но прослыть героем ...

Да особого гемора с конвертацией не будет, просто подправь конвертор. При чем, гемор с конвертацией максимум 2-3 раза в год, гемор с тормозами каждый день

>гемор с конвертацией максимум 2-3 раза в год, гемор с тормозами каждый день

Тут я с тобой полностью согласен.

Я уже склонялся к созданию своих полей в katsopr-е, но хотелось узнать мнение бывалых (до этого случая не приходилось менять структуру базы).
Всем большое спасибо за советы.

Ну тогда учитывай следующие вещи
1. Сначала экспортни данные из катсопра (например в дбф)
2. добавь поля в исходник таблы
3. сгенери новую таблицу
4. залей данные обратно в катсопр
если п.1 не выполнишь - данные из катсопра просто пойдут "по бороде"

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

так это.....можно же использовать
alter table
как это делается в докомпиляторе (alter.lot)

тогда можно обойтись без экспорта/импорта
но надо конечно сначала все на тесте откатать..

Vitas, не соглашусь насчет отсутсвия геморроя при смене релизов при докомпиляции самого Katsopr...
Во время конвертации глюков не будет в случае добавления каких-то полей конвертатором , но :
1) Добавленные поля по смещению будут стоять за твоими в записи
2) В ресурсах поля идентифицируются по смещению и длине
3) Ресурсы нового релиза скомпилены на стандартной базе, где нет твоих полей и смещения другие ...
4) Результат - сам знаешь ;D