Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3   вперед  Ctrl      все
 Re: Оптимальность методов загрузки XML в MSSQL  [new]
NIIIK
Member

Откуда: Россия, Ростовская область, г. Таганрог
Сообщений: 1295
Для тех колонок что должны быть НЕ нуловые но имееют констрейнты getutcdate(), newsequentialid(), тупо 0
Я пока вижу только методы
1) Триггер
2) На уровне процедуры
2.1) Update-операторы
2.2) alter table ...

Причём для NULL-овых колонок, но у которых висит default constraint когда я пытаюсь изменить на "not null" всё равно выскакивает ошибка и этот констрейнт для существующих колонок не срабатывает.
Для функции newsequentialid() полный головняк - прийдётся иметь дополнительную колоку что бы сохранять и старые значения (её можно использовать только как default)

Идентификаторы "вставленных завписей" я могу только определять только если один поток (банальной выборкой последней или "до и после").
16 июн 12, 00:07    [12723660]     Ответить | Цитировать Сообщить модератору
 Re: Оптимальность методов загрузки XML в MSSQL  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6724
NIIIK
Но почему-то перестают работать default constrain -ы
Ну коль CheckConstraints не распространяются на Default, то таково решение M$.
Но меня смущает другое:
http://msdn.microsoft.com/en-us/library/ms171769.aspx
KeepNulls
Specifies what value to use for a column that is missing a corresponding attribute or child element in the XML document. This is a Boolean property. When the property is set to TRUE, XML Bulk Load assigns a null value to the column. It does not assign the column's default value, if any, as set on the server. The value of this property applies to all columns involved in the bulk load.

The default value is FALSE.
Ничего дополнительного к вашим вариантам особо больше и не придумаешь. Кроме того чтобы попросить M$ этот функционал добавить. Но скорее и оно вас направит к вашим же решениям.
NIIIK
Последний параметр - это какой-то важный параметр в какой-то новой версии или можно "забить" ?!
Это параметризованный KeepIdentity.
NIIIK
Как-нибудь возможно вернуть то что вставно (идентификаторы) вроде как insert into ... output
О боже. Вы зажрались :) XmlBulkLoad это программный доступ, тут нет скуля.
Моя процедура это SQL доступ через OLE к данному функционалу.
NIIIK
Есть ли метод, напримре, при каждой загрузке создавать запись в табилце фактов загрузки, получать идентификатор и потом этот идентификатор передавать внуть этого XMLBulkLoad, что бы корневой тэг (тэги) ссылались на него и мы бы всегда знали с какого из файлов загружены данные?
Ну вы же можете корневой тег (аля ROOT) для этого и использовать, ссылается на нужную таблу у которой Identity, и прописать на него релейшеншипы.

У вас вопросы какие-то неправильные - в них уже содержится полный ответ. =)
16 июн 12, 05:15    [12723946]     Ответить | Цитировать Сообщить модератору
 Re: Оптимальность методов загрузки XML в MSSQL  [new]
Kairat V. Beysenov
Member

Откуда: Astana City
Сообщений: 21
Mnior, у меня есть такой код на C# (с подключенной COM библиотекой Interop.SQLXMLBULKLOADLib):

public void Insert(string xml, string xsd) {
	SQLXMLBULKLOADLib.SQLXMLBulkLoad4Class objBl = new SQLXMLBULKLOADLib.SQLXMLBulkLoad4Class();
	objBl.ConnectionString = "Provider=sqloledb;server=localhost;database=dbXml;integrated security=SSPI";
	objBl.KeepIdentity = false;
	objBl.Execute(@"D:\Temp\Schema.xsd", @"D:\Temp\Data.xml");
}


Возможно ли методу Execute передавать поток данных, а не путь к файлам?
Хml в моем случае приходят из IBM MQ (~10 xml в секунду, каждая xml весит ~ 25КБ)
1 ноя 12, 17:02    [13410260]     Ответить | Цитировать Сообщить модератору
 Re: Оптимальность методов загрузки XML в MSSQL  [new]
skorpk
Member

Откуда: Волгоград
Сообщений: 276
Kairat V. Beysenov,
Можно
1 ноя 12, 20:25    [13411031]     Ответить | Цитировать Сообщить модератору
 Re: Оптимальность методов загрузки XML в MSSQL  [new]
skorpk
Member

Откуда: Волгоград
Сообщений: 276
Kairat V. Beysenov,если надо в с помощью .NET

Managed XML Bulk load does not work with managed streams and requires a wrapper around native streams.
Using XML BulkLoading with .Net Streams
1 ноя 12, 20:32    [13411047]     Ответить | Цитировать Сообщить модератору
 Re: Оптимальность методов загрузки XML в MSSQL  [new]
Kairat V. Beysenov
Member

Откуда: Astana City
Сообщений: 21
skorpk,

Спасибо! Сегодня сто раз натыкался на эту статью и не внимательно прочитал концовку, где как раз описывается как XML передавать поток вместо, файла. Жалко что схема должна быть в виде файла. Хотя их не много - пусть лежат на сервере рядом с сиквелом.
А вообще само решение выше озвученной мной задачи имеет право на жизнь?
Еще читал что пользуются XDR схемами вместо XSD, но я так понимаю принципиальной разницы нет? Разве что XSD схему можно использовать дополнительно для проверки XML. Верно?
1 ноя 12, 20:45    [13411079]     Ответить | Цитировать Сообщить модератору
 Re: Оптимальность методов загрузки XML в MSSQL  [new]
Kairat V. Beysenov
Member

Откуда: Astana City
Сообщений: 21
skorpk,

За это вообще мега-респект!
Буду завтра пробовать на работе.
1 ноя 12, 20:54    [13411094]     Ответить | Цитировать Сообщить модератору
 Re: Оптимальность методов загрузки XML в MSSQL  [new]
Borsugg
Member

Откуда:
Сообщений: 20
Доброго времени суток.

Mnior, решил попробовать использовать вашу процедуру, уж больно красиво написана =) (За процедуру вам отдельная благодарность и безмерное уважение)
С простыми схемами\xml-документами работает на ура! Но вот при использовании на больших, сложных xml-схемах возникает следующая ошибка:
Msg 50000, Level 18, State 1, Procedure spXMLBulkLoad, Line 50
Ошибка при выполнении метода "Execute" в "C:\tmp\XMLBulkError.xml": Schema: multiple base for a derived type on unit is not supported.


Есть ли какие-либо пути решения? Если понадобится, приведу xml-схему. Спасибо!
26 ноя 12, 08:25    [13527435]     Ответить | Цитировать Сообщить модератору
 Re: Оптимальность методов загрузки XML в MSSQL  [new]
MSDN Library
Guest
Требования и ограничения для коллекций XML-схем на сервере
26 ноя 12, 10:32    [13527828]     Ответить | Цитировать Сообщить модератору
 Re: Оптимальность методов загрузки XML в MSSQL  [new]
NIIIK
Member

Откуда: Россия, Ростовская область, г. Таганрог
Сообщений: 1295
Никто не в курсе есть ли вариант сейчас как-то решить проблему значений по умолчанию не кривыми методами?
Понятно что "пересоздавать колонку с newsequentialid() not null-овую паралельно с обычными int-выми ключами (сохраняя старые значения в отдельной колонки) вполне можно.

Хотелось бы "более умный метод".
19 мар 13, 13:25    [14066995]     Ответить | Цитировать Сообщить модератору
 Re: Оптимальность методов загрузки XML в MSSQL  [new]
NIIIK
Member

Откуда: Россия, Ростовская область, г. Таганрог
Сообщений: 1295
очередной раз вернулся к задаче загрузке данных в МсСКЛ, правда ещё предстоит нормализовывать загруженные занные.

Но проблемы
1) дефолтных значений
2) педелачи дополнительных параметров

более актуальная сейчас.

Для примера, возьмём "передача имени файла с которого грузятся данные + дата начала загрузки + какой-то внешний ключ".

Как правильно это орагнизовывать? В целом можно третьими методами "заведомо положить их в ХМЛ" (хотя не уврен на счёт даты загрузки).

Если ограничится тем что "всегда загружает только один поток" всегда можно найти "последнюю запись по атрибуту с нуловым значением" (потом его проапдейтить).

Если ХМЛ может грузится в несколько потоков - как это делать?
19 мар 13, 17:20    [14068802]     Ответить | Цитировать Сообщить модератору
 Re: Оптимальность методов загрузки XML в MSSQL  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6724
Согласно документации MS Правила и ограничения массовой загрузки XML (SQLXML 4.0) следует что default параметр должен работать.
Так что вы можете продублировать (да, да, неудобно) в XSD файле значения по умолчанию.

Если вы на счёт прописывания идентификатора закачки в саму таблицу сразу же при самой заливке данных, то можно воспользоваться тем же методом. Создавая для каждой загрузки свой XSD. Ну а чё делать?! Да и в принципе логично.

Если вы в Default constraint записываете идентификатор закачиваемого файла - то это не гуд решение само по себе. Источник данных должен говорить о себе, а не метаданные таблицы.

PS: Если вы попробуете это и если не трудно, то отпишитесь о результатах.
27 мар 13, 19:09    [14103878]     Ответить | Цитировать Сообщить модератору
 Re: Оптимальность методов загрузки XML в MSSQL  [new]
NIIIK
Member

Откуда: Россия, Ростовская область, г. Таганрог
Сообщений: 1295
Врят ли к этой задаче вернутся дадут в близжайшее время ("пока работает").
Но там целая иерархия таблиц. Хотел сразу использовать PK и FK в виде uniqueidentifier которые задавались default newsequentialid() и
даты загрузке (sysdatetimeoffset()), имя загружаемого файла и некоторые статусы которые меняются только в процессе обработки данных но по идее имеют дефолтное значение и их можно было бы сделать not null default (функция получения дефолтного значения).

В итогде загрузил через indetity(1,1) и потом дополнительные поля и "мануальная установка значений".
27 мар 13, 19:16    [14103909]     Ответить | Цитировать Сообщить модератору
 Re: Оптимальность методов загрузки XML в MSSQL  [new]
NIIIK
Member

Откуда: Россия, Ростовская область, г. Таганрог
Сообщений: 1295
что самое плохое в моём решение - будет грудится в один поток, котоу что добавленную запись я нахожу как select max() и ещё сделал "синхранизацию" черех ## таблицы, что бы второй поток не запустили.
27 мар 13, 19:37    [14104000]     Ответить | Цитировать Сообщить модератору
 Re: Оптимальность методов загрузки XML в MSSQL  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6724
NIIIK
имя загружаемого файла
Константа, закладывается в XSD.
NIIIK
даты загрузке (sysdatetimeoffset())
Оно одно для всего загружаемого файла - т.е. константа
1) если рядом с именем файла, также закладывается в XSD
2) если в строках данных - бить по рукам за плохую структуру базы
NIIIK
uniqueidentifier - newsequentialid()
sic! Об функциях я и не подумал.

Что-то у меня вспоминается случай, что нужно просто указывать не имя таблицы, а имя вью, в которой перечислены только нужные колонки (без дефолтных). Но кажись это не для XmlBulkLoad, а обычного BULK INSERT (BCP). Не помню.

В случае GUID надо прописывать у колонки свойство ROWGUIDCOL. Хотя врятли это как Identity прокатит (но по смыслу оно и есть). Т.е. можно завести на connect просьбу, им тяжело будет отмазаться (и скорее напишут - "in next release").

Ну и вообще наверно в большинстве случаев (внешних данных, 95%) данные грузятся всегда в промежуточные таблы, а потом переливаются в нужную родную структуру. Это я даже не говорю про всякие партишины, которые частенько применяются в таких задачах.
28 мар 13, 23:31    [14110363]     Ответить | Цитировать Сообщить модератору
 Re: Оптимальность методов загрузки XML в MSSQL  [new]
NIIIK
Member

Откуда: Россия, Ростовская область, г. Таганрог
Сообщений: 1295
Mnior
Константа, закладывается в XSD.

С этим максимум разберусь, хотя конечно удобнее было бы "как обычно" и не менять в XSD, если что-то меняется в логике.
Хотя пока "не использовал" (от лени и малой необходиомости)

Mnior
даты загрузке (sysdatetimeoffset())
Оно одно для всего загружаемого файла - т.е. константа
1) если рядом с именем файла, также закладывается в XSD
2) если в строках данных - бить по рукам за плохую структуру базы
[/quot]

Тут ответ не понял, но смысл в том что файлы "уже лежат" хочу сохранять именно момент загрузки (Сейчас делаю "потом апдейт").
Так же хочу имя самого файла (Путь к нему и т. п.), но внутри ХМЛника его нет.

Mnior
Что-то у меня вспоминается случай, что нужно просто указывать не имя таблицы, а имя вью, в которой перечислены только нужные колонки (без дефолтных). Но кажись это не для XmlBulkLoad, а обычного BULK INSERT (BCP). Не помню.

Будет возврат к задаче или возможность - попробуй протестить, но сомневаюсь, ХМЛБалкЛоад связанные данные загружает и указывать надо ПК, ФК (хотя если задача "просто рядом сгенерить" - может прокатит и это лучше чем я гоняю через временные таблицы, что бы потом искользовать "последовательные гуиды" и при вставке и т. д.)

Mnior
В случае GUID надо прописывать у колонки свойство ROWGUIDCOL. Хотя врятли это как Identity прокатит (но по смыслу оно и есть).

Вот почему у меня это в привычку не вошло :(

Mnior
Т.е. можно завести на connect просьбу, им тяжело будет отмазаться (и скорее напишут - "in next release").

Не шарящий...
Где-то попросить мелкомягких сделать фишку? А ссылку можно :) (простите за лень на ночь глядя) :)

Mnior
Ну и вообще наверно в большинстве случаев (внешних данных, 95%) данные грузятся всегда в промежуточные таблы, а потом переливаются в нужную родную структуру. Это я даже не говорю про всякие партишины, которые частенько применяются в таких задачах.

Да, я испольщую как "промежуточные", но "подготавливаю" данные уже там и потом использую готовый идентификаторы. С другой стороны эти стейджинговые данные тоже "не сразу удаляются" (пока даже не удаляются пока отладка).
Хотя в том же проекте на другой задаче может вполне "ровный и готовый ХМЛник прийти". Т. е. "бери и заливай".
29 мар 13, 00:26    [14110488]     Ответить | Цитировать Сообщить модератору
 Re: Оптимальность методов загрузки XML в MSSQL  [new]
Гость333
Member

Откуда:
Сообщений: 3683
NIIIK
Где-то попросить мелкомягких сделать фишку? А ссылку можно :)

connect.microsoft.com
29 мар 13, 09:41    [14111083]     Ответить | Цитировать Сообщить модератору
 Re: Оптимальность методов загрузки XML в MSSQL  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6724
NIIIK
Так же хочу имя самого файла (Путь к нему и т. п.), но внутри ХМЛника его нет.
Опять же в XSD.
Т.е. для каждой загрузки свой XSD (временный) со всеми дополнительными данными: Путь/имя файла, дата загрузки и другие заранее просчитанные константы для данной заливки.
NIIIK
смысл в том что файлы "уже лежат" хочу сохранять именно момент загрузки (Сейчас делаю "потом апдейт").
А смысл? Не отходите от смысла задачи. Не надо вот эту бессмысленную педантичность. Дата загрузки - это такое аморфная весчь, ибо она долго длится во времени. Тут ставить что-то точнее чем SmallDateTime бессмысленно.
Не важно от чего вы будете отсчитывать - от прихода файла в каталог загрузки или после попадания в результирующие таблы. Главное чтобы было унифицировано и последовательно (для всех закачек).

NIIIK
ХМЛБалкЛоад связанные данные загружает и указывать надо ПК, ФК
Это надо для связей XML данных и порядка вставки.
Но я не буду спорить, я не помню в каком случае это прокатило.

NIIIK
Да, я испольщую как "промежуточные"
Ну дык лучше не парится.
NIIIK
С другой стороны эти стейджинговые данные тоже "не сразу удаляются" (пока даже не удаляются пока отладка).
Смысла не вижу (разве что кроме тестов). Нужны логические данные, удобно структурированные. А физические, они пусть в файлах и лежат.
29 мар 13, 12:33    [14112149]     Ответить | Цитировать Сообщить модератору
 Re: Оптимальность методов загрузки XML в MSSQL  [new]
NIIIK
Member

Откуда: Россия, Ростовская область, г. Таганрог
Сообщений: 1295
Mnior,

Там есть так называем "скраппер" (внешний сервис), который работает довольно автономно и предполагается что будет вызывать мою процеудуру.
Врят ли он будет формировать ХСД. За временем хочется следить "хотя бы ради логов".

Стейджинговые данные "не сразу удаляются" что бы если возникнет какая-то ошибка её отдебагить, отловить и "не потерять данные". Там если честно "головняк видеть надо". Задача внятно не поставлена, "загружать данные и всё тут".

Я ещё планировал выделять сущности. Но то что там справочные значения - легко переделал на ссылки (лошадинные скачки, стадионы, имена лошадей и т.д.), но явно там "кривые данные" (повторяющихся много), при том что ХМЛник имеет несколько уровней в иерархии.

Ладно бы там была денормализация в виде "Список заказов"
И была бы сущность "заказ", которая на самом деле "заказ", "клиент", "человек" (не каждый человек в системе клиент), "паспортные данные" (человек может менять ФИО, но при этом оставаться тем же человеком и клиентом), "ссылка на товар", "элементы заказа" (в одном заказе может быть несколько товаров). Т. е. там мне было очевидно бы.

Тут же никто не говорит что это за данные, я возможности выяснить не имею, вопросы "уходят в бездну". Уже чувствую что туда "если надо будет запустить - надо будет возвращаться". На уровне стейджинговых данных целая логика уже. Вот пока и не удаляю.

А "разаработчики фротэнда советуют" пихать данные вообще "как есть незадумываясь" :)
При том что только один ХМЛник весит под 30 метров и после загрузки в таблицах нижнего уровня появляется по 30+ тысяч записей. (т. е. прямым текстом говорят что потом надо получать анало "списка клиентов" запросами в духе select distinct firstName, lastName from Orders). Тут и здоровый ...

Вот что реально жалко - вопросы нормализации не смогу решить на уровне XMLBulkLoad. Это по сути "быстрая заливка того что есть". Хотелось сделать "максимум" на этой операции. Всё равно на уровне обработки данных много запросов "нормализующих" уже. И даже в стейджинговых таблицах я сохраняю те связи что нашёл в справочниках и только когда установил все FK - я обычными insert ... select ... закидываю данные в нормальную (в том числе и более нормализованную базу). А грохать данные со стейджинговой (в которой по сути куча логики "как они получились") пока не хочу.
29 мар 13, 13:09    [14112441]     Ответить | Цитировать Сообщить модератору
 Re: Оптимальность методов загрузки XML в MSSQL  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6724
NIIIK
будет вызывать мою процеудуру
У вас все карты на руках. :)
Пусть ваша процедура и создаёт/меняет XSD, сохраняет файлы (а не хранит копии в таблах - "стейджинговые данные") и т.п.
Лучше на этих копиях логику не завязывать (а вдруг что-то поменяется ...). А всё в кучу смешивать - под себя копать. Мухи отдельно, котлеты отдельно.

Но вообще я не навязываю, это ваше дело, какова архитектура решения.

Ваш пост навеял: http://dilbertru.blogspot.com/2007/10/20071026.html :)
В 90% IT потеряла свою цель, теперь это вещь в себе. Очень мало людей которые могут/хотят обзорно думать.
30 мар 13, 16:24    [14116392]     Ответить | Цитировать Сообщить модератору
 Re: Оптимальность методов загрузки XML в MSSQL  [new]
NIIIK
Member

Откуда: Россия, Ростовская область, г. Таганрог
Сообщений: 1295
Идиотская какая-то ошибка

началась с того что передали не правильный путь к файлу.
Ну не правильный так не правильный
тоьлко Messages выглядили так

Messages
(1 row(s) affected)

(1 row(s) affected)

(1 row(s) affected)

(1 row(s) affected)

(1 row(s) affected)

(1 row(s) affected)

(29 row(s) affected)

(29 row(s) affected)

(3480 row(s) affected)

(3480 row(s) affected)

(31320 row(s) affected)

(31320 row(s) affected)

(31320 row(s) affected)

(31320 row(s) affected)

(0 row(s) affected)

(0 row(s) affected)

(0 row(s) affected)

(0 row(s) affected)

(0 row(s) affected)

(0 row(s) affected)

(0 row(s) affected)

(0 row(s) affected)

(0 row(s) affected)

(0 row(s) affected)

(0 row(s) affected)

(0 row(s) affected)

(0 row(s) affected)

(0 row(s) affected)

(0 row(s) affected)

(0 row(s) affected)

(0 row(s) affected)

(0 row(s) affected)

(0 row(s) affected)

(0 row(s) affected)

(0 row(s) affected)

(0 row(s) affected)

(0 row(s) affected)

(0 row(s) affected)

(0 row(s) affected)

(0 row(s) affected)

(0 row(s) affected)

(0 row(s) affected)

(0 row(s) affected)

(0 row(s) affected)

(0 row(s) affected)

(0 row(s) affected)

(0 row(s) affected)

(0 row(s) affected)

(0 row(s) affected)

(0 row(s) affected)

(0 row(s) affected)

(0 row(s) affected)

(1 row(s) affected)

(29 row(s) affected)

(3480 row(s) affected)

(31320 row(s) affected)

(31320 row(s) affected)
Msg 50000, Level 18, State 1, Procedure spXMLBulkLoad, Line 61
Ошибка при выполнении метода "Execute" в "Microsoft XML Bulkload for SQL Server": The error log file could not be created. Make sure you have the appropriate permissions and that the ErrorLogFilePath is valid.


Только вопрос в том, что начинается загрузка ХМЛ в самом начале процедуры, а дальше идёт "раскидывание по таблицам и нормалзизация".

Я уже начал пытаться вернуть код ошибки или ещё что-нить с процедуры dbo.[spXMLBulkLoad]
но даже если я писал (один из вариантов)

 exec @spXMLBulkLoad = dbo.[spXMLBulkLoad] 
 	 @@File = @fileName,
	 @@Schema = @xsdSchemaName,
	 @@DataBase	= @dbName;
 
 select @spXMLBulkLoad;
 select 123;


Ничего не выбиралось, но каунты все я видел.

Потом я написал просто фейковый Select перед вызовом. Все прблемы как ветром сдуло. Просто обычный select 123;

Пока оставил в таком виде код.

 declare @spXMLBulkLoad int;

 select 'XML loading started' as action;

 exec @spXMLBulkLoad = dbo.[spXMLBulkLoad] 
 --'D:\Nikita\xml\test_04.xml', 
 	 @@File = @fileName,
	 @@Schema = @xsdSchemaName,
	 @@DataBase	= @dbName;
 
 if coalesce(@spXMLBulkLoad, -1) <> 0
 begin
  --for double sure
  return;
 end;
 select 'XML loading finished' as action;


не прверка на в if не нужна, до неё не доходит если ошибка


Тут у меня "не страшно", но в другом месте, когда я так же буду брать "последнюю добавленную в единственном потоке запись

 select @pkTable = max(pk) 
   from shecmaName.tXmlDataTable ms;


то там всегда будет "предыдущая запись", а передавать индетификатор в процедуру который есть в ХМЛ данных как корень (и что бы много потоков работало) необходимо менять на приложении.
18 апр 13, 13:08    [14198146]     Ответить | Цитировать Сообщить модератору
 Re: Оптимальность методов загрузки XML в MSSQL  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6724
NIIIK
The error log file could not be created. Make sure you have the appropriate permissions and that the ErrorLogFilePath is valid.
Ну, тут ошибка не в неправильном файле XML или XSD, а то что в процедуре вы не прописали правильный путь для файла лога (в двух местах). Из этого лога потом можно читать сообщения об ошибках. Это базовые требования.

NIIIK
Ничего не выбиралось, но каунты все я видел.
Тёмные силы электричества.
Не, ну никак не может быть, только запросы запущенные до или после вызова процедуры.
Кстати, сообщения об ошибках не обязательно идут в том же порядке что и каунтеры. В скуле на самое деле обработка ошибок идёт через несколько костылей (OLE, CLR и все-все-все).

NIIIK
if coalesce(@spXMLBulkLoad, -1) <> 0
Контролировать ошибки обязательно.
И не обязательно через IF. Я работаю через TRY/CATCH (кроме старых процедур типа OleAutomation), там поэтому и стоит RAISERROR (старый подход на новый переносится).
И не нужно делать Coalesce, код результата всегда существует.

Ошибки сами по себе не прерывают процесс (не всегда). Чтобы код прервался надо или писать проверки (IF, по старому) и писать SET XAct_Abort ON и т.п., или заворачивать в TRY/CATCH (по новому).
Это базовые понятия.
18 апр 13, 19:28    [14200397]     Ответить | Цитировать Сообщить модератору
 Re: Оптимальность методов загрузки XML в MSSQL  [new]
NIIIK
Member

Откуда: Россия, Ростовская область, г. Таганрог
Сообщений: 1295
Ошибка изначально была изначально из-за отсутствия ХМЛ, этот путь "на другом сервере", а процедура сделана так что бы файл с ошибкой создавать по имени файла с данными (+Д-СКЛ)

Mnior
Тёмные силы электричества.
Не, ну никак не может быть, только запросы запущенные до или после вызова процедуры.

"Мля буду". Сам сидел в шоке. Но факт что эти запросы "выполнялись".
Просто сложно продемонстировать.

По поводу того "костыля" не сильно заморачивайтесь. Это автопилотом написано и "есть привычка" обарабтывать нулл. Там и его не должно быть, там довольно большой TRY/CATCH уже есть.
18 апр 13, 21:21    [14200683]     Ответить | Цитировать Сообщить модератору
 Re: Оптимальность методов загрузки XML в MSSQL  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6724
NIIIK
"Мля буду". Сам сидел в шоке. Но факт что эти запросы "выполнялись".
Просто сложно продемонстировать.
Главное, чтобы оно больше не повторялост и не воспроизводилось.

Но если вы на баг нарвались, поковыряться очень интересно.
19 апр 13, 12:54    [14203247]     Ответить | Цитировать Сообщить модератору
Между сообщениями интервал более 1 года.
 Re: Оптимальность методов загрузки XML в MSSQL  [new]
Если
Member

Откуда:
Сообщений: 58
День добрый!
Постил вопрос, но что-то не найду его, может удалили?

Вопрос такой, запускаю:
EXEC dbo.spXmlBulkLoad 'C:\Temp\Обрез.xml', 'C:\Temp\b.xsd',тест

Выдает
(строк обработано: 1)
Сообщение 50000, уровень 18, состояние 1, процедура spXMLBulkLoad, строка 47
Ошибка при выполнении метода "Execute" в "c:\Temp\XMLBulkError.xml": Schema: unable to load schema 'b.xsd'. An error occurred (Невозможно переключиться в данную кодировку.) at line 1 column 39. 


В чем может быть дело?
Кодировка b.xsd стоит UTF-8(без BOM), пробовал конвертнуть в ANSII - тоже самое.

Искал на форуме так и не нашел подобного вопроса.

P.S. Win8 64bit, MS SQL 2008 R2

Заранее спасибо!
7 авг 15, 15:52    [17989899]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить