Devart Forum

Подскажите пожалуйста, в хранимке возникает ошибка, SSMS ловит ошибку типа

Msg 50000, Level 16, State 1, Procedure TestMessages, Line 20 [Batch Start Line 0]
Реальная ошибка

В дельфи я ловлю только сообщение "Реальная ошибка"
Как я могу поймать текст детализирующий место возникновения ошибки?

В принципе я просто написал наследника на TMSQuery :)

Плотно работаю с табличными параметрами и столкнулся с одной весьма неудобной вещью.

Создается объект TMSTableData, прописываем тип на сервере, открываем заполняем.
Затем присваиваем ParamByName('xxx').asTable:= TMSTableData.Table
Затем все открываем и все замечательно работает, НО, если перед открытием запроса объект TMSTableData будет например
удален, то запрос не выполнится и получим ошибку. Тут как бы все логично, идет ссылка на уже несуществующий в памяти объект.
Но в случае когда мы динамически работаем с запросами использующими табличные параметры приходится городить связи между самим TMSQuery и всеми табличными объектами тоже созданными в рантайме.
Т.е хочется какой-то метод который загрузит данные из TMSTableData в табличный параметр после чего может быть безопасно убит, а запрос будет преспокойно открываться и работать. В идеале вообще чтобы TMSTableData был встроен в TMSParam и не требовалось городить связки объектов.

При попытке установить триальную версию в Лазаря, получаю сообщение об ошибке. Отсутствует файл MsCompactConnectionEditor.lfm
Ну и соответственно установка не удалась. Я что-то неверно делаю или пакет для Лазаря неполный?
Lazarus 1.6.4, FPC 3.0.2, SDAC последняя триальная версия с сайта

Добрый день, спасибо за оперативный ответ. Думаю это стоит добавить куда-то в документацию или FAQ, так как в том же SSMS результат без TYPE точно также просматривается как xml. SDAC же требует четкого возврата типа xml для того чтобы поле датасета создалось TMSXMLField, а не TBlobField.

PS: кстати я решил данную проблему через присвоение результата генерации xml типу varchar(MAX) и возврату уже этого типа. Может кому пригодится. Ну и для общего развития, если TYPE не указан, то результат возвращается в виде nvarchar(MAХ).

Или я чего-то не понимаю или лыжи совсем не катят.
На форме лежит TMSSQLConnection, установлено соединение с сервером.
Параметры соединения и клиента:
Microsoft SQL Server 12.00.5000
Microsoft SQL Server Native Client 11.0: 11.0.2100.60
В TMSQuery делаю запрос вида SELECT * FROM xxx FOR XML PATH, в SSMS результат отлично виден в виде XML.
В дизайне смотрю поле получилось типа TBlobField. Пытаюсь считать значение следующим образом
s:= TMSXMLField(qXML.Fields[0]).XML и в итоге в переменной s я не вижу нормального xml значения.
Что я делаю не так? Delphi XE7 и SDAC 7.3.13

Андрей, спасибо за ответ и рад что проблема исправлена.
Подскажите пожалуйста, последнее время я заметил что возник ряд вопросов о качестве продукта, причем ошибки не маленькие, а достаточно критичные. Медленная загрузка в лоадере, проблема с округлением, сейчас вот вообще банальная ошибка коннекта. Т.е качество тестирования релизов явно имеет какие-то проблемы. С чем связаны все эти проблемы?

Новое приложение, кидаем на форму TMSConnection, вызываем визард настройки соединения, вбиваем данные для коннекта и получаем ошибку на соединении.
Прикладываю 2 скрина, первый это ошибка при нажатии кнопки коннект и второй это ошибка при переключении в закладку info.
Исходные данные: Delphi XE7 c апдейтом, никаких других компонентов не установлено.

Будет ли решение этой проблемы?

Но в выше опубликованном примере от 10 мая 2013, написанном Вами, никакой ручной установки типов параметров нет, и при этом пример замечательно работал тогда, я проверял сразу после Вашего ответа.

Вы правы, при создании поля как widestring проблема уходит

XE7 и версия TVirtualTable 9.x

Создаем датасет, добавляем одно текстовое поле, вызываем штатный редактор датасета TVirtialTable, пытаемся занести значение "АБВГД", при посте значение меняется на "?????"

Ну точно не скажу, но судя по дате сообщения версия unidac доступная 10 мая 2013 года. В вышеприведенном примере кстати тоже ничего не упоминается о ручной установке out параметров, т.е на момент написания примера out параметры в тексте запроса работали без ручной настройки.
Да и тогда вообще непонятно зачем в запросе параметры помечать как out если перед запуском мы их все равно правим руками.

А это нормальное поведение или баг? Просто раньше необходимости в ручной установке типа параметра небыло необходимости. Парсер сам брал SQL запрос и параметры out делал как ptOutput.
Т.е будет ли это поправлено или это теперь нормальное поведение компонента и ничего не изменится?

В версии 6.0.1 пример на OUT параметрах от AndreyZ не работает. На debug видно что не смотря что в тексте sql запроса на insert параметры заданы как out, в списке параметров передаваемых на сервер они заданы как in и соответственно возвращенные с сервера знаения не обрабатываются и не появляются в датасете.
В чем может быть дело?