еще раз про lookup

[mick_777]

есть две таблицы:
в одной есть два поля: внутр. вид и представление
в другой хранится ссылка по внутр. полю из табл. 1
а на экране хочу чтобы в таблице 2 отображались данные по представлению из табл. 1

сделал edit процедуру, она нормально работает на табл. 2, (работает когда ввожу значение ручками)

lookup переопределил

PHP код:

this.performTypeLookup(typeid(mk1cTableName)); 


окошко с выбором появляется, но когда выбор делаю
то в таблицу ничего не попадает т.к. mk1cTableName это внутренний вид поля из таблицы 1, а на экране совсем другой тип
вот если бы performTypeLookup возвращал значение - тогда было бы что-то типа

PHP код:

table2.mk1cTableName = this.performTypeLookup(typeid(mk1cTableName)); 


вот тут я и застрял - как с минимальной кровью решить эту проблему?

[mazzy]

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

Могу дать только один совет - переходи с искусственных ключей на естественные.
Вся Аксапта построена на том, что поле код является основным рабочим инструментом. Код должен быть виден всегда. Работа ведется через код. Фильтры настраиваются через код. Если хорошо подумать, то выяснится, что код нельзя прятатьт от пользователя ни в коем случае. Иначе все переписывать придется.

Слишком тяжело переделывать этот подход на 1Совский.
Я писал по этому поводу http://www.mazzy.ru/axapta/hints/autonumber/

[mick_777]

в моем случае это не подходит
поле sp107 никак у меня не ассоциируется с адресом банка
или еще SP148 - коэффициент

[mazzy]

да. с 1Сом.
По-моему тебе надо задачу переформулировать.
Иначе придется переписывать механизм lookup'ов.
Т.е. малой кровью никак.

Если уж очень хочется, то открой просмотршиком axsys.aod
и поищи строку "void performTypeLookup("
Посмотри что там написано.

И все же. Постарайся чуть отойти от стандартов 1С.
С задачей lookup'ов встречаются все, кто пишет базы данных, системы автоматизации и т.п. на нормальных движках. То, что сделали в 1Се конечно же очень удобно пользователю. Но офигительно нагружает СУБД. Постарайся понять также, что остальные решают эту проблему. Вовсе не так как в 1С.

[mick_777]

по другому опишу задачу:
взял себе в учебных целях написать импорт данных из 1С
при этом хочу
чтобы выбиралась таблица из Ахапты, напротив нее таблица из 1С
а потом сопоставить поля
но дело в том что в 1С именя полей и таблиц в базе имеют внутренние номера, а не их смысловое значение
напр.
таблица "единицы" в 1С имеет имя SC153
как ни крути, а чтобы сопоставить две таблицы мне эти коды никак не помогут
вот я и хотел чтобы на экране у меня были русские названия полей из 1С
а в табличке хранились внутренние названия полей и таблиц как есть физически

[olesh]

Ну если очень хочется сделать именно такое поведение lookup'а, то обратите внимание на форму Закупки или Заказы, поле Контактное лицо. Вроде бы оно ведет себя именно так, как Вы хотите.

[mazzy]

2 mick_777:
вот я и говорю, переформулировать.

Идентификация в 1С на логическом уровне выглядит так:
= внутренний код (невидим для пользователя)
= код
= наименование

Ты пытаешься повторить эту функциональность.
А ты используй код в качестве акспатовского кода, наименование в качестве наименования, а внутренний код как реквизит.

В даном случае будет так:
= идентификатор 1С -> код Аксапты
= комментарий в 1С -> наименование в Аксапте
= внутренний код в 1С -> реквизит

Здесь надо сказать следующее:
Ты скорее всего предполагаешь, что внутренний код не изменяется. Это не так. Никто этого никогда не гарантировал. Говорилось следующим образом: пользователь может менять код, а 1С гарантирует, что объект останется неизменным для системы. Заметь, что про внутренний идентификатор нигде не говорилось! Да, сейчас реализвация такова, что внутренний идентификатор практически никогда не меняется. Но это особенность реализации, а не инвариант. В данных идентификаторы пока нигде не меняются, а в конфигурации могут изменяться при объединении конфигураций.

Теперь рассмотрим код. Код (идентификатор для метаданных) может меняться пользователем. И никогда не меняется самой системой. Пока пропустим данные. Сосредоточимся на метаданных. Что значит изменился идентификатор? Это значит, что во всей конфигурации надо выполнить синтаксическое переименование. Вспомним, что это не Аксапта и синтаксическое переименование в 1С надо делать ручками. Вероятность изменения кода-идентификатора в конфигурации ничтожна. А уж если изменили, то: 1) явно по указанию пользователя, 2) происходит что-то из ряда вон выходящее.

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

Таким образом:
малой кровью можно обойтись, если идентификатор объекта использовать в Аксапте как код, комментарий объекта использовать как наименование, а внутренний идентификатор затолкать в реквизит. Дополнительно в группу AutoLookup можно затолкать все три поля, тогда их всех будет видно. В этом случае ничего в Аксапте переделывать не надо.

Если волнуют случаи, когда идентификаторы в 1С могут измениться, то можно сделать дополнительные проверки на соотвтетствие идентификатора и внутреннего идентификатора.

Кстати, похоже, что ты пользуешься только данными из SQL-я. ЛУчше подключись к 1С через OLE и получи нужные тебе данные о конфигурации с помощью объекта Метаданные.

2 olesh:
я все еще считаю, что не надо программировать низкоуровненвые вещи. Нужно по возможности использовать стандартные решения, а пргограммировать только там, где без этого действительно не обойтись.

Кстати, по этму лукапу больше всего дурацких вопросов - пользователи не понимают как он работает.

[mazzy]

В твоем случае можно хранить в Аксапте следующим образом
Код = Единицы
Наименование = Единици измерения
Внутр.ид = SC153

[mick_777]

а по поводу неизменности внутреннего кода -
вряд-ли кто-то будет это переделывать - открой МД - и ты увидишь что там все насквозь пропитано этим (все ссылки по внутр. коду)
а что выйдет в 8-м релизе 1С там уж посмотрим

[mazzy]

Еще немного ОФФа, и не буду больше.

В общем случае идентификация объектов в 1С на логическом уровне выглядит слудующим образом:
1. Внутренний идентификатор (невидим для пользователя - искуственный ключ)
2. Полный код (может совпадать с кодом, а может и не совпадать)
3. Код (естественный ключ)
4. Наименование

1С никогда не показывает внутренний идентификатор
1С никогда не гарантировала неизменность внутреннего идентификатора
1С гарантирует, что при изменении кода, объект в системе остается неизменным. Т.е. везде, где объект используется он останется именно этим объектом.
1С не гарантирует, что код будет уникальным в пределах типа.
1С гарантирует, что полный код будет уникальным в пределах типа.

При организации связи с 1С, как правило, возникают три проблемы:
= использование 1Совский перечислений
= работа с полным кодом в общем случае
= уникальность внутренних идентификаторов

Я считаю, что такая функциональность, обеспечивающая возможность изменения кода, избыточна.
Я считаю, что искуственные ключи излишне напрягают СУБД.
Я считаю, что изменение естественного кода можно реализовать с помощью каскадных обновлений.
Я считаю, что нужно хорошее обоснование, чтобы повторять данную 1Совскую функциональность.

[mazzy]

Цитата:

Изначально опубликовано mick_777
а по поводу неизменности внутреннего кода -
вряд-ли кто-то будет это переделывать

1. могут. Например для объединения конфигураций они стали изменять идентификаторы в md. А в данных... вот доделают лечение - может будут и в данных идентификаторы менять
2. вот я и говорю - особенность реализации. Некоторые используют данную особенность. Например, МОД. Но от этого данная особенность не становится гарантированной. Некоторые использовали особенность, что поток Task в md хранится незашифрованным. И что из этого стало?
3. А тебе то это зачем? Переверни задачу и решаей ее на Аксапте малой кровью. В такой постановке она неудобна для Аксапты. Что значит неудобно - это значит что слишком много низкоуровненго программирования. Тебе оно надо?

[mick_777]

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