Работа со сторонней базой через X++

[Kainix]

Добрый день.

Пытаюсь реализовать функционал хранения файлов в базе, но не в текущей, с которой работает аос, а со сторонней. Для этого на том же экземпляре SQL создал тестовую базу с 1й таблицей, которая состоит из 2х полей Int64(BigInt) и Container(Image).
И пытаюсь записывать туда файлы ссылкой по RecId на DocuValue.

В принципе через ADODB, это получилось. Но там нет красивости кода. Поэтому пытаюсь написать полноценную обертку основываясь для работы с SQL на System.Data.SqlClient. И я воткнулся в следующие проблемы.
1. Это как передать в System.Data.SqlClient.SqlParameter BinData.
2. Это перехват исключений

По пункту 1 посмотрел темы по работе с ContainerClass, BinData, хочется понять как сама аксапта засовывает контейнеры в SQL именно в поле image, для того чтобы м.б. в дальнейшем сделать можно было расширять обертку.
По пункту 2 пробовал пользоваться

try
{
 ...
}
catch(Exception::CLRError)
{
        e = CLRInterop::getLastException();
}

Объект System.Exception всегда пустой не понятно почему не возвращает, хотя в блок catch попадает.

Спасибо.

[Kainix]

Решение вопросов.
1. Записывать в базу контейнера как аксапта это делает (получается такой же Image)

conClass = new ContainerClass(con);
binData = new BinData();
binData.setData(conClass.toBlob());
string = binData.base64Encode();
clrObject = System.Convert::FromBase64String(string);
//clrObject отправляем в System.Data.SqlClient.SqlParameter.Value

На выходе получаем byte[], который пригоден для записи в базу.
2. Выяснилось что SQL генерирует разные уровни оповещений, и не все являются ошибками, которые перехватывает метод CLRInterop::getLastException().
Также хочу заметить что аксапта не может использовать нетовские handler(обработчик событий. Поэтому
Решение - написание библиотеки, которая в себе содержит функции обработки событий и возвращает готовые исключения типа SqlException или Exception, либо это info от sql типа SqlInfoMessageEventArgs

public class SysSqlCommand
    {
        SqlCommand      sqlComm;
        SqlException    sqlEx;
        Exception ex;

        public SysSqlCommand(SqlCommand _sqlComm)
        {
            this.sqlComm = _sqlComm;
        }
        public void ExecuteNonQuery()
        {
            try
            {
                sqlComm.ExecuteNonQuery();
            }
            catch (SqlException _ex)
            {
                sqlEx = _ex;
                throw;
            }
            catch (Exception _ex)
            {
                ex = _ex;
                throw;
            }
        }
        public SqlException sqlException()
        {
            return sqlEx;
        }
        public Exception exception()
        {
            return ex;
        }
    }

Вот как то так.

[Kainix]

В дополнение напишу, что п. 1 можно сделать через VARAINT SafeArray, но я не смог разобраться как привести SafeArray - byte[], и мне кажется что это нужно будет делать в dll

[MikeR]

Не прочувствовал, зачем файлы хранить именно в базе? То есть почему просто не использовать допустим файловое хранилице? И почему файлы (правда вы не написали, что за файлы) допустим не хранить в ресурсах системы?

[Kainix]

Как же не написал DocuValue, стандартный функционал выносим в базу.
Получаемые плюсы,
1. Это доступ, если использовать файловое хранилище то каждый пользователь получает доступ. Например если хранятся изображения, то стандартным просмоторщиком можно их смотреть. Открыл изображение и крути себе скрол))).
2. Это бекапирование. Куда проще хранить бекап одного файла чем все эти папки и файлы.
3. Можно контролировать кто открыл файл и держит - стандартный функционал.
4. Так же если документов уж очень много. то возникают баги, тормоза при обслуживании всего этого хозяйства. Найти документ вручную, удалить подменить (хотя спорный момент)

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

Самое главное что не теряем контейнеры, которые хранятся в этих 2х таблицах.

Ну и наверно еще извращенный мозг сможет придумать применение, при детальном подходе.

[Kainix]

Не написал как доставать контейнер.
К сожалению не получилось средствами аксапты, не поддерживает синтаксис. Пришлось писать стороннюю функцию

public static string getStrFromImg(Object _img)
        {
            byte[] image = (byte[])_img;

            return Convert.ToBase64String(image);
        }

И функция в аксе

protected container getContainer(int _colNum)
{
    str     string = IAU.Functions::getStrFromImg(dataReader.GetValue(_colNum));
    ;

    return ContainerClass::blob2Container(binData::loadFromBase64(string));
}

Где System.Data.SqlClient.SqlDataReader dataReader; IAU.Functions - библиотека с функцией

[Kainix]

Нашел метод считывания контейнеров без библиотеки.

protected container getContainer1(int _colNum)
{
    str     string ;
    ;
    string = CLRInterop::staticInvoke("System.Convert", "ToBase64String", dataReader.GetValue(_colNum));
    return ContainerClass::blob2Container(binData::loadFromBase64(string));
}

Итого библиотека понадобится чтобы обрабатывать сообщений из SQL

[db]

Цитата:

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

Как же не написал DocuValue, стандартный функционал выносим в базу.
Еще возможное использование. Все знаем SysDataBaseLog, которая ну очень большая, и приходится все время что то с ней делать. А тут можно преспокойно вынести в отдельную базу, и не таскать везде ссобой.

бррр... что то не сходится. если причины только в этом, то точно ничего не понимаю

что мешает вынести таблицы документооборота и SysDataBaseLog в отдельные файловые группы? бекапить/ресторить сможете отдельно, сможете засунуть на другие (более медленные/дешевые/просто другие) диски. делается пяткой левой ноги за 15 минут любым администратором бд без каких либо изменений в DAX

[Raven Melancholic]

Цитата:

Это доступ, если использовать файловое хранилище то каждый пользователь получает доступ

Ну это в том случае, если админы дали полный доступ в каталог хранения файлов. Нормальный админ в этом каталоге запретит перебор состава каталога. Тогда к файлу можно обратиться только по полному имени. Для Аксапты проблем нет, через файловые менеджеры не получится.

Цитата:

Это бекапирование. Куда проще хранить бекап одного файла чем все эти папки и файлы.

Хранить проще. Но бэкапирование должно производится по определенным правилам, которые включают время на операцию. Если все данные в одной файловой группе (или бэкап делается не по файловым группам, а в целом по базе), то все зависит от соотношения полезных данных и редкоменяемых данных в blob полях. Если размер файлов, хранимых в вашей базе, сопоставим по объему с остальными данными, то можем поиметь проблемы. Данные файлов в blob полях меняются редко, а архивировать их нужно вместе со свей базой данных.

Цитата:

Можно контролировать кто открыл файл и держит - стандартный функционал.

Да, можно, но только с одним уточнением "В Аксапте". Если кто-то его открыл извне (из файловой системы или есть какой-то внешний клиент, понимающий формат хранения изображений в базе Аксы), то Акса ничего про это не знает.

Цитата:

Так же если документов уж очень много. то возникают баги, тормоза

Насчет багов не знаю, но тормоза при хранении всех прикрепленных файлов в одном каталоге есть. Когда количество файлов превышает пару десятков тысяч, то управлять каталогом очень сложно. Один просмотр его в любом файловом менеджере может повиснуть на несколько минут. Но тут есть стандартная возможность Аксы распределять разные типы документов по разным каталогам, прямо указывать путь к файлам (при определенных настройках). Ну и очень простая модификация, позволяющая хранить определенные файлы в разных каталогах и на разных серверах (по типам, по времени создания и т.п.). По крайней мере, такая модификация оставляет стандартные возможности и не требует извращений с внешними базами.

Цитата:

Все знаем SysDataBaseLog, которая ну очень большая

Согласен, на этапе запуска и внедрения новой функциональности хочется включить как можно больше логов. Но такие этапы, в конце концов, заканчиваются. Если в режиме эксплуатации включены все возможны логи, то это уже паранойя.
Ну уж если нужно хранить любой чих в течение ста лет, то можно посмотреть на секционирование таблиц, предлагаемое MS SQL. Правда, если при настроенном секционировании изменить именно SysDataBaseLog, то при синхронизации таблиц, скорее всего, Акса убьет это секционирование и его нужно будет настраивать заново. Но как часто изменяется структура SysDataBaseLog?

[Raven Melancholic]

Ну, а если очень хочется работать именно из Аксапты со сторонней базой, то можно использовать одну из особенностей работы Аксы со своей базой. На данном форуме уже не раз приводился способ работы из Аксы не со своими таблицами, а с вьхами, которые Акса считает своими таблицами. Поищите на форуме соответствующие темы. Основной принцип:

• В AOD создается таблица нужно структуры. Она синхронизируется с базой данных.
• В базе данный средствами MS SQL таблица удаляется, а вместо неё создается view той же структуры, но в запросе вьюхи обращение идет к нужным данным (не исключено, что на другой сервер), если нужно, то вьюха делается индексируемой. Единственное правило, что если из Аксапты будут идти запросы на обновления, вставку, удаление, то вьюха должна поддерживать эти операции (смотри BOL).
• Такой подход потребует некоторых изменений в базовых классах синхронизации таблиц, но модификация простая и описана в темах этого форума.
• После таких манипуляций Акса будет работать так, как будто это её родная таблица, но MS SQL обращаться будет не к таблице, а к вьюхе.

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

[Kainix]

Спасибо за конструктивную критику, не знал про возможности решения моей проблемы, другими способами, всегда приятно иметь альтернативы. И возможность работать с аксой напрямую с другими базами тоже нужна. Поговорю с админами на счет настройки прав и вынос таблицы в отдельную файловую группу.

[Vadik]

AX 2012 - storing Dynamics AX Document Attachments Within SharePoint

[Kainix]

Обертка для работы со сторонней бд (с поддержкой контенеров)
SharedProject_IAU_SQL (1).xpo - проект
IAU.rar - dll

Можно без dll, тогда не перехватить сообщения от sql. чтобы все работало зайти в места поменять одноименные методы, класса

метод nmExecuteNonQuery - sqlCommandForEx.ExecuteNonQuery(); на sqlCommand.ExecuteNonQuery();

Описание краткое
n - net
p - property
s - set
g - get
m - method

nps - net property Set
npg - net property Get
nm - net method

Вопрос еще такой, как лучше делать обертках, наследовать классы или без наследования.
Если наследовать тогда можно избежать методов которые работают с net классами, но тогда нужно следить за инициализацией всех объектов. Если не наследовать то есть методы которые принимают и возвращают net классы.

[Kainix]

пример использования. Выбор и запись в таблицу, состоящую из 2х полей RefRecId int64(bigint) и BinData container(image).
Для доступа к конкретным полям нужна обертка для System.Data.DataSet

static void IAU_Connection(Args _args)
{
    SysSqlConnection                    sysSqlConnection;
    SysSqlCommand                       SysSqlCommand;
    SysSqlConnectionStringBuilder       sysSqlStringBuilder;
    SysSqlConnectionTable               sysSqlConnectionTable;
    SysDataRowCollection                sysDataRowCollection;
    SysDataRow                          sysDataRow;
    SysSqlDataReader                    sysSqlExecuteReader;
    
    System.Exception                    e;
    ;
    try
    {
        sysSqlStringBuilder = new SysSqlConnectionStringBuilder();

        sysSqlStringBuilder.npsServer('');
        sysSqlStringBuilder.npsDataBase('');
        sysSqlStringBuilder.npsUserName('');
        sysSqlStringBuilder.npsUserPassword('');

        sysSqlConnection = new SysSqlConnection(sysSqlStringBuilder.npgConnectionString());
        SysSqlCommand = sysSqlConnection.sysSqlCommand();

        SysSqlCommand.npsCommandText("SELECT * from Table where RefrecId = @RefRecId");
        SysSqlCommand.sysSqlParameterCollection().addSysSqlParameter("@RefRecId", 5637374403);
        sysSqlExecuteReader = SysSqlCommand.sysSqlExecuteReader();
        sysSqlExecuteReader.nmRead();

        if(sysSqlExecuteReader.npgHasRows())
        {
            sysSqlExecuteReader.nmClose();
            SysSqlCommand = sysSqlConnection.sysSqlCommand();
            SysSqlCommand.npsCommandText("Update Table set binData = @BinData where RefrecId = @RefRecId");
            SysSqlCommand.sysSqlParameterCollection().addSysSqlParameter("@RefRecId", 5637374403);
            SysSqlCommand.sysSqlParameterCollection().addSysSqlParameter("@BinData",  connull());
            SysSqlCommand.nmExecuteNonQuery();

        }
    }
    catch(Exception::CLRError)
    {
        e = CLRInterop::getLastException();
        if(e)
        {
           while(e)
            {
                info(e.get_Message());
                e = e.get_InnerException();
            }
        }
        e = SysSqlCommand.clrSqlExeption();
        if(e)
        {
           while(e)
            {
                info(e.get_Message());
                e = e.get_InnerException();
            }
        }
        else
        {
            e = SysSqlCommand.clrExeption();
            if(e)
            {
               while(e)
                {
                    info(e.get_Message());
                    e = e.get_InnerException();
                }
            }
        }
    }
}