16.06.2017, 13:34 | #41 |
Участник
|
Вы думаете, что лечение происходит в AxForum? Я бы посоветовал нести боль в Яммер - там гораздо больше шансов быть услышанным принимающими решение.
Цитата:
Неужели инструментарий 3.0 не позволил бы программисту решить проблему разноски больших журналов? Те же хранимые процедуры это стандартное и приемлимое
решение. Перечислите, пожалуйста достоинства и недостатки использования TSQL для обработки данных в AX. |
|
16.06.2017, 13:36 | #42 |
Участник
|
ax_mct, в отдельной ветке, пожалуйста.
|
|
16.06.2017, 13:40 | #43 |
Участник
|
Цитата:
|
|
|
За это сообщение автора поблагодарили: mazzy (2). |
16.06.2017, 13:52 | #44 |
Moderator
|
Цитата:
Сообщение от belugin
Есть галка HotSwapping, тут вопрос, насколько медленнее работа с ней чем без нее - я не тестил.
|
|
|
За это сообщение автора поблагодарили: mazzy (2), belugin (2), Logger (3). |
16.06.2017, 14:01 | #45 |
Banned
|
Цитата:
Сообщение от belugin
Вы думаете, что лечение происходит в AxForum? Я бы посоветовал нести боль в Яммер - там гораздо больше шансов быть услышанным принимающими решение.
Мне кажется инструментарий, который не заставляет прикладного программиста переписывать код для достижения того же быстродействия лучше в этом аспекте чем тот, который заставляет. Перечислите, пожалуйста достоинства и недостатки использования TSQL для обработки данных в AX. Очень вероятно что Аксапту похоронили не злобный и циничный Майкрософт, а романтики программирования с горящими глазами верящие в светлое будущее программизма. Инструментарий для кодирования лучше/хуже, способ программирования лучше/хуже - это диагноз. Аксапта это продукт для кого? Я не ностальгирую по Аксапте, я сожалею о безумстве которое в головах. |
|
|
За это сообщение автора поблагодарили: mazzy (2), Pustik (5). |
16.06.2017, 15:36 | #46 |
Участник
|
Правильно ли я понимаю, что чтобы решить эту задачу, надо просто скопировать имеющуюся форму в новую, и в новой форме начинать колбасить?
добавить readonly датасорс на форму, для фильтрования Если я понимаю правильно, то это тоже подход. Тогда АХ7 еще можно переварить. Главное, наработать последовательность рутинных операций, с помощью которых можно быстро удовлетворять клиента. Тогда АХ7 уже не такая непонятная становится. Просто внешние обработки в ней хранятся не в файлах, как в 1С, а в AOT, вперемешку со стандартными объектами.
__________________
Мои утилиты для Аксапты версий 3.0-2012: http://aceofdatabase.blogspot.com/ Последний раз редактировалось Ace of Database; 16.06.2017 в 15:38. |
|
16.06.2017, 15:42 | #47 |
Участник
|
Баааалин.
Докатились. Теперь злостный копипаст у нас признается нормальным способом. |
|
|
За это сообщение автора поблагодарили: Ace of Database (2), mazzy (2). |
16.06.2017, 15:49 | #48 |
Участник
|
Автоматом получив при этом практическую невозможность установки дальнейших обновлений и фиксов. форма SalesTable довольно огромная форма, которая часто меняется
|
|
16.06.2017, 15:58 | #49 |
Участник
|
|
|
16.06.2017, 15:59 | #50 |
Участник
|
Цитата:
Я обычно ищу примеры в Аксапте или в интернете и копирую их. Судя по всему, для того, чтобы экстендить форму, надо написать кучу служебного кода. Вы что, каждый раз этот код будете вручную писать? Я, например, когда создаю класс-наследник от RunBase копирую методы из RunBase в новый класс и правлю их. А при экстендинге придется еще больше повторяющегося служебного кода копировать.
__________________
Мои утилиты для Аксапты версий 3.0-2012: http://aceofdatabase.blogspot.com/ |
|
16.06.2017, 16:04 | #51 |
Участник
|
Сделать как раньше, кастомизацией - закроют то только через год, да и то это только в планах
опционально написать о проблеме в микрософт |
|
|
За это сообщение автора поблагодарили: Ace of Database (2), mazzy (2). |
16.06.2017, 16:10 | #52 |
Участник
|
Спасибо, trud!
Я просто пытаюсь разобраться. Обычно у любого продукта есть нить, ухватившись за которую можно начать работать. В любом продукте есть какой-то свой шаблон действий, главное его понять. Еще ни разу не встречал "Сферического коня".
__________________
Мои утилиты для Аксапты версий 3.0-2012: http://aceofdatabase.blogspot.com/ |
|
16.06.2017, 17:19 | #53 |
Banned
|
Это понятно что хранимые процедуры сложно/непривычно поддерживать.
Но парадокс то и в том что шли, шли и пришли к тому же решению которого могло быть достаточно и в 3.0. Цитата:
Цитата:
Но это оффтоп если за/против, тут интересно то что как и с хранимыми процедурами, пришли к тому же, только уже в менее удобной форме. Да какой там балаган. Это о вполне реальной нашей болезни. Жертвой который и пала Аксапта. |
|
16.06.2017, 19:16 | #54 |
Участник
|
Цитата:
Цитата:
Есть такое. Я тоже ведь больной. Но в принципе я оцениваю эффективность и достаточность, а не "правильность". C точки зрения поддержки и изменений те же хранимые процедуры не хуже и не лучше, нужно просто правильно их готовить.
|
|
16.06.2017, 19:20 | #55 |
Участник
|
Цитата:
(Как не смутно помнится, надо было очень аккуратно перекомпилировать наследников, если как-то не до конца это сделаешь, то будут странные ошибки или тихо данные возьмутся из другого поля) |
|
16.06.2017, 23:21 | #56 |
Banned
|
Да, журналы ГК не разносятся через хранимые процедуры. Но я о жизни программиста когда все с той же лопатой в руках но уже крутясь между дорогой и сверкающей техникой.
Как должна решаться недостаточно быстрая разноска? Через хранимые процедуры. Правильно через неплохое ОOП, LedgerVoucher* ? Да, правильно. Потому и медленно. Цитата:
Цитата:
Проблема в том что большинство в упор не видит программизма и что есть оverengineering. LedgerVoucher* - вполне может быть тем самым оverengineering. А нежелание писать с использованием хранимых процедур - программизмом. |
|
17.06.2017, 00:04 | #57 |
Участник
|
Цитата:
К решению чего? |
|
17.06.2017, 01:11 | #58 |
Участник
|
Люди, никогда не признаю правильной стратегию копипастить. Честно , зло берет.
__________________
-Ты в гномиков веришь? -Нет. -А они в тебя верят, смотри, не подведи их. |
|
17.06.2017, 01:55 | #59 |
Banned
|
Цитата:
Парадокс в том что идя по пути совершенствования средств программирования и инструментария в AX (по крайней мере течение вещей именно так представляется собирательному образу большинства программистов AX), программисту AX легче не стало. Конкретно по хранимым процедурам - они как были так и остались одним из самых эффективных способов повышения производительности. Не знаю как насчет роли сборщика мусора, но нормализацию LedgerTrans в 4 кажется таблицы сделанную в AX2012 можно было сделать и в "3.0". А если таки про сборщик мусора в 3.0 и устарелость виртуальной машины X++ - то при наличии таких проблем надо решать именно и только их. Все лишнее - программизм |
|
17.06.2017, 02:20 | #60 |
Banned
|
Цитата:
а для реального облегчения жизни как hint, когда это твой выстраданный выбор, то достаточно часто имеет смысл. Если есть нетронутая SYS форма и твои изменения существенны то сдублировать ее - на мой взгляд разумно. Так же при перегрузке методов - иногда здравый смысл говорит что лучше менять копию если это упростит жизнь тебе и программисту после тебя. Часто соображения безопасности твоего решения - чем больше сбоку тем меньше претензий к тебе как к подрядчику. Как бы это не противоречило Искусству. Но вот если от самого такого решения физически плохо и мутит, несмотря на его здравость - это программизм |
|
Теги |
sysoperation framework |
|
Опции темы | Поиск в этой теме |
Опции просмотра | |
|