AXForum  
Вернуться   AXForum > Прочие обсуждения > Курилка
NAV
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск Все разделы прочитаны

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 27.01.2022, 16:40   #441  
trud is offline
trud
Участник
Лучший по профессии 2017
 
1,035 / 1616 (56) ++++++++
Регистрация: 07.06.2003
Записей в блоге: 1
Ну может автор хотел чтобы вы в каждом экстеншене паковали его query. Имеет же право
Старый 27.01.2022, 19:39   #442  
ax_mct is offline
ax_mct
Banned
 
2,548 / 1091 (0) ++++++++
Регистрация: 10.10.2005
Адрес: Westlands
Цитата:
Сообщение от trud Посмотреть сообщение
Ну может автор хотел чтобы вы в каждом экстеншене паковали его query. Имеет же право
Тут ведь не только базовые классы но и абсолютно все их экстеншен должны корректно обращаться с общим для всех контейнером. Достаточно любого соседнего экстеншен с подобной адресацией. Причем этот экстеншен типа работает, а ваше его ломает.
Старый 19.08.2022, 14:08   #443  
axm2017 is offline
axm2017
Участник
 
1,564 / 270 (13) ++++++
Регистрация: 15.05.2017
Долго не мог понять какого моя ER конфигурация (технически стандартный функционал ER\SSRS накладных) отказывается работать
Пришлось заглянуть в код.
Нажмите на изображение для увеличения
Название: strangeCode.png
Просмотров: 92
Размер:	51.7 Кб
ID:	13418
Много думал на тему рукожопства с ограничением по RU.
Старый 02.09.2022, 15:11   #444  
axm2017 is offline
axm2017
Участник
 
1,564 / 270 (13) ++++++
Регистрация: 15.05.2017
Делал доклад по ER
Традиционно (когда еще замечать косяки как не в ходе показа?) в его процессе заметил возможность добавить void в модель
Попробовал ради интереса.
Название: Screenshot 2022-09-02 144414.jpg
Просмотров: 427

Размер: 18.3 Кб
Много думал о команде ER и нехватке тестеров.
Старый 05.09.2022, 16:40   #445  
online
Stitch_MS
Участник
Аватар для Stitch_MS
Соотечественники
 
390 / 472 (16) +++++++
Регистрация: 27.02.2006
Адрес: Дания
X++:
BPUpgradeCodeSystemDate: BP Rule: [BPUpgradeCodeSystemDate]:Method systemdateget has been deprecated, use DateTimeUtil::getSystemDate(DateTimeUtil::getUserPreferredTimeZone()) instead.

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

"...
- Товарищ лейтенант, может, лучше лопатами?
- Мне не надо лучше, мне надо, чтобы вы замучились." (с)
За это сообщение автора поблагодарили: Logger (1).
Старый 05.09.2022, 16:55   #446  
axm2017 is offline
axm2017
Участник
 
1,564 / 270 (13) ++++++
Регистрация: 15.05.2017
Цитата:
Сообщение от Stitch_MS Посмотреть сообщение
..
Нельзя просто взять, и сделать так, чтобы systemDateGet вызывал DateTimeUtil::getSystemDate(DateTimeUtil::getUserPreferredTimeZone()).
Если они не идентичны (так как кто, когда, зачем и что делал неизвестно) то это как раз нормально: типа не сломаем то что было
Старый 05.09.2022, 17:59   #447  
online
Stitch_MS
Участник
Аватар для Stitch_MS
Соотечественники
 
390 / 472 (16) +++++++
Регистрация: 27.02.2006
Адрес: Дания
Цитата:
Сообщение от axm2017 Посмотреть сообщение
Если они не идентичны (так как кто, когда, зачем и что делал неизвестно) то это как раз нормально: типа не сломаем то что было
Хм, а ведь разница действительно есть. Сам писал про неё несколько лет назад.

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

А вот если после systemDateSet или DateTimeUtil::setSystemDateTime вызывать DateTimeUtil::getSystemDateTime, то время "замрёт".
За это сообщение автора поблагодарили: S.Kuskov (10), axm2017 (5).
Старый 05.09.2022, 22:15   #448  
Logger is offline
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
3,724 / 2721 (98) +++++++++
Регистрация: 12.10.2004
Адрес: Москва
Записей в блоге: 2
Цитата:
Сообщение от Stitch_MS Посмотреть сообщение
А вот если после systemDateSet или DateTimeUtil::setSystemDateTime вызывать DateTimeUtil::getSystemDateTime, то время "замрёт".
А обратно "отмереть" время можно ?
Старый 06.09.2022, 18:35   #449  
online
Stitch_MS
Участник
Аватар для Stitch_MS
Соотечественники
 
390 / 472 (16) +++++++
Регистрация: 27.02.2006
Адрес: Дания
Цитата:
Сообщение от Logger Посмотреть сообщение
А обратно "отмереть" время можно ?
Хороший вопрос, но пока не копал — не было необходимости.
Старый 26.10.2022, 04:31   #450  
trud is offline
trud
Участник
Лучший по профессии 2017
 
1,035 / 1616 (56) ++++++++
Регистрация: 07.06.2003
Записей в блоге: 1
Кто там говорил что виртуальные компании это плохо и сложно настраивать, поэтому их и убирают
Похоже эту функциональность решили переизобрести, но под новым названием - master company sharing (preview)
https://learn.microsoft.com/en-us/dy...n/srs-overview
Старый 26.10.2022, 10:42   #451  
sukhanchik is offline
sukhanchik
Administrator
Аватар для sukhanchik
MCBMSS
Злыдни
Лучший по профессии 2015
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,211 / 3361 (119) ++++++++++
Регистрация: 13.06.2004
Адрес: Москва
Цитата:
Сообщение от 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 - да, работает. Но как я уже писал с ограничением на объёмы синхронизируемых данных
__________________
Возможно сделать все. Вопрос времени
За это сообщение автора поблагодарили: Logger (3).
Старый 01.11.2022, 10:34   #452  
axm2017 is offline
axm2017
Участник
 
1,564 / 270 (13) ++++++
Регистрация: 15.05.2017
Табличка VendInvoiceInfoTable_RU
как понимаю под коррекцию создали поля
CorrectedInvoiceId_RU
CorrectedInvoiceDate_RU
CorrectedJournalId
но вижу перенос в VendInvoiceJour только первых двух полей что рождает порой неоднозначность
почему не перенесли и третье поле загадка
Старый 18.01.2023, 04:40   #453  
trud is offline
trud
Участник
Лучший по профессии 2017
 
1,035 / 1616 (56) ++++++++
Регистрация: 07.06.2003
Записей в блоге: 1
По ходу команда которая делала ГК еще осталась в MS и теперь они добрались и до InventTrans(у которой по видимому есть "фатальный недостаток")
Встречайте новые таблицы(пока только для склада) с GUID идентификаторами
Нажмите на изображение для увеличения
Название: NewInventTrans.png
Просмотров: 47
Размер:	196.3 Кб
ID:	13535

Оригинал вот здесь:
https://learn.microsoft.com/en-us/sh...y-transactions
За это сообщение автора поблагодарили: Logger (3).
Старый 18.01.2023, 10:04   #454  
ena_ax is offline
ena_ax
Участник
 
252 / 34 (2) +++
Регистрация: 06.12.2006
Цитата:
Сообщение от trud Посмотреть сообщение
По ходу команда которая делала ГК еще осталась в MS и теперь они добрались и до InventTrans(у которой по видимому есть "фатальный недостаток")
Встречайте новые таблицы(пока только для склада) с GUID идентификаторами
Вложение 13535

Оригинал вот здесь:
https://learn.microsoft.com/en-us/sh...y-transactions
Добрый день!
Для понимания, можете рассказать чем плохи или не удобны идентификаторы GUID?
Старый 18.01.2023, 10:33   #455  
Pandasama is offline
Pandasama
Участник
 
421 / 133 (5) +++++
Регистрация: 11.08.2014
Адрес: Барнаул
Цитата:
Для понимания, можете рассказать чем плохи или не удобны идентификаторы GUID?
Они не плохи, но, думаю, здесь избыточны. Больший размер чем у RecId, дольше генерятся.
За это сообщение автора поблагодарили: ena_ax (1).
Старый 18.01.2023, 10:43   #456  
Logger is offline
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
3,724 / 2721 (98) +++++++++
Регистрация: 12.10.2004
Адрес: Москва
Записей в блоге: 2
Цитата:
Сообщение от Pandasama Посмотреть сообщение
Они не плохи, но, думаю, здесь избыточны. Больший размер чем у RecId, дольше генерятся.
А еще по ним индексы неэффективно работают.
Фрагментация, то, сё...
За это сообщение автора поблагодарили: Pandasama (3), ena_ax (1).
Старый 18.01.2023, 11:08   #457  
fed is offline
fed
Moderator
Аватар для fed
Ex AND Project
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,847 / 5534 (190) ++++++++++
Регистрация: 13.03.2002
Адрес: Hüfingen,DE
Цитата:
Сообщение от Logger Посмотреть сообщение
А еще по ним индексы неэффективно работают.
Фрагментация, то, сё...
Вообще в SQL Server есть функция, которая возрастающие GUID генерирует. (NewSequentialId()), по которым проблемы фрагментации индекса не возникает. Тут правда вопрос - как разработчики GUIDы в своей логике генерируют...
Плюс - мне кажется что сейчас почти все индексы сжимаются, при этом с учетом того что они пишут что у них таблица в режиме append only, особо большого оверхида при обновлениях не будет, а при чтении за счет сжатия выигрыш будет существенным.
За это сообщение автора поблагодарили: ena_ax (1), Logger (5).
Старый 18.01.2023, 12:11   #458  
online
Владимир Максимов
Участник
КОРУС Консалтинг
 
1,607 / 1126 (41) ++++++++
Регистрация: 13.01.2004
Записей в блоге: 3
Цитата:
Сообщение от ena_ax Посмотреть сообщение
Для понимания, можете рассказать чем плохи или не удобны идентификаторы GUID?
Есть правило: пусть безобразно, зато единообразно

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

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

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

Хотя в данном случае, вроде бы, речь идет не об идентификаторе записи (RecId), а о некоем общем идентификаторе "процесса" вроде ParmId. Т.е. вроде бы, и не выбивается из общих принципов построения приложения в данном случае.
__________________
- Может, я как-то неправильно живу?!
- Отчего же? Правильно. Только зря...
За это сообщение автора поблагодарили: ena_ax (1).
Старый 18.01.2023, 13:27   #459  
Logger is offline
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
3,724 / 2721 (98) +++++++++
Регистрация: 12.10.2004
Адрес: Москва
Записей в блоге: 2
Цитата:
Сообщение от fed Посмотреть сообщение
Вообще в SQL Server есть функция, которая возрастающие GUID генерирует. (NewSequentialId()), по которым проблемы фрагментации индекса не возникает.
Это да.
Но если их инкрементно выделять, то пропадают все вкусности GUID и он становится ничем не лучше обычного RecId. Даже хуже, так как RecId всего 8 байт занимает.
Старый 18.01.2023, 14:11   #460  
fed is offline
fed
Moderator
Аватар для fed
Ex AND Project
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,847 / 5534 (190) ++++++++++
Регистрация: 13.03.2002
Адрес: Hüfingen,DE
Цитата:
Сообщение от Logger Посмотреть сообщение
Это да.
Но если их инкрементно выделять, то пропадают все вкусности GUID и он становится ничем не лучше обычного RecId. Даже хуже, так как RecId всего 8 байт занимает.
GUID проще выделить до записи в БД. То есть - в принципе UnitOfWork или махинации с suspendRecId() решают проблему, но MkGuid() все равно проще написать.
Теги
axapta, cil, d365fo, rasset, баг

 

Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 16:51.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.