//_____________________________________________________________________________
//
Процедура Сформировать()
	Перем BinData;
	Перем стрФайл; // C:\somewhere\file1.ept
	Перем стрЗапрос;
	Перем rs;

	BinData = СоздатьОбъект("BinaryData");
	Попытка
		BinData.ПодключитьсяКФайлу(стрФайл, 1, 1);
	Исключение
		Сообщить("Не удалось подключиться к файлу " + стрФайл, "!");
		Возврат;
	КонецПопытки;

	rs = СоздатьОбъект("ODBCRecordSet");

	стрЗапрос = "IF OBJECT_ID(N'tempdb.dbo.#TempTblForSample') IS NOT NULL DROP TABLE #TempTblForSample";
	Если rs.Выполнить(стрЗапрос) = 0 Тогда
		Сообщить("Не удалось выполнить запрос!" + РазделительСтрок + "---> описание ошибки: " + rs.ПолучитьОписаниеОшибки(), "!");
		Возврат;
	КонецЕсли;

	стрЗапрос = "
	|CREATE TABLE #TempTblForSample (
	|	ROW_ID int IDENTITY(1, 1) NOT NULL,
	|	FNAME varchar(255) NOT NULL,
	|	FIMAGE image NULL
	|)";

	Если rs.Выполнить(стрЗапрос) = 0 Тогда
		Сообщить("Не удалось выполнить запрос!" + РазделительСтрок + "---> описание ошибки: " + rs.ПолучитьОписаниеОшибки(), "!");
		Возврат;
	КонецЕсли;

	стрЗапрос = "INSERT INTO #TempTblForSample (FNAME, FIMAGE) VALUES (?, ?)";

	Если rs.Подготовить(стрЗапрос) = 0 Тогда
		Сообщить("Не удалось подготовить запрос!" + РазделительСтрок + "---> описание ошибки: " + rs.ПолучитьОписаниеОшибки(), "!");
		Возврат;
	КонецЕсли;

	rs.ДобПараметр(1, 15, 255, 0); // FNAME
	rs.ДобПараметр(1, 19, 0, 0); // FIMAGE

	rs.УстПараметр(1, стрФайл);
	rs.УстПараметр(2, BinData);

	Если rs.Выполнить() = 0 Тогда
		Сообщить("Не удалось выполнить запрос!" + РазделительСтрок + "---> описание ошибки: " + rs.ПолучитьОписаниеОшибки(), "!");
		Возврат;
	КонецЕсли;
КонецПроцедуры // Сформировать()
 

По моему меня не так поняли???!! Я хотел спросить, можно ли использовать объект "BinaryData" вместо компоненты BinFiles. Я хочу хранить файлы в в длинных строках базы 1С. Вышеприведенный кусок кода этого явно не поясняет!

P.S. База у меня КОНЕЧНО не SQL! В Скулевских базах у меня свой механизм и такой проблемы не стоит!

vandalsvq писал(а) 29. Апреля 2008 :: 15:27:


Да нет, не тот случай! Конфа не слишком объемистая! Может лучше чего скажешь по моему вопросу????

P.S. Странно! Неужели никто не может прояснить ситуацию??

Хотя, наверное, можно использовать BinaryData для побайтового (или по 2 или 4 байта) методами ПрочитатьДанные/ЗаписатьДанные. Но, ИМХО, это будет слишком медленно.

ZOOBR писал(а) 29. Апреля 2008 :: 19:52:

По видимому, не может. Впрочем BinFiles, ИМХО, тоже не слишком удачный вариант для реализации хранения бинарных файлов в 1С. Сложноватый алгоритм и, скорее всего, не самый быстрый. Но по сравнению с использованием BinaryData будет летать. Потому что читает бОльшими порциями, да и числа, полученные из BinaryData, нужно как-то еще, дополнительно, обрабатывать.

kms писал(а) 30. Апреля 2008 :: 13:09:

Ага, блин. Дофига как удачный алгоритм. Сначала радостно превращаем строку в hex-коды, а потом радостно жмем ее архиватором. Сначала насоздавали себе трудностей, а потом бодро их преодолеваем.

Вот ЗАЧЕМ нужно сначала вытягивание hex-строки из ВК, а потом впендюривание ее обратно? А? А если еще учесть, что ВК сделана не по типу Rainbow, а по штатной технологии, то в этих перекидываниях строк туды-сюды , как пить дать, есть пара преобразований в юникод и обратно. Фактически через ВК прокачивается объем данных больше чем В ВОСЕМЬ раз превышающий размер исходного объема файла. До хрена как удачный алгоритм. Да-да. Трындец просто.

Правильная ВК должна предоставлять три простых метода:
1) ОткрытьФайл (чтение или запись)
2) ПрочитатьUUEДанные (длина). длина должна быть такова, чтобы получить целое количество закодированных байтов
3) ЗаписатьUUEДанные (СтрокаUUE)

Чтение при этом происходит поблочно (а не весь файл в строку). Файл пишется не в строку неограниченной длины а в специальный справочник поблочно - одна порция UUE-кодированных данных в одну запись. В результате нет больших затрат по памяти и не засоряется одинэсная блоб-таблица. Если в справочнике перелезли лимит в 2Гб, то без проблема создаем справочник нумер два и нас будет еще 2Гб, куда можно гадить.

Количество взаимодействий с ВК минимально, объем перекачиваемых данных невелик. Оверхед - 30% объема исходного файла. UUE заменить на Base64 по вкусу.

При этом ВК лучше делать по типу Rainbow, чтобы исключить преобразования в Юникод. Иначе оверхед будет сразу больше 100%.