EDT как Array

[KingPeas]

Здравствуйте уважаемые.
Вопрос уже поднимался на форуме, но я не нашел ни одного понятного ответа, возможно плохо искал, возможно просто не допрыгиваю...
Сделал EDT как Array из 16 элементов. Хочу использовать его для настроек, то есть возможно будет использоваться в строке 4 элемента, а может 15. Когда добавляю на форму поле из таблицы на базе этого EDT то вижу только первый заполненный, как отобразить их все?
Как определить количество доступных для EDT элементов (попросту ArrayLength)?

[ice]

посмотрите как работают с типом Dimension и с полями на его основе

[KingPeas]

Цитата:

Сообщение от ice

посмотрите как работают с типом Dimension и с полями на его основе

Смотрел, вот только в основном там идет работа с уже подготовленным и введенным массивом. знаю что через dimof() могу получить размер массива. Это если уже есть массив значений, а массивом я как раз и не владею, есть только расширенный тип. И еще в книге нашел чтобы выводились все поля необходимо указать ArrayIndex = 0. Сменил 1 на 0 а результата нет. Может из за того что изначально поле было не array-типа

[Владимир Максимов]

Зря Вы это сделали... С полями типа Array проблем больше, чем достоинств.

Физически, каждый отдельный элемент типа Array - это отдельное поле. Значит, обращаться необходимо к каждому такому полю персонально. Посмотрите, например, форму заказов на закладке "Аналитика". Там идет обращение к каждому элементу по имени.

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

[KingPeas]

Цитата:

Сообщение от Владимир Максимов

Зря Вы это сделали... С полями типа Array проблем больше, чем достоинств.

Физически, каждый отдельный элемент типа Array - это отдельное поле. Значит, обращаться необходимо к каждому такому полю персонально. Посмотрите, например, форму заказов на закладке "Аналитика". Там идет обращение к каждому элементу по имени.

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

Да уж это точно. Была таблица с 16 однотипными полями, решил превратить их в одно... Все бы хорошо да поле типа строка размер Memo. На базе такого типа массив не формируется.Так что скорей всего придется переделывать назад. Всего то хотел чтобы таблица не разбухала при увеличении списка параметров.

[akvi]

Посмотрите, как хранится контейнер в шаблонах записей (табл. SysRecordTemplateTable).

[KingPeas]

Цитата:

Сообщение от akvi

Посмотрите, как хранится контейнер в шаблонах записей (табл. SysRecordTemplateTable).

Спасибо за идею, но к сожалению в этом случае она не подходит. Я использовал такой прием для хранения сложных настроек) вот только сейчас задача организовать настройки которые будут доступны вне аксапты по средствам обычного sql запроса к бд. Поэтому и избрал изначально хранение в полях таблицы или как сейчас реализовано в массиве на одном EDT. Заменил поле Memo на строку длиной 1000 символов, правда пришлось увеличить размер буфера для SQL. Но в итоге таки работает и именно так как и хотелось

[Владимир Максимов]

Цитата:

Сообщение от KingPeas

Всего то хотел чтобы таблица не разбухала при увеличении списка параметров.

Не понимаю, каким образом использование Array позволит решить эту задачу? Физически ведь это по прежнему будет несколько отдельных полей.

Использование определенных типов данных лишь косвенно влияет на размер таблицы. Да и то, в очень специфических ситуациях.

Как правило, таблица настроек, "по определению" содержит очень небольшое количество записей (обычно вообще одну). Поэтому количество добавляемых полей практически никак не влияет на ее размер.

[KingPeas]

Цитата:

Сообщение от Владимир Максимов

Как правило, таблица настроек, "по определению" содержит очень небольшое количество записей (обычно вообще одну). Поэтому количество добавляемых полей практически никак не влияет на ее размер.

Попытаюсь объяснить зачем все затевалось. Работаю с ReportingServices в аксапте. Представьте есть отчет содержащий 15 параметров. Каждый месяц формируется около 100 видов этого отчета с разными вариантами параметров. На стороне аксапты формирование отчета организовывалось на базе пакетной обработки. На RS скорость исполнения возросла на 20%, но запускать пакеты на формирование отчетов в RS из аксапты большого смысла нет.
У RS есть служба управляемых подписок - на основании запроса формировать отчеты. То что надо для таких случаев. Получается надо таблицу которая будет содержать нужные параметры и использоваться в запросе RS. Но согласитесь если для каждого отчета на RS делать свою таблицу это будет несколько расточительно. Поэтому сделал общую таблицу содержащую значения для формирования подписок.Состав полей очень простой: код класса формирующий подписку, путь к отчету, список параметров(Parameter1, Parameter2 и т.д.) и признак активности подписки чтобы ее можно было выключать временно. Сначало параметры забил отдельными полями, сейчас превратил их в массив так табличка симпотичнее выглядит). Вот собственно и все... Механизм отладил уже работает

[mazzy]

Цитата:

Сообщение от KingPeas

Но согласитесь если для каждого отчета на RS делать свою таблицу это будет несколько расточительно.

Категорически не соглашусь.

[KingPeas]

Цитата:

Сообщение от mazzy

Категорически не соглашусь.

Поясните пожалуйста свою позицию?В чем прелесть если аот вырастет на 100 новых таблиц?
Я исходил из того, что используя одну таблицу буду не только экономить узлы AOT, но и упрощу настройку подписок на RS. А каковы ваши мотивы для такого утверждения?

[mazzy]

Цитата:

Сообщение от KingPeas

Поясните пожалуйста свою позицию?В чем прелесть если аот вырастет на 100 новых таблиц?

Вопрос поставлен некорректно.
От простого добавления 100 таблиц ни холодно, ни жарко.

Прелесть состоит в том, что эти 100 таблиц будут иметь свои типизированные поля, свои валидейты, свои индексы, свои relation'ы, свои права. Каждую таблицу можно будет отнести к определенному проекту и функционалу.

В общем, вы получите проверку на уровне компилятора, а не во время runtime.

Цитата:

Сообщение от KingPeas

Я исходил из того, что используя одну таблицу буду не только экономить узлы AOT, но и упрощу настройку подписок на RS. А каковы ваши мотивы для такого утверждения?

А зачем "экономить узлы AOT"?
Но зато ваша экономия приведет к огромному динамическому программированию, к "универсальным" валидейтам, к неподъемному программированию прав
Подробнее см. Значение display метода по его названию

Насчет упрощения подписок - отчасти вы правы, но как вы права собираетесь раздавать? Или у вас все пользователи могут менять любые параметры?

[KingPeas]

Цитата:

Сообщение от mazzy

Прелесть состоит в том, что эти 100 таблиц будут иметь свои типизированные поля, свои валидейты, свои индексы, свои relation'ы, свои права. Каждую таблицу можно будет отнести к определенному проекту и функционалу.

В общем, вы получите проверку на уровне компилятора, а не во время runtime.

Это имело бы значения если бы эти таблицы использовались в DAX. Но их основное назначение хранить параметры для стороннего приложения и легкий доступ к ним в этом приложение. Типизированные поля это хорошо, но для исполнения в RS необходимо передавать параметры в виде сопоставимом с RS. То бишь дату например я передаю используя date2StrUsr(). Иначе параметр может просто не попасть в отчет, или даже привести к ошибке исполнения. Если будет 100 таблиц то везде требуется не забыть преобразовать данные при сохранении параметра. Заполнение параметров осуществляется из диалоговых форм Runbase к которым пользователи уже привыкли. Если они и введут неправильный параметр (например ранг в запросе) в итоге получат неправильный отчет, но то же самое они получали в аксапте, так что пока разницы не чувствую.
Поэтому все параметры преобразуются в строку и хранятся в одной таблице. А добавление параметра осуществляется через единый метод в наследнике Runbase.

Цитата:

Сообщение от mazzy

Но зато ваша экономия приведет к огромному динамическому программированию, к "универсальным" валидейтам, к неподъемному программированию прав
Подробнее см. Значение display метода по его названию

Насчет упрощения подписок - отчасти вы правы, но как вы права собираетесь раздавать? Или у вас все пользователи могут менять любые параметры?

Пришлось повозиться пару дней чтобы организовать таблицу для гибкой привязки параметров в аксапте с параметрами непосредственно в отчетах RS. Можно и без этого было обойтись, но неудобно переносить с одного сервера на другой и сервера перенастраивать при новых путях для отчетов на RS или изменении порядка параметров в отчете со стороны аксапты или RS. На этом динамическое программирование закончилось).
А насчет прав доступа выкручиваюсь таким образом). Разграничение доступа к таблице настройки параметров вручную осуществляется через форму. Те кому не положено не допускаются к ней обычными средствами. А заполнение прочих подписок выполняется через наследники Runbase. То есть если у пользователя есть права на формирование отчета он может добавить запись в подписку для данного класса. Если возникла ошибка при создании записи подписки достаточно в диалоге изменить значения полей с уникальным именем подписки и его пересохранить. А дальше все будет зависеть от безопасности на RS.

[mazzy]

Цитата:

Сообщение от KingPeas

Это имело бы значения если бы эти таблицы использовались в DAX. Но их основное назначение хранить параметры для стороннего приложения и легкий доступ к ним в этом приложение.

А в самом приложении?

Цитата:

Сообщение от KingPeas

Пришлось повозиться пару дней чтобы организовать таблицу для гибкой привязки параметров в аксапте с параметрами непосредственно в отчетах RS. Можно и без этого было обойтись, но неудобно переносить с одного сервера на другой и сервера перенастраивать при новых путях для отчетов на RS или изменении порядка параметров в отчете со стороны аксапты или RS. На этом динамическое программирование закончилось)

Спасибо. Надо подумать.

[KingPeas]

Цитата:

Сообщение от mazzy

А в самом приложении?

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

[Maxim Gorbunov]

Возвращаясь к изначальной проблеме, так и сделайте так, как это со стандартным Dimension сделано. Добавьте в таблицу поле, основанное на EDT-массиве. Затем сделайте в таблице Field Group, в которую добавьте Ваше новое поле. Идите в форму и создайте там группу (контрол Group), которому укажите DataGroup = <имя Field Group в таблице> и AutoDataGroup = Yes.

[KingPeas]

Цитата:

Сообщение от Maxim Gorbunov

Возвращаясь к изначальной проблеме, так и сделайте так, как это со стандартным Dimension сделано. Добавьте в таблицу поле, основанное на EDT-массиве. Затем сделайте в таблице Field Group, в которую добавьте Ваше новое поле. Идите в форму и создайте там группу (контрол Group), которому укажите DataGroup = <имя Field Group в таблице> и AutoDataGroup = Yes.

Ну да, собственно так и реализовал). Вся загвоздка была в том, что размер строки элемента используемого как extended для EDT как массива был Memo. Как только сменил Memo на 1000 символов все стало работать по писанному.