Hi Aleksey!

Судя по всему этого как раз и не должно происходить для blob/image - для
того он и предназначен. А вот для text/memo как раз должно происходить -
поскольку текст преобразуется учитывая всякие там collation и прочее... Не
предназначен text для хранения бинарной информации...

Posted via ActualForum NNTP Server 1.3

Hi Aleksey!

Э, не! Ты не путай фоксовый memo (который ко всему прочему ещё и атрибут
NOCPTRAN имеет - как раз для того чтобы заложенные в него бинарные данные
извлекались без перекодирования) и серверным Text - там совсем другие
правила работают... В лучшем случае наверное можно только закодировав в
BASE64 избежать ненужных конвертаций/искажений для бинарных файлов. А так -
пользуй Image...
Кстати интересный факт - в SQL2005 эти типы переименованы - и теперь они по
названию стали varchar/nvarchar и varbinary - просто в качестве размерности
ставится ключевое слово max...

СНГ :)

Posted via ActualForum NNTP Server 1.3

Hi Aleksey!

> Ну и какие там интересно правила работают на сервере по отношению к полям
> типа Text ? В сравнении с полями типа Image ?

В MSDN весьма расплывчато про это говорится (хотя и упомянуто про bit
patterns). Впрочем ты же сам говорил про проблемы "с некоторыми
последовательностями символов" На разных платформах в частности разные
понятия про "перевод строки" - и если сервер ИНТЕРПРЕТИРУЕТ поле как
текстовое, то без сомнения он может например для одних клиентов "перевод
строки" считать как CRLF (это кстати только в Win стандарт такой! он не
кроссплатформенный), для других же проcто как LF - и соответственно при
записи со стороны Win клиента и чтении со стороны Unix будет "пропадание"
байта, а при обратном направлении наоборот - образуется "лишний" байт...
Уверен что это далеко не все конвертации которые претерпевает ТЕКСТ.

=========Beginning of the citation==============
Each text and ntext data value has a collation. Collations define attributes
such as comparison rules and sensitivity to case or accenting. The
collations for text values also specify a code page, which defines the bit
patterns used to represent each character. Each ntext value uses the Unicode
code page, which is the same for all the collations. Each database has a
default collation. When a text or ntext column is created, it is assigned
the default collation of the database unless you assign a specific collation
using the COLLATE clause. When two text or ntext values having different
collations are combined or compared, collation precedence rules determine
which collation is used for the operation.

Data in an image data is stored as a string of bits and is not interpreted
by SQL Server. Any interpretation of the data in an image column must be
made by the application. For example, an application could store data in an
image column using a BMP, TIFF, GIF, or JPEG format. The application that
reads the data from the image column must recognize the format of the data
and display it correctly. All an image column does is provide a location to
store the stream of bits that make up the image data value.
=========The end of the citation================

>> В лучшем случае наверное можно только закодировав в
>> BASE64 избежать ненужных конвертаций/искажений для бинарных файлов...

> А каким образом это сделать ?

Со стороны клиента вестимо. И это уж от используемого клиента зависит :) В
Фоксе это STRCONV()

> И не вырастит ли объем файла в два раза как минимум ?

Вырастет, но не в 2, а лишь на треть - пропорция 8/6 - т.е. 1 некодированный
байт это 1.(3) кодированных байта - ну и плюс к тому по стандарту должно
быть "выравнивание" (padding) на границу 4-х символов, хотя не всегда это
соблюдается :(

Posted via ActualForum NNTP Server 1.3