The daily Axapta WTF

[trud]

Ну может автор хотел чтобы вы в каждом экстеншене паковали его query. Имеет же право

[ax_mct]

Цитата:

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

Ну может автор хотел чтобы вы в каждом экстеншене паковали его query. Имеет же право

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

[axm2017]

Долго не мог понять какого моя ER конфигурация (технически стандартный функционал ER\SSRS накладных) отказывается работать
Пришлось заглянуть в код.

Много думал на тему рукожопства с ограничением по RU.

[axm2017]

Делал доклад по ER
Традиционно (когда еще замечать косяки как не в ходе показа?) в его процессе заметил возможность добавить void в модель
Попробовал ради интереса.

Много думал о команде ER и нехватке тестеров.

[Stitch_MS]

BPUpgradeCodeSystemDate: BP Rule: [BPUpgradeCodeSystemDate]:Method systemdateget has been deprecated, use DateTimeUtil::getSystemDate(DateTimeUtil::getUserPreferredTimeZone()) instead.

Нельзя просто взять, и сделать так, чтобы systemDateGet вызывал DateTimeUtil::getSystemDate(DateTimeUtil::getUserPreferredTimeZone()).

"...
- Товарищ лейтенант, может, лучше лопатами?
- Мне не надо лучше, мне надо, чтобы вы замучились." (с)

[axm2017]

Цитата:

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

..
Нельзя просто взять, и сделать так, чтобы systemDateGet вызывал DateTimeUtil::getSystemDate(DateTimeUtil::getUserPreferredTimeZone()).

Если они не идентичны (так как кто, когда, зачем и что делал неизвестно) то это как раз нормально: типа не сломаем то что было

[Stitch_MS]

Цитата:

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

Если они не идентичны (так как кто, когда, зачем и что делал неизвестно) то это как раз нормально: типа не сломаем то что было

Хм, а ведь разница действительно есть. Сам писал про неё несколько лет назад.

Вкратце, systemDateSet "не влияет" на время суток, ну то-есть можно прибавлять и отнимать целые сутки, а часы и минуты будут тикать себе дальше, но это если потом использовать systemDateGet для проверки.

А вот если после systemDateSet или DateTimeUtil::setSystemDateTime вызывать DateTimeUtil::getSystemDateTime, то время "замрёт".

[Logger]

Цитата:

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

А вот если после systemDateSet или DateTimeUtil::setSystemDateTime вызывать DateTimeUtil::getSystemDateTime, то время "замрёт".

А обратно "отмереть" время можно ?

[Stitch_MS]

Цитата:

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

А обратно "отмереть" время можно ?

Хороший вопрос, но пока не копал — не было необходимости.

[trud]

Кто там говорил что виртуальные компании это плохо и сложно настраивать, поэтому их и убирают
Похоже эту функциональность решили переизобрести, но под новым названием - master company sharing (preview)
https://learn.microsoft.com/en-us/dy...n/srs-overview

[sukhanchik]

Цитата:

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

Кто там говорил что виртуальные компании это плохо и сложно настраивать, поэтому их и убирают
Похоже эту функциональность решили переизобрести, но под новым названием - master company sharing (preview)
https://learn.microsoft.com/en-us/dy...n/srs-overview

Так это давно уже "изобрели". И на уровне свойства таблицы можно было задать - данные единые или копируемые. Детально я не проверял, но год назад точно работал только режим "копируемые".
Т.е. технически, если я допустим группу клиентов шарю между компаниями - то создается вторая запись (с другим RecId), которая является полной копией другой записи и любая попытка изменить любое поле - автоматически приводит к синхронизации второй записи. Это я и называю режим "копируемые". И даже приводились ограничения от MS на объем таких "синхронизируемых" данных.

Тут собственно 2 проблемы:
1. Единая запись и автоматически копируемая - это всё-таки разные технологии. И постоянная синхронизация явно не увеличивает производительность
2. Про ссылки по RecId в этом случае можно забыть. В системе же действительно очень мало ссылок по RecId )) и конечно же этим ограничением можно пренебречь )))

И мне так и не довелось увидеть в работе режим Single (свойство Data sharing type на таблице). Режим Duplicate - да, работает. Но как я уже писал с ограничением на объёмы синхронизируемых данных

[axm2017]

Табличка VendInvoiceInfoTable_RU
как понимаю под коррекцию создали поля
CorrectedInvoiceId_RU
CorrectedInvoiceDate_RU
CorrectedJournalId
но вижу перенос в VendInvoiceJour только первых двух полей что рождает порой неоднозначность
почему не перенесли и третье поле загадка

[trud]

По ходу команда которая делала ГК еще осталась в MS и теперь они добрались и до InventTrans(у которой по видимому есть "фатальный недостаток")
Встречайте новые таблицы(пока только для склада) с GUID идентификаторами


Оригинал вот здесь:
https://learn.microsoft.com/en-us/sh...y-transactions

[ena_ax]

Цитата:

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

По ходу команда которая делала ГК еще осталась в MS и теперь они добрались и до InventTrans(у которой по видимому есть "фатальный недостаток")
Встречайте новые таблицы(пока только для склада) с GUID идентификаторами
Вложение 13535

Оригинал вот здесь:
https://learn.microsoft.com/en-us/sh...y-transactions

Добрый день!
Для понимания, можете рассказать чем плохи или не удобны идентификаторы GUID?

[Pandasama]

Цитата:

Для понимания, можете рассказать чем плохи или не удобны идентификаторы GUID?

Они не плохи, но, думаю, здесь избыточны. Больший размер чем у RecId, дольше генерятся.

[Logger]

Цитата:

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

Они не плохи, но, думаю, здесь избыточны. Больший размер чем у RecId, дольше генерятся.

А еще по ним индексы неэффективно работают.
Фрагментация, то, сё...

[fed]

Цитата:

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

А еще по ним индексы неэффективно работают.
Фрагментация, то, сё...

Вообще в SQL Server есть функция, которая возрастающие GUID генерирует. (NewSequentialId()), по которым проблемы фрагментации индекса не возникает. Тут правда вопрос - как разработчики GUIDы в своей логике генерируют...
Плюс - мне кажется что сейчас почти все индексы сжимаются, при этом с учетом того что они пишут что у них таблица в режиме append only, особо большого оверхида при обновлениях не будет, а при чтении за счет сжатия выигрыш будет существенным.

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

Цитата:

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

Для понимания, можете рассказать чем плохи или не удобны идентификаторы GUID?

Есть правило: пусть безобразно, зато единообразно

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

К сожалению, в отношении Axapta это правило уже давно нарушено. Сейчас с точки зрения именно идеологии построения приложения Axapta представляет собой не единый "монолит", а некую "сборную солянку", что существенно усложняет сопровождение.

Так вот, использование GUID как идентификатора записи в одном модуле - это еще одно нарушение "монолитности" (единообразия) идеологии. Дополнительная проблема при внесении изменений в код.

Хотя в данном случае, вроде бы, речь идет не об идентификаторе записи (RecId), а о некоем общем идентификаторе "процесса" вроде ParmId. Т.е. вроде бы, и не выбивается из общих принципов построения приложения в данном случае.

[Logger]

Цитата:

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

Вообще в SQL Server есть функция, которая возрастающие GUID генерирует. (NewSequentialId()), по которым проблемы фрагментации индекса не возникает.

Это да.
Но если их инкрементно выделять, то пропадают все вкусности GUID и он становится ничем не лучше обычного RecId. Даже хуже, так как RecId всего 8 байт занимает.

[fed]

Цитата:

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

Это да.
Но если их инкрементно выделять, то пропадают все вкусности GUID и он становится ничем не лучше обычного RecId. Даже хуже, так как RecId всего 8 байт занимает.

GUID проще выделить до записи в БД. То есть - в принципе UnitOfWork или махинации с suspendRecId() решают проблему, но MkGuid() все равно проще написать.