Цитата:
Сообщение от
kashperuk
Выборка через АОС или выборка напрямую из SQL Server
(Данные выбираются для валидации корректной работы приложения после выполнения заданного сценария).
Я что-то не могу вспомнить недостатков прямого похода через SQL, кроме нижеприведенных. Помню, что массу раз обсуждалось, но не нашел ничего интересного. Добавьте кто что может
Недостатки SQL:
- Не учитывает настроек безопасности (особенно RLS)
- Проблемы с генерацией RecId при необходимости вставки данных
Недостатки AOS:
- Медленнее
Недостатки SQL:
= не учитывается кэширование, которое выполняет Аксапта. (что очень плохо)
= не учитывается метод postLoad (правда он уже устаревший), но все равно он используется в LedgerTrans. Также некоторые его используют для логов
= не учитываются display-методы и вообще методы у таблиц
= если пользоваться recordset'ом, то прямой доступ к SQL теряет информацию о типах
= не учитываются виртуальные компании.
= не учитываются свойство (общих таблиц)
= (!) не учитываются
конфигурационные и лицензионные ключи (в результате, прямой запрос в SQL должен сам определять какие поля/таблицы есть, а каких нет и перестраиваться на ходу. Обрати внимание сколько труда положили на OLAP кубы, сколько новых объектов в АОТ ввели (перспективы и датасеты) и сколько документов написали на эту тему. Универсальный обработчик с прямым доступом - безумно сложная штука. Если на конкретном проекте с конкретным набором ключей его сделать легко, то в общем случае - не знаю... очень велика вероятность, что накосячат.
= (!) не учитываются конфигурационные и лицензионные ключи
на индексах. Со всеми вытекающими для уникальности...
= прямой доступ и доступ через SQL по разному общаются с Array-полями. Array-поля у клиентов используются не только в аналитике. Клиенты делают и свои array-поля. при прямом доступе с большой вероятностью можно накосячить в них
= прямой доступ должен знать о настройках выравнивания (влево-вправо) и корректно работать с ними
= прямой доступ должен знать о настройках Case и корректно работать с этим параметром.
= прямой доступ должен знать о настройках часового пояса в каждой компании (включая виртуальные), если прямой доступ работает с UTC-полями.
= если речь идет о проверках, то не учитываются validateField и validateWrite, в которых написано огромная часть бизнес-правил.
= если в результате проверок будут выполняться какие-то автокоррекции, то при прямом доступе к SQL идут лесом все аксаптовские database логи, все update, и даже doUpdate (на которые программисты очень сильно надеются как на последнее средство контроля)
= если в результате проверок будет хоть как-то меняться схема (добавляться поля, индексы, изменяться длина полей), то очень велика вероятность рассинхронизации и очень велика верояность, что прямой доступ сделает схему, которую нельзя прочитать в самой Аксапте (например, не хватает буфера)
это навскидку.
Я задачу "сделать универсальную проверку и коррекцию с прямым доступом к SQL" побоялся бы поставить и опытному то программисту... А в майкрософте наверняка будут делать люди, которые с аксаптой не работали.
Нафих!
пусть используют нормальный Аксаптовский доступ.
во время проверок пусть используют нормальные Аксаптовские местоды и классы (в них тоже есть баги, баги в методах и классах тоже исправлять нужно)
в общем, тестирование и исправление должно работать при помощи тех же средств, которые используются нормальными клиентами. В противном случае велика вероятность того, что с точки зрения "проверок МС" все Ок, а с точки зрения клиента - косяки.
==========
посмотрел что писали люди выше:
= согласен про base enum
= хорошо про перекрестные ссылки
= отлично про различие в написании полей
= замечательно про различие в MS SQL и Oracle версиях
= добавлю про работу с разными языками и метками... (например, в нумераторе хранится метка, метки могут хранится и в других местах. доступ к значениям меток организовать прямыми запросами очень проблематично)
===========
еще добавил
= при анализе конфигурационных и лицензионных ключей нужно разбирать не только наличие/отсутствие полей индексов, но также наличие отключенной таблицы в "середине" запроса. стандартный механизм худо-бедно с этой задачей справляется. Как с этим будет справляться прямой доступ к SQL - не знаю. В результате сам механизм анализа конфигурационных ключей и перестройки запроса супресложным получается. А следовательно сам по себе будет требовать отдельного и очень кропотливого тестирования.
===========
блин, еще добавил:
Цитата:
= если пользоваться recordset'ом, то прямой доступ к SQL теряет информацию о типах
а следовательно прямой доступ теряет информацию о relation.
Для тестирования важно, что теряется свойство validation, указанное в relation.
кроме relation в типах также теряется relation, указанный в таблицах