:: Visual Foxpro, Foxpro for DOS
Зачем были созданы новые типы данных?
Владимир Максимов
Автор

Сообщений: 14095
Откуда: Москва
Дата регистрации: 02.09.2000
В VFP9 были созданы 2 принципиально новых типа данных: VarChar и BLOB.

С какой целью они были введены в FoxPro?

Вопрос вызван в основном особенностями реализации этих типов данных в FoxPro.

VarChar

Понятно, что речь идет о совестимости с MS SQL. Но разве нельзя было ввести какое-либо дополнительное свойство для Remote View вроде "отсекать концевые пробелы при записи"?

Если отвлечься от совместимости с MS SQL, то какова предположительная область применения этого типа данных собственно в среде FoxPro?

Пока я вижу одни недостатки от его использования:

1) Он не уменьшит, а увеличит размер базы данных.
2) Его использование требует повышенной бдительности от программиста в отношении настроек SET EXACT, SET ANSII, SET VARCHARMAPPING

Причем, если этот тип данных был введен именно для совместимости с MS SQL, то почему были установлены такие нелогичные настройки по умолчанию: CursorGetProp("MapVarchar")=.F. (для Remote View и SQLExec()) и SET VARCHARMAPPING ON. Хотя по логике должно быть с точностью до наоборот.

BLOB
Что этот тип данных делает такого, чего не мог выполнить старый тип данных Memo (binary) ?

Тип VarBinary я рассматриваю как частный случай BLOB, и в отношении него тот же вопрос. Чем он отличается от Memo (binary) в смысле предполагаемой области использования.




------------------
Ratings: 0 negative/0 positive
Re: Зачем были созданы новые типы данных?
piva

Сообщений: 18655
Откуда: Курган
Дата регистрации: 24.03.2004
Как-то быловался с типом BLOB, который поддерживает MySQL, как написано в хелпе (VFP) BLOB был придуман для полей nText, Text и Image MSSQL. Вот сляпал Remote View - прописал BLOB полю тип BLOB, на форме картинка ставлю ей PictureVal="=BIN" ( поле view) - нет картинки, пишу STRTOFILE(BIN,"C:\TEST.JPG") - получаю JPG файл. Далее вместо BLOB ставлю Memo (Binary) - картинка рисуется сразу - команада STRTOFILE - так же отрабатывает нормально - следовательно Владимир Максимов как всегда прав - я тоже не знаю куда можно привернуть BLOB вместо Memo(Binary) - разве что использовать в XML файлах т.к. BLOB это бинарные данные пропущенные через функцию StrConv(...,15) - Expression to Encoded hexBinary.

Владимиру Маскимову вопрос - Вы случайно не Янус Полуэткович из "Понедельник начинается в субботу" - един в двух лицах. А то как появляетесь на форуме - сразу 2 Владимира Максимова. Это приятно когда хорошего человека много




------------------
Часто бывает так, что есть над чем задуматься, а нечем.
Ratings: 0 negative/0 positive
Re: Зачем были созданы новые типы данных?
Владимир Максимов
Автор

Сообщений: 14095
Откуда: Москва
Дата регистрации: 02.09.2000
Цитата:
А то как появляетесь на форуме - сразу 2 Владимира Максимова.
Это у нас на работе глючит Internet и время от времени предлагают переключится на другой IP-адрес (2 варианта). Вот эти 2 адреса, видимо, и вызывают такой эффект.




------------------
Ratings: 0 negative/0 positive
Re: Зачем были созданы новые типы данных?
piva

Сообщений: 18655
Откуда: Курган
Дата регистрации: 24.03.2004
Зато забавно




------------------
Часто бывает так, что есть над чем задуматься, а нечем.
Ratings: 0 negative/0 positive
Re: Зачем были созданы новые типы данных?
Igor Korolyov

Сообщений: 34580
Дата регистрации: 28.05.2002
1) Размер БД в 90% случаев не увеличится, а если и вырастет, то всего на
RECCOUNT()*1 байт - для varchar поля нужен всего 1 дополнительный бит на
поле - причём он хранится в том-же служебном поле что и флаги Null-ов - это
уже обсуждалось на форуме.
2) Я пользу вижу в том, что не нужно больше думать о всяких RTrim-ах и
насиловать CursorAdapter "функциями преобразования", дабы в Remote-базу не
лезли лишние пробелы. Конечно если некто всегда всю работу с базой делал
руками, через свои собственные классы и слал INSERT INTO/UPDATE ... то ему
это и не очень нужно, но вот всем остальным - очень даже. Кстати как бы ты
без этого поля смог ввести в локальный курсор и затем отправить на сервер
значение типа: "asd fgh " (обрати внимание на 2 хвостовых пробела) - раньше
либо пробелов по плешку (до размера поля) - либо все вырезать - иного не
было
Да и даже в самом фоксе мне например нравится наличие такого типа поля.
Скажем многие функции преобразрования AllTrim/RTrim можно будет просто
выкинуть, заменив банальной конкатенацией. Т.е. польза определённо есть.
3) Насчёт настроек - господа, это же beta - и каковы будут настройки в
релизе зависит во многом от вас самих - пишите, и да будут услышаны ваши
голоса Мне тоже кажется что надо обратно их выставить (для удалённых
курсоров включить, для фоксовых запросов - выключить).
4) Насчёт blob - не вижу никаких сложностей в использовании - да это именно
так и есть как описано - memo(binary) пропускаемое через strconv() при
доступе. Мне пару раз реально приходилось пользоваться именно таким
преобразованием, так что вреда я в нём не вижу точно, а польза - ну это
конечно не супер-нужная-фича, но всё-же есть
5) varbinary это не memo - это Char(binary) пропскаемый через strconv() при
доступе - так что надо сравнивать его именно с "C(xx) NOCPTRANS". В принципе
в моих задачах я этим типом никогда не пользовался (в отличие от
memo-binary), но вот например для хранения ключа-GUID-а он IMHO очень хорошо
подходит (откидывай скобки и дефис - вот тебе и поле)




------------------
WBR, Igor
Ratings: 0 negative/0 positive
Re: Зачем были созданы новые типы данных?
Владимир Максимов
Автор

Сообщений: 14095
Откуда: Москва
Дата регистрации: 02.09.2000
Цитата:
1) Размер БД в 90% случаев не увеличится, а если и вырастет, то всего на
RECCOUNT()*1 байт - для varchar поля нужен всего 1 дополнительный бит на
поле - причём он хранится в том-же служебном поле что и флаги Null-ов - это
уже обсуждалось на форуме.
Я в курсе. Размер поля _NullFlags можно рассчитать по формуле:

?CEILING((N+V)/8)

N - это количество полей, в которых допустимо использования значения NULL
V - это количество полей типа VarChar или VarBinary

Цитата:
2) Я пользу вижу в том, что не нужно больше думать о всяких RTrim-ах и
насиловать CursorAdapter "функциями преобразования", дабы в Remote-базу не
лезли лишние пробелы.
Почему для решения этой задачи понадобилось вводить новый тип данных, а не модифицировали Remote View (или еще какие-нибудь настройки)?

Цитата:
Кстати как бы ты
без этого поля смог ввести в локальный курсор и затем отправить на сервер
значение типа: "asd fgh " (обрати внимание на 2 хвостовых пробела) - раньше
либо пробелов по плешку (до размера поля) - либо все вырезать - иного не
было
Да, такую задачу можно решить только введением нового типа данных или прямой модификации через T-SQL. Но я как-то сомневаюсь, что это очень уж распространенная задача. Обычно требовалось именно "все или ничего" в качестве концевых пробелов.

Цитата:
Да и даже в самом фоксе мне например нравится наличие такого типа поля.
Скажем многие функции преобразрования AllTrim/RTrim можно будет просто
выкинуть, заменив банальной конкатенацией. Т.е. польза определённо есть.
Т.е. выгода от VarChar только в операциях сложения строк? И для этого надо было вводить новый тип данных? А насколько усложнится сам процесс работы с символьными строками при совместном использовании Char и VarChar не прикидывал?

Например, объединение таблиц по JOIN по полям VarChar? Не проблема, конечно, если не забыть выставить SET ANSI. Но куча воплей в конфе по поводу глюков объединения обеспечена!

Цитата:
4) Насчёт blob - не вижу никаких сложностей в использовании
Вопрос не в сложности использования, а зачем это вообще надо? Чем лучше BLOB или VarBinary по сравнению с Memo(binary) и Char(binary)? Что они могут такого, чего не могли поля со свойством binary?

Да, кстати, ты уверен, что BLOB и VarBinary - это Char пропущенный через StrConv()? Ведь физически хранится голая последовательность битов. Я предполагаю, что как раз Char требует дополнительных преобразований, а BLOB - это чтение содержимого "как есть". Вообще без преобразований. Или я ошибаюсь?




------------------
Ratings: 0 negative/0 positive
Re: Зачем были созданы новые типы данных?
Igor Korolyov

Сообщений: 34580
Дата регистрации: 28.05.2002
Цитата:
Почему для решения этой задачи понадобилось вводить новый тип данных,
а не модифицировали Remote View (или еще какие-нибудь настройки)?
Я
не думаю что так было бы лучше...
SPT тогда тоже модифицировать надо или побоку? Сохранить результат выборки в
таблицу, да или просто в другой курсор (ну скажем обработка такая - из одной
таблицы через запрос(ы) в дургую перегнать, без участия сервера)... В общем
мне кажется что так как сделали оно очень неплохо, и вполне удобно. Я
пожалуй даже в чисто фоксовых базах стану использовать
Цитата:
Т.е. выгода от VarChar только в операциях сложения строк?
Нет
не только. Просто хранение инфы "в том виде как её ввели", без всяких там
дополнений пробелами это очень неплохое улучшение.
Цитата:
Например, объединение таблиц по JOIN по полям VarChar
Ну
вот - сразу крайности ты сам реально часто где используешь "Join по полям
наименований"? Я - очень редко и лишь для очень специфических целей (ну там
дубликаты между табличками найти) - в общем это IMHO не есть повседневная
работа.
Цитата:
Но куча воплей в конфе по поводу глюков объединения
обеспечена!
Ну и что? тогда по твоему не нужно было вообще ничего
такого вводить - ни dbc, ни триггера, ни транзакции, ни тем более
буферизацию - ибо от этих новшеств даже сегодня масса вопросов у народа
возникает. И это при том, что ВСЕ эти задачи можно "руками" проэмулировать в
FPD... Порой даже более корректно и просто.
Цитата:
Вопрос не в сложности использования, а зачем это вообще надо?
Философ А зачем вообще нужны компьютеры? Вот я например считаю что 90%
того что сегодня "автоматизируют" можно очень успешно решать и без
компьютеров вообще Компьютеры лишь усложняют простому человеку жизнь -
пообщавшись с юзерами это видно особенно отчётливо
Цитата:
Чем лучше BLOB или VarBinary по сравнению с Memo(binary) и
Char(binary)
Чем лучше Integer по сравнению с C(4) NOCPTRANS? Чем
лучше AsTopLevel Form по сравнению со _SCREEN? Это IMHO вопросы без ответов.
Где-то применимо одно - где-то - другое.
Цитата:
Что они могут такого, чего не могли поля со свойством binary?
Ничего. Они лишь дополнительно "конвертируют" результат в ascii-hex числа.
Цитата:
Да, кстати, ты уверен, что BLOB и VarBinary - это Char пропущенный
через StrConv()
Нет конечно, я лишь могу видеть вход (dbf/fpt) и
выход (? mytable.myfield). О внутренностях "чёрного ящика" могу лишь
догадываться как и ты
Цитата:
Ведь физически хранится голая последовательность битов.
Естественно - всё есть голая последовательность битов - и Char и Numeric и
Double и Integer...
Цитата:
Я предполагаю, что как раз Char требует дополнительных
преобразований
Он считывается как последовательность байт - проходит
(или НЕ проходит) конвертацию кодовых страниц (опять же из одной
последовательности байт перевод в другую). И потом интерпретируется
как строка. Для var* вместо просто интерпретации ещё дополнительно очевидно
проводится конвертация. Проводится она для "хранимого в памяти
представления", или это лишь какой-то бит в variant-е который просто говорит
функции вывода (тому-же ?) что при выводе надо не как ASCII код символа это
брать, а преобразовать в 2 символа hex кода - я не знаю...
Цитата:
а BLOB - это чтение содержимого "как есть". Вообще без
преобразований.
"как есть" - это набор байт. И так оно всегда и
будет. Другое дело как это обрабатывать, как печатать...




------------------
WBR, Igor
Ratings: 0 negative/0 positive
Re: Зачем были созданы новые типы данных?
Владимир Максимов
Автор

Сообщений: 14095
Откуда: Москва
Дата регистрации: 02.09.2000
Цитата:
Просто хранение инфы "в том виде как её ввели", без всяких там
дополнений пробелами это очень неплохое улучшение.
С этим, пожалуй, соглашусь. Как-то не подумал о том, что может быть и такая задача. Видимо, просто не попадалась. Хотя, это можно решить и через Memo. ;)

Цитата:
Цитата:
Вопрос не в сложности использования, а зачем это вообще надо?
Философ
Нет, вопрос предельно конкретный.

Например, есть поля Numeric и Currency. Вроде бы, если речь идет о денежных суммах, они делают одно и то же. Однако есть предмет для сравнения. Currency - экономичнее (физически меньше места занимают), но Numeric - точнее для россиийской бухгалтерии. По приведенным тобой примерам тоже есть свои "За" и "Против". Взвешивая аргументы (и свои личные предпочтения) можно принять решение, что именно использовать.

А что можно сказать при сравнении BLOB и Memo(binary)? Что выбрать под конкретную задачу на FoxPro? Где здесь предмет сравнения? Чем они отличаются при реализации приложения? Способом отображения? Ну, так ни один из них и не позиционируется как тип данных для отображения!

Эта некая информация, которая требует дополнительной обработки. Просто при работе с одним типом данных мне придется применять одну методику обработки, а с другим - другую (и то, не факт!). Ну и в чем разница?

Например, при хранении файлов в таких полях вообще никакой разницы: StrToFile() или COPY MEMO ... Какой тип не используй, результат будет одинаковый.




------------------
Ratings: 0 negative/0 positive
Re: Зачем были созданы новые типы данных?
Igor Korolyov

Сообщений: 34580
Дата регистрации: 28.05.2002
Hi, Владимир!

Цитата:
С этим, пожалуй, соглашусь. Как-то не подумал о том, что может быть и
такая задача. Видимо, просто не попадалась. Хотя, это можно решить и через
Memo.
Именно через Memo и приходилось это решать, но у memo есть
масса своих недостатков - основной из которых - распухание fpt от работы в
Shared режиме (новая инфа дописывается в конец, даже если она по размену <=
старой ) Я так например когда-то хранил параметры (когда ещё хранил их в
dbf-ах) - и чтоб не сильно пух fpt приходилось ставить нечто типа
ON ERROR *
PACK Localpar.dbf
ON ERROR &lcOldOnError
Цитата:
Нет, вопрос предельно конкретный.
А что можно сказать при сравнении BLOB и Memo(binary)
Никогда не
задумывался над этим, если серьёзно. Один момент я уже сказал (GUID хранить,
хотя конечно без дефисов он страшен, но всё-же...). BLOB - ну наверное так
удобно сразу файл hex-coded получить...

P.S. Может быть Алексей обратит внимание на нашу беседу и просвятит какой же
глубинный смысл был в введении этих полей Я кстати и не удивлюсь, если
это было сделано исключительно "по просьбам трудящихся" - AUTOINC похоже
так-же делали, а потом пришлось доделывать (в 9-ке), ибо изначально он
крайне неудобен... Да и в 9-ке всё-же не хватает ему функции возврата
"последнего присвоенного для таблицы в рамках заданной датасессии"...
Американцы вообще немного странные люди - скажешь им что "а теперь есть
BLOB" - радуются, хотя по сути он был всегда... Я боюсь что так скоро
мы получим и CLOB вместе с memo, image вместе с General (а что добавить
возможность "вытянуть картинку обратно" - и готово) и тому подобные "новые
типы"




------------------
WBR, Igor
Ratings: 0 negative/0 positive
Re: Зачем были созданы новые типы данных?
Aleksey Tsingauz [MSFT]
Цитата:
В VFP9 были созданы 2 принципиально новых типа данных: VarChar и BLOB.
С какой целью они были введены в FoxPro?

Я думаю - это диверсия. Ну а теперь серьезно.

Это стандартные типы полей, многие СУБД (не только MS SQL) их поддерживают.
Было высказано довольно много пожеланий, чтобы эти типы были добавлены. Из-за их отсутствия, существует много трудностей при работе с удаленными источниками данных. Если вы с этим еще не столкнулись, то вам очень и очень повезло. Если в случае с Varchar можно сомневаться и понавесить 15-20 настроек, чтобы автоматически RTRIM-ить данные в тех или иных ситуациях, а через месяц популярной станет новая СУБД, с которой этот подход просто не будет работать, то в случае с Blob и Varbinary вопросов быть не должно. Почему? Да потому что в VFP нет других типов полей для хранения binary данных. То, что Char NOCPTRANS и MEMO NOCPTRANS являются binary типами данных - это глубокое заблуждение. Вот только на днях объяснял это на UT, NOCPTRANS всего лишь отменяет code page translation в момент чтения/записи данных в поле на диск. Во всех остальных ситуациях эти данные подвержены code page translation наравне с обычными Char и MEMO. Простой пример, SET COLLATE TO "Russian" и операции сравнения для Char NOCPTRANS и MEMO NOCPTRANS становятся нечувствительны к регистру букв. Это похоже на работу с binary данными? Индексы по полю Char NOCPTRANS почти бесполезны если CPDBF()!=CPCURRENT(), даже если индекс построен с COLLATE "MACHINE". Что происходит с SPT? Данные из Char NOCPTRANS и MEMO NOCPTRANS передаются как текстовые, не дай бог кодовые страницы на сервере и клиенте отличаются - данные на другом конце "провода" узнать будет сложно. Очень хорошее упражнение попробовать вставить значение больше 8Kb из MEMO NOCPTRANS в поле Image на MS SQL Server. И т.д. и т.п.


Цитата:
1) Он не уменьшит, а увеличит размер базы данных.

Совсем не факт, да и не вижу особой разницы с NULL полями. Благодаря этому прямой доступ к записи по номеру остается черезвычайно быстрым. Примите ко вниманию, что именно номер записи используется при индексировании.

Цитата:
2) Его использование требует повышенной бдительности от программиста в отношении настроек SET EXACT, SET ANSII, SET VARCHARMAPPING

Программист всегда должен быть очень бдителен к SET EXACT и SET ANSI.

Цитата:
Причем, если этот тип данных был введен именно для совместимости с MS SQL, то почему были установлены такие нелогичные настройки по умолчанию: CursorGetProp("MapVarchar")=.F. (для Remote View и SQLExec()) и SET VARCHARMAPPING ON. Хотя по логике должно быть с точностью до наоборот.
В релизе SET VARCHARMAPPING будет OFF по умолчанию. Надеюсь, тогда все будет логично?


Aleksey Tsingauz,
Visual FoxPro Dev Team

Ratings: 0 negative/0 positive
Re: Зачем были созданы новые типы данных?
piva

Сообщений: 18655
Откуда: Курган
Дата регистрации: 24.03.2004
2Aleksey
Тогда какого ... в vfp9 в SPT курсорах для BLOB или Image полей SQL сервера ставится General а не BLOB ?
Понятно, что в Remote View можно напильником подправить, а для SPT почему ставится General а не BLOB по умолчанию ?




------------------
Часто бывает так, что есть над чем задуматься, а нечем.
Ratings: 0 negative/0 positive
Re: Зачем были созданы новые типы данных?
Владимир Максимов
Автор

Сообщений: 14095
Откуда: Москва
Дата регистрации: 02.09.2000
Ничего себе! Выходит, диверсия была проведена когда ввели NOCPTRANS! А введение BLOB - это исправление последствий этой диверсии! Странно, что о таком поведении NOCPTRANS ни слова в описании. Теперь понятно, чем они отличаются.

Цитата:
Программист всегда должен быть очень бдителен к SET EXACT и SET ANSI.
Количество настроек в FoxPro и так уже достаточно велико. Поэтому, если есть возможность, я стараюсь писать программу таким образом, чтобы не зависеть от таких глобальных настроек.

При работе с полями Char обойти проблему SET EXACT и SET ANSI довольно просто, добавив концевые пробелы к символьным выражениям:

=SEEK(PADR("test",10))

Такой поиск будет правильным вне зависимости от SET EXACT

А вот с VarChar такой фокус не пройдет

Цитата:
В релизе SET VARCHARMAPPING будет OFF по умолчанию. Надеюсь, тогда все будет логично?
Если в паре к ней по умолчанию будет CursorGetProp("MapVarchar")=.F. (для Remote View и SQLExec()). В противном случае - опять непонятки: тип ввели, но для его поддрежания нужны дополнительные настройки?!


Теперь кое что прояснилось:

BLOB устраняет ряд недостатков, присущих NOCPTRANS. Поскольку содержащаяся в полях NOCPTRANS информация тем не менее рассматривается FoxPro как символы, а не как двоичная последовательность (binary)

VarChar, прежде всего, включен для совместимости с серверными базами данных. Область применения его собственно в таблицах FoxPro по прежнему не понятна.




------------------
Ratings: 0 negative/0 positive
Re: Зачем были созданы новые типы данных?
Igor Korolyov

Сообщений: 34580
Дата регистрации: 28.05.2002
Hi, piva!

Кстати меня тоже всегда интересовал этот вопрос, хотя реально я с image
полями не работал (да и вообще перспективы серьёзного импользования MSSQL у
нас пока под вопросом - заказчики всё больше на Oracle сидят...)
Причём "достать" image было (и есть пока что вообще очень
затруднительно - приходилось ручками вправлять тип поля на Memo(binary), что
уже само по себе не такая и тривиальная задача, потом только можно было
скинуть данные в файл...




------------------
WBR, Igor
Ratings: 0 negative/0 positive
Re: Зачем были созданы новые типы данных?
Igor Korolyov

Сообщений: 34580
Дата регистрации: 28.05.2002
Hi, Aleksey Tsingauz!

Вот, теперь значительно понятнее Я как-то совсем забыл что эти типы
данных не только к полям относятся, но и к переменным... А тут реально
большие отличия будут по сравнению со старой "строкой" в которую и memo и
char и они же (binary) конвертились...




------------------
WBR, Igor
Ratings: 0 negative/0 positive
Re: Зачем были созданы новые типы данных?
Aleksey Tsingauz [MSFT]
Цитата:
Цитата:
Программист всегда должен быть очень бдителен к SET EXACT и SET ANSI.
Количество настроек в FoxPro и так уже достаточно велико. Поэтому, если есть возможность, я стараюсь писать программу таким образом, чтобы не зависеть от таких глобальных настроек.

При работе с полями Char обойти проблему SET EXACT и SET ANSI довольно просто, добавив концевые пробелы к символьным выражениям:

=SEEK(PADR("test",10))

Такой поиск будет правильным вне зависимости от SET EXACT

А вот с VarChar такой фокус не пройдет

Да? Это почему же?

Цитата:
Цитата:
В релизе SET VARCHARMAPPING будет OFF по умолчанию. Надеюсь, тогда все будет логично?
Если в паре к ней по умолчанию будет CursorGetProp("MapVarchar")=.F. (для Remote View и SQLExec()). В противном случае - опять непонятки: тип ввели, но для его поддрежания нужны дополнительные настройки?!
Все эти настройки по умолчанию OFF, причина на мой взгляд очевидна - обеспечить VFP8 совместимое поведение. В бета версии SET VARCHARMAPPING установлена в ON чисто из соображений тестирования.

Цитата:
VarChar, прежде всего, включен для совместимости с серверными базами данных. Область применения его собственно в таблицах FoxPro по прежнему не понятна.

Владимир, по-моему, область применения вполне очевидна - хранение текстовых данных переменной длины не более 254 байт. Игорь даже привел несколько примеров зачем это может быть нужно. Ничего страшного если вы не видите немедленное применение этого типа в своих приложениях. Когда появится надобность, функциональность уже на месте. Делать заключение "включен ТОЛЬКО для совместимости с серверными базами данных" - это загонять себя в какие-то, искуственно созданные, границы в выборе средств в будущем. А озвучивать его на всю "вселенную" - это еще и загонять в эти границы других людей.

Aleksey Tsingauz
Visual FoxPro Dev Team

Ratings: 0 negative/0 positive
Re: Зачем были созданы новые типы данных?
Aleksey Tsingauz [MSFT]
Здравствуйте, Вадим!

Цитата:
Тогда какого ... в vfp9 в SPT курсорах для BLOB или Image полей SQL сервера ставится General а не BLOB ?
Понятно, что в Remote View можно напильником подправить, а для SPT почему ставится General а не BLOB по умолчанию ?

А для совместимости с предыдущими версиями. В идеале, чтобы можно было перекомпилировать существующий код и запустить без всяких изменений. Простой пример, Image поле может содержать "копию" OLE объекта (по-моему, categories.picture в MS SQL базе Northwind использует именно этот формат), General поле как раз умеет работать с этим форматом. В VFP8 приложение запускало запрос, получало назад General поле, без проблем создавало OLE объект и занималось своими делами дальше. Теперь представим, что в VFP9 оно получит Blob, который не привязан ни к какому определенному формату и понятия не имеет что делать с содержимым. Каков результат? "Cломанное" приложение.

Aleksey Tsingauz
Visual FoxPro Dev Team

Ratings: 0 negative/0 positive
Re: Зачем были созданы новые типы данных?
piva

Сообщений: 18655
Откуда: Курган
Дата регистрации: 24.03.2004
Алексей, а нельзя ли ввести некий переключатель типа SET BLOB TO BLOB или SET BLOB TO GENERAL для SPT запросов, а то я не любитель и по ряду причин невсегда использую Remote View.




------------------
Часто бывает так, что есть над чем задуматься, а нечем.
Ratings: 0 negative/0 positive
Re: Зачем были созданы новые типы данных?
Aleksey Tsingauz [MSFT]
Цитата:
Как-то быловался с типом BLOB, который поддерживает MySQL, как написано в хелпе (VFP) BLOB был придуман для полей nText, Text и Image MSSQL. Вот сляпал Remote View - прописал BLOB полю тип BLOB, на форме картинка ставлю ей PictureVal="=BIN" ( поле view) - нет картинки, пишу STRTOFILE(BIN,"C:\TEST.JPG") - получаю JPG файл. Далее вместо BLOB ставлю Memo (Binary) - картинка рисуется сразу - команада STRTOFILE - так же отрабатывает нормально - следовательно Владимир Максимов как всегда прав - я тоже не знаю куда можно привернуть BLOB вместо Memo(Binary) - разве что использовать в XML файлах т.к.

Только что попробовал следующее в бета версии:

CREATE CURSOR foo (f1 Blob)
APPEND BLANK
REPLACE f1 WITH FILETOSTR("test.jpg")

Создал форму, бросил на нее Image control, PictureVal= "=foo.f1"
Запустил форму, картинка отобразилась.

Цитата:
BLOB это бинарные данные пропущенные через функцию StrConv(...,15) - Expression to Encoded hexBinary.

BLOB - это последовательность байтов, VFP никакую кодировку не применяет.

Aleksey Tsingauz
Visual FoxPro Dev Team

Ratings: 0 negative/0 positive
Re: Зачем были созданы новые типы данных?
Aleksey Tsingauz [MSFT]
Цитата:
Алексей, а нельзя ли ввести некий переключатель типа SET BLOB TO BLOB или SET BLOB TO GENERAL для SPT запросов, а то я не любитель и по ряду причин невсегда использую Remote View.

Переключатель давно на месте:
CURSORSETPROP("MapBinary",.T.,0)
Ratings: 0 negative/0 positive
Re: Зачем были созданы новые типы данных?
piva

Сообщений: 18655
Откуда: Курган
Дата регистрации: 24.03.2004
Алексей, что-то я погорячился, странно, почему тогда не работало ? Теперь все отлично работает, и про StrConv оказалось ошибкой, потому как просмотр поля BLOB показыает последовательность похожую на StrConv, хотя фактически на диске поле BLOB именно в бинарном виде.
Спасибо, что ткнули носом куда следует.

PS. Кстати, и портрет Билла Гейтса (WILLIAM GATES III ) висит у меня на стенке, фотку забрал с сайта БГ и распечатал на цветном принтере. Без шуток



[i][small][color=Gray]Отредактировано (22.09.04 12:35)


------------------
Часто бывает так, что есть над чем задуматься, а нечем.
Ratings: 0 negative/0 positive


Извините, только зарегистрированные пользователи могут оставлять сообщения в этом форуме.

On-line: 33 AndyNigmatec akvvohinc  (Гостей: 31)

© 2000-2024 Fox Club 
Яндекс.Метрика