непонятное поведение поля enum NoYes

[timaluhs]

Есть таблица со всеми льготами
EmplID, NumOfbenefits, и разные поля в которых есть дополнительные характеристики

Нужно созадть табличку в которой в одной строке будут все льготы для сотрудника.
Создала табличку типа EmplID, Benefit1, характеристики для Benefit1, Benefit2, характеристики для Benefit2 ну и так до 27...
поля Benefit1 типа Enum, EnumType NoYes
В классе запускается цикл. Внутри цикла для каждого benefits

select BenefitTbl where BenefitTbl .emplId == MyTbl.EmplId
         && BenefitTbl .BenefitTypeId == '01';
//если есть такая льгота то 
        if (BenefitTbl != NULL)
        {
            MyTbl.Benefit1= NoYes::Yes;
                 
        }
        else
        {
            MyTbl.Benefit1= NoYes::No;
        }

и это повторяется для всех benefits только со сменой номера .

Вопрос 1: Почему-то в enum поля не всегда правильно записывается значение. С дебагером захожу внутрь цикла - т.е. должно быть Yes -1, a в БД - 0
Есть какая-то хитрость?
Вопрос 2: Можно ли это как-то оптимизировать. Муторно очень всё копировать
Спасибо

[Zabr]

1) после записи значения не забываете делать MyTbl.update() ?
2) вместо "if (BenefitTbl != NULL)" лучше писать "if (BenefitTbl)" или "if (BenefitTbl.recid)"

[samolalex]

попробуйте убрать

if (BenefitTbl != NULL)

и оставить

if (BenefitTbl)

[lev]

Цитата:

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

попробуйте убрать

if (BenefitTbl != NULL)

и оставить

if (BenefitTbl)

а ещё лучше:

if (BenefitTbl.RecId != 0)

[Krasher]

Я бы ещё бы проверил, что присутствует select forupdate MyTbl..., присутствуют операторы открытия/закрытия транзакции ttsbegin/ttscommit..., ну и разумеется MyTbl.update();

[pitersky]

Цитата:

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

Нужно созадть табличку в которой в одной строке будут все льготы для сотрудника.
Создала табличку типа EmplID, Benefit1, характеристики для Benefit1, Benefit2, характеристики для Benefit2 ну и так до 27...
поля Benefit1 типа Enum, EnumType NoYes

Ужасное решение. Просто ужасное. НЕ делайте так никогда.
Надо было создать табличку с полями EmplId/BenefitType/BenefitDescription. В BenefitType записать все возможные типы льгот (создать соответствующий Enum или использовать таблицу льгот, если она есть), в BenefitDescription - то, что относится по типу к EmplId. А дальше на EmplTable создаёте закладку, на которой отображаете льготы для конкретного человека.
Если надо всё-таки в одну строку выводить (именно выводить, а не хранить!!!) - нарисуйте соответствующую формочку. Но я не вижу в этом особого смысла.

[timaluhs]

Цитата:

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

Ужасное решение. Просто ужасное. НЕ делайте так никогда.
Надо было создать табличку с полями EmplId/BenefitType/BenefitDescription. В BenefitType записать все возможные типы льгот (создать соответствующий Enum или использовать таблицу льгот, если она есть), в BenefitDescription - то, что относится по типу к EmplId. А дальше на EmplTable создаёте закладку, на которой отображаете льготы для конкретного человека.
Если надо всё-таки в одну строку выводить (именно выводить, а не хранить!!!) - нарисуйте соответствующую формочку. Но я не вижу в этом особого смысла.

Всё это уже есть. просто наши HR хотят всё видеть сразу. Поэтому создаётся такая никому не нужная таблица в классе, который будет по ночам обноблять в batch.
поэтому кажется forupdate несколько не в тему
в начале есть
delete_from MyTbl;

и в конце каждой итерации MyTbl.insert();

Попробую заменить
if(BenefitTbl != NULL) на if (BenefitTbl.RecId != 0)
Хотя с дебагером заходит в if , но значение почему-то не меняет

[pitersky]

Цитата:

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

Всё это уже есть. просто наши HR хотят всё видеть сразу.

Мне кажется, что это не тот случай, когда надо под HR прогибаться (извините за слэнг). Полученная таблица крайне ненаглядна и неудобна в работе. Могу предположить, что утром это копипастят в Excel и дальше работают автофильтрами, отбирая нужное. Если это так, то может проще нарисовать им нужную выгрузку, а не плодить лишние таблицы?

Цитата:

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

Вот собственно и первое предложение по оптимизации. Вместо delete_from и потом нового её заполнения, почему не использовать .update() только того, что изменилось

С точки здения быстродействия update хуже, потому что обновляемую запись надо сначала найти. В то же время delete_from работает очень быстро. Если не жалко RecId, то лучше пересоздавать

[timaluhs]

Цитата:

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

Если это так, то может проще нарисовать им нужную выгрузку, а не плодить лишние таблицы?

а как это сделать?

[pitersky]

Цитата:

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

а как это сделать?

А что тут сложного? Делаете цикл по EmplTable (это строка выгрузки), внутри него делаете вывод в Excel данных по каждому типу льгот (делая запросы к таблице льгот по типу и EmplId)

[S.Kuskov]

Цитата:

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

а как это сделать?

Точно также как вы делали вставку в таблицу, только вместо инициализации полей таблицы найденными значениями, отправляйте эти значения в excel или лучше во временную таблицу ADORecordset, а уже её заполненную одним махом в excel (так будет быстрее )
Есть ещё конечно вариант с OLAP и RS, но это не обязательно
Программное добавление столбцов в отчёт

И на будущее, если необходимо сделать в таблице 27 столбцов одного типа, отличающихся только индексом, то используйте расширенный тип данных основанный на масиве полей (стандартный пример - тип Dimension)

[timaluhs]

Цитата:

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

С точки здения быстродействия update хуже, потому что обновляемую запись надо сначала найти. В то же время delete_from работает очень быстро. Если не жалко RecId, то лучше пересоздавать

подозреваю что HR не заботит проблема с RecID
а искать то что надо обновить кажется ещё непригляднее

[Ivanhoe]

Цитата:

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

Вопрос 2: Можно ли это как-то оптимизировать. Муторно очень всё копировать
Спасибо

Оптимизация простая - сделать по-другому. Поясните что и зачем вы делаете, тогда, возможно, получите дельный совет

[timaluhs]

Цитата:

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

Оптимизация простая - сделать по-другому. Поясните что и зачем вы делаете, тогда, возможно, получите дельный совет

писала выше. HR заказали форму в которой будут показаны все льготы всех сотрудников включая характеристики некоторых льгот или галочку (есть/нет)
их не устраивает лазить по каждому отдельному сотруднику, подозреваю что это будет некая отчётность для поставщиков (машина, сотовый, комп и т.д.)

посему решено создать подтаблицу и её показывать в форме

[Krasher]

Вот собственно и первое предложение по оптимизации. Вместо delete_from и потом нового её заполнения, почему не использовать .update() только того, что изменилось?

[S.Kuskov]

Цитата:

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

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

Судя по всему при написании подобного кода использовалась технология Copy/Past .

Цитата:

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

С дебагером захожу внутрь цикла - вижу как значение меняется с No на Yes.

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

[timaluhs]

Цитата:

Сообщение от S.Kuskov

Судя по всему при написании подобного кода использовалась технология Copy/Past .

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

именно так оно и было, Спасибо
как всегда на дурацкие ошибки уходит куча времени

а как можно узнать какой сейчас до какого RecID мы уже добрались и насколько актуальна проблема зашкаливания.
DAX 2009

[lev]

Цитата:

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

а как можно узнать какой сейчас до какого RecID мы уже добрались и насколько актуальна проблема зашкаливания.
DAX 2009

в АОТ в узле System Documentation \ Tables таблице SystemSequences, в ней поле NextVal это то значение которое у вас сейчас в системе. В поле MaxValue максимально допустимое значение. Сравните и поймете насколько вы приблизились к максимуму.

про зашкаливания. в АХ2009 (и в АХ 4.0) recId теперь 64 битное (а не 32 как было в трешке ), поэтому не думаю что оно у вас скоро зашкалит

P.S. про RecId уже обсуждалось aEremenko: Дефрагментация RecID
выдержка из ссылки по сути:

Цитата:

"Ситуация в DAX 4.0

Версия 4.0 содержит 64-битный пул RecID, RecID базируется на новом типе int64. Также, в DAX 4.0, можно сегментировать RecID в разрезе таблиц. Этого более чем достаточно для очень крупной компании лет на 100."

[timaluhs]

Цитата:

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

в АОТ в узле System Documentation \ Tables таблице SystemSequences, в ней поле NextVal это то значение которое у вас сейчас в системе. В поле MaxValue максимально допустимое значение. Сравните и поймете насколько вы приблизились к максимуму.

Но посмотреть пока не удалось.
Попытки открыть таблицу не удались - выкидывает меня в Help
права у меня админские, я в этой копии - "адын савсем адын"

Цитата:

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

про зашкаливания. в АХ2009 (и в АХ 4.0) recId теперь 64 битное (а не 32 как было в трешке ), поэтому не думаю что оно у вас скоро зашкалит

понятно что волноваться пока рановато

[lev]

Цитата:

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

Но посмотреть пока не удалось.
Попытки открыть таблицу не удались - выкидывает меня в Help
права у меня админские, я в этой копии - "адын савсем адын"

Таблица открывается как и обычные таблицы в Data Dictionary.
т.е. Правая кнопка мыши --> Надстройки (AddIns) --> обозреватель таблиц