|
28.08.2014, 09:50 | #1 |
Участник
|
Цитата:
выше, например, упоминали Linked Server - транзакции синхронизируются с помощью сервиса DTS без какого то участия, надо только настроить DTS с ODBC тоже проблем нет никогда не сталкивался с WCF с этой точки зрения и вот возник вопрос, насколько я понял, по ссылке просто описания транзакционности WCF |
|
28.08.2014, 11:00 | #2 |
Участник
|
Хотелось поблагодарить всех участников за высказанное мнение, но все таки, если принять за аксиому то, что нужен доступ к MySQL через ODBC - в чем причина отсутствия каких-либо данных в resultset?
Немного дополнительной информации: Версия MySQL - 3.51. Версия 32-битного драйвера на клиенте - 3.51.06 Код выполняется из джоба на 32-битном клиенте. Коннект к БД точно есть, так как при наличии ошибок в запросе система реагирует соответствующими информационными сообщениями. При попытке выполнить данный джоб на сервере АОС (64 битная архитектура) сначала ругалось на отсутствие драйвера MySQL ODBC на сервере. Нашли 64-битный драйвер - версия 3.51.30. Установили сразу оба (32-битный и 64 битный), каждый в свою папку. В результате при выполнении этого же джоба с 32-битного клиента непосредственно на сервере АОС (через драйвер версии 3.51.30) коннект к базе не происходит: [Microsoft][Диспетчер драйверов ODBC] Источник данных не найден и не указан драйвер, используемый по умолчанию Очевидно он не воспринимает строку подключения, которая отлично работает на 32-битном драйвере версии 3.51.06. При этом, если явно указать 32-битный DSN, какой-то коннект вроде происходит, но при передаче значений в resultset выдает следующее: Описание ошибки SQL: [Microsoft Dynamics AX] Unable to retrieve message for retval -1, ODBC call reason code 100, SQLSTATE = [] Error message [] На явные ошибки в тексте запроса (неверное имя поля, таблицы, команды) не реагирует. Аналогичный эффект наблюдается при выполнении кода непосредственно на 64-битном сервере АОС через 64-битный драйвер. |
|
29.08.2014, 08:33 | #3 |
Участник
|
Может действительно не стоит заморачиваться с MySQL?
Мы, если хотим получить данные из АХ для сторонних систем, используем Web-сервисы. Очень удобно и без геморроя.
__________________
// no comments |
|
29.08.2014, 18:06 | #4 |
Участник
|
Спасибо всем участникам обсуждения за дельные предложения. Получилось достучаться к БД MySQL по ODBC через .Net компоненту:
X++: static public void Main(Args _args) { System.Exception e; System.Data.Odbc.OdbcConnection objConn; System.Data.Odbc.OdbcCommand cmdSelect; System.Data.Odbc.OdbcDataReader reader; InteropPermission perm; str exceptionStr, connectStr; ; connectStr = "Driver={MySQL ODBC 3.51 Driver};Server=myserver;Database=mydatabase;User=root;Password=123;Option=3;"; try { perm = new InteropPermission(InteropKind::ClrInterop); if (perm == null) { throw error("Error with file permissions"); } perm.assert(); objConn = new System.Data.Odbc.OdbcConnection(connectStr); objConn.Open(); cmdSelect = objConn.CreateCommand(); cmdSelect.set_CommandText("SELECT * FROM table"); reader = cmdSelect.ExecuteReader(); while (reader.Read()) { info(reader.GetString(0)); } } catch(Exception::CLRError) { CodeAccessPermission::revertAssert(); perm = new InteropPermission(InteropKind::ClrInterop); if (perm == null) { return; } perm.assert(); e = ClrInterop::getLastException(); CodeAccessPermission::revertAssert(); while( e ) { exceptionStr += e.get_Message(); e = e.get_InnerException(); } info(exceptionStr); } catch { error("An Exception has occurred"); } if(objConn) objConn.Close(); } Оба драйвера версии 3.51.30 (32-битный и 64-битный) пока молчат. Будут результаты - отпишусь. |
|
10.09.2014, 11:41 | #5 |
Участник
|
С драйверами разобрались - все заработало на версии 3.51.29, удалось достучаться к базе через .Net и с 32-битного клиента, и с 64-битного сервера.
|
|
13.08.2018, 17:56 | #6 |
Участник
|
|
|
13.08.2018, 18:36 | #7 |
Banned
|
Цитата:
Сообщение от MikeR
Попробую высказать свое фэ по этому решению.
1 Не правильно держать коннекшены к другим базам данных из приложения Dynamics AX, по многим причинам (загрузка канала связи, не тот уровень исполнения, небезопасно и т.д). Скорее всего это даже не локальная инфраструктура, а через инет. И что будет в случае обрыва связи? 2 Настройка DSN привязана к конкретному AOS скорее всего. А если вы заходите с мигрировать на другой компьютер, где этой настройки нет и кто будет об это кроме разработчика помнить? Пока не запустили, мое мнение - одумайтесь и переделайте на отправку и получения пакетов в формате .xml или .csv. Атомарно. Легко переносимо. Не требует танцев с бубнами. Цитата:
То есть если можно за 2 дня обеспечить доступ к MySQL через .NET Interop из X++ и получить работающее решение то именно так и стоит сделать. И решать проблемы по мере их поступления. Web-сервисы это хорошо но дорого по стоимости разработки. Имеют смысл когда четко понятно что требуется. При этом конечно надо писать код так чтобы легко заменить этот слой логики на WS. |
|
13.08.2018, 19:19 | #8 |
Banned
|
|
|
13.08.2018, 21:03 | #9 |
Banned
|
Одно дело когда это заказ и консалтинг заинтересован сделать проект более дорогим прикрываясь непобиваемой правильностью веб-сервисов.
И совсем другое когда это внутренний проект где в интранете и AX и PHP приложение. Тут принцип KISS имеет все основания быть примененным. Или прототипирование для сбора дальнейших требований. Где о правильности вообще надо забывать. |
|
14.08.2018, 08:26 | #10 |
Участник
|
Цитата:
А когда нечетко понятно, что требуется, то х**к, х**к и в продакшн?
__________________
// no comments |
|
14.08.2018, 14:35 | #11 |
Banned
|
Цитата:
Использование веб-сервисов это не просто удаленный вызов, это уже интеграция двух систем. Работа с двух сторон, документация, согласования, координация действий, тестирование и настройки. Двадцать дней. х**к, х**к он безотносителен к способу. Веб-сервисы как универсальный способ это неправильно. |
|
15.08.2018, 07:31 | #12 |
Участник
|
Цитата:
Сообщение от ax_mct
Доступ к сторонней базе остается программированием в AX и делом одного человека. Пусть даже и через NET прокси. Два дня.
Использование веб-сервисов это не просто удаленный вызов, это уже интеграция двух систем. Работа с двух сторон, документация, согласования, координация действий, тестирование и настройки. Двадцать дней. х**к, х**к он безотносителен к способу. Веб-сервисы как универсальный способ это неправильно. Дешевле - в том смысле, что вы все равно к этому придете позже. Даже просто работая с чужой базой вы будете задавать вопросы коллеге, который работает в ней постоянно. Документация и так будет вестись, согласитесь. Координация действий, тестирование - все это время будете отвлекать коллегу. Быстрее - как ни странно, но вдвоем работа идет быстрее. Парадокс общения во время работы. Когда ты один, можешь долго тупить над вполне простыми вещами. Когда ты ведешь рабочий диалог - мысли сами выстраиваются в нужном направлении. Скорость разработки повышается. Однако, если долго мучить коллегу, то наверное тоже работа будет быстро сделана. Правильнее - вам не нужно будет добавлять поля типа флага Processed, чтобы фильтровать обработанные записи, не нужно запускать батч каждые 10 минут. Как только данные поступят, веб-сервис их обработает.
__________________
// no comments |
|
|
|