ЗАЧЕМ? Тебе же со стороны картинки будут записывать в Blob, без всякого забасивания! раз работает так запросто (?m.t), то все уже и так хорошо.

of63
ЗАЧЕМ? Тебе же со стороны картинки будут записывать в Blob, без всякого забасивания! раз работает так запросто (?m.t), то все уже и так хорошо.

Не, это я буду записывать картинки

Если бы только ты сама писала и читала (точнее, только своей прогой) в поле Blob, то можно было бы хоть забасивать, хоть шифровать. Но если кто-то другой, другой прогой, собирается видеть это поле как набор байтов, типа как в файле-картинке, то тогда надо держать в этом поле именно байты, составляющие файл-картинку, а не что-то другое...

Доб. Кстати, ты посмотри, что реально попадает в это поле. В HEX-виде там должно быть идентично HEX-виду JPG-файла, туда записанному.



Исправлено 1 раз(а). Последнее : of63, 14.11.18 16:42

of63
Доб. Кстати, ты посмотри, что реально попадает в это поле. В HEX-виде там должно быть идентично HEX-виду JPG-файла, туда записанному.

Вот такая штука в HEX-виде получается -

[attachment 30269 hex.jpg]

Божья_коровка

of63
Доб. Кстати, ты посмотри, что реально попадает в это поле. В HEX-виде там должно быть идентично HEX-виду JPG-файла, туда записанному.

Вот такая штука в HEX-виде получается -

[attachment 30269 hex.jpg]

Офа так точно разглядит. Надо было мельче сделать.

Ну при увеличении вроде похоже на заголовок JPG-файла.





Исправлено 1 раз(а). Последнее : Crispy, 14.11.18 17:41

И вторая должна быть картинка - исходный файл в таком же HEX-виде (первая картинка из монитора БД наверное?). Сравниваешь, убеждаешься, что они одинаковые, и значит все ок.

Crispy
Офа так точно разглядит. Надо было мельче сделать.

Как получилось

Crispy
Ну при увеличении вроде похоже на заголовок JPG-файла.

of63
И вторая должна быть картинка - исходный файл в таком же HEX-виде (первая картинка из монитора БД наверное?). Сравниваешь, убеждаешься, что они одинаковые, и значит все ок.

Визуально похожи, начало и конец одни и те же. Так это всё? И больше ничего не надо?

Божья_коровка
Как получилось

А ты чем снимала?

Больше ничего. Дальше увидишь, если в тех местах, где прога устанавливается, тоже будет так же работать, то значит жизнь удалась

of63
Больше ничего. Дальше увидишь, если в тех местах, где прога устанавливается, тоже будет так же работать, то значит жизнь удалась

Немного не поняла как я должна это увидеть, но видимо нормально инсертится в блоб





Исправлено 2 раз(а). Последнее : Божья_коровка, 14.11.18 18:11

Crispy

Божья_коровка
Как получилось

А ты чем снимала?

PrtScr

Божья_коровка

of63
Больше ничего. Дальше увидишь, если в тех местах, где прога устанавливается, тоже будет так же работать, то значит жизнь удалась

Немного не поняла как я должна это увидеть, но видимо нормально инсертится в блоб

Да юзеры сами скажут, если что не так.

Божья_коровка
Я хочу спросить - это всё? Так надо делать base64 или нет?

А теперь выними обратно в фокс - вот тогда и будет "фсё" или "не фсё"

Но поле-то Blob не зря кем-то сделано (не БК-шкой), не текстовое. Походу, там собирались хранить именно бинарные файлы. Поэтому такой спитч в 3 страницы...

У неё тоже в "строке" совсем даже не текст находится. В фоксе (8-м) нет "настоящих" бинарных типов данных, да и 9-ные blob/varbinary это скорее хитрый трюк вокруг строкового типа, а не настоящий byte[] или типа того.
Но ODBC (да и сами сервера) кое что умеют преобразовывать - в частности строку в набор байт для blob поля - но там 100500 нюансов с кодировками, с возможными ошибками "невозможности конвертации", плюс к тому для фокса (8 и младше) большой проблемой будет получить обратно именно "бинарные данные".

Igor Korolyov
У неё тоже в "строке" совсем даже не текст находится. В фоксе (8-м) нет "настоящих" бинарных типов данных, да и 9-ные blob/varbinary это скорее хитрый трюк вокруг строкового типа, а не настоящий byte[] или типа того.
Но ODBC (да и сами сервера) кое что умеют преобразовывать - в частности строку в набор байт для blob поля - но там 100500 нюансов с кодировками, с возможными ошибками "невозможности конвертации", плюс к тому для фокса (8 и младше) большой проблемой будет получить обратно именно "бинарные данные".

Игорь, меня больше волнует сможет ли с этого блоба вытащить нормальную фотку другой разраб другими средствами, не фоксом. Т.е. правильно ли всё положилось с фокса в блоб. А для фокса, так я средствами оракла делаю преобразование из типа блоб в клоб и всё прекрасно вытаскивается на клиента с VFP8. Сделала эксперимент проблем нет, фотка прекрасная. Т.е. зачем мне мучиться с фоксовым полем General если на стороне оракла всё можно преобразовать и получить уже нужный результат на клиента без напряга для VFP8.





Исправлено 4 раз(а). Последнее : Божья_коровка, 16.11.18 10:34

Божья_коровка
Игорь, меня больше волнует сможет ли с этого блоба вытащить нормальную фотку другой разраб другими средствами, не фоксом.

А почему тебя должны волновать чужие проблемы
blob стандартный тип, большинство средств доступа нормально с ним работают - особенно из более-менее современных.

Божья_коровка
Т.е. правильно ли всё положилось с фокса в блоб.

Сомневаешься - извлеки другими средствами, сохрани в файл и сравни побайтно Но судя по приведенному скриншоту всё ок - заголовок вполне себе jpeg-овский.

Божья_коровка
А для фокса, так я средствами оракла делаю преобразование из типа блоб в клоб и всё прекрасно вытаскивается на клиента с VFP8.

Да, это один из вариантов обхода дурацкой пролблемы с получением General в старых версиях фокса. НО CLOB это "текстовый" тип, и потому байтики в нём подвержены преобразованиям связанным с конвертацией кодовых страниц. Ну точно так же как и в фоксе - если CPCURRENT не совпадает с CPDBF - и единственный способ избежать таковых преобразований, это убедится что кодировка БД совпадает с кодировкой установленной на клиенте (чере NLS_LANG). Пока кодировки совпадают, преобразования не производятся и ты получаешь бинарно идентичные данные. Естественно это проблема настройки окружения для твоей программы, а не её самой - да, кое что можно и из фокса настроить (например переменную окружения задать/изменить перед первым обращением к оракл-клиенту), но полного контроля ты не имеешь (как, например, над тем какой версией клиента будет пользоваться твой заказчик) - этим и плох (точнее опасен и неудобен) такой способ.

Божья_коровка
Т.е. зачем мне мучиться с фоксовым полем General если на стороне оракла всё можно преобразовать и получить уже нужный результат на клиента без напряга для VFP8.

Мучения с general это просто другой способ получения бинарных данных без "вредных" преобразований. Мы позволяем оракл-клиенту и ODBC получать именно "поток байт" (ничего не преобразуя ни на сервере ни в транспортной/оракл-клиентской части), но в этом самом старом фоксе полученные данные в структуре курсора помечаются как тип поля General (ну это может и логично - т.к. из иных типов только memo nocptrans хоть как-то соответствует "бинарным данным"), и с этим приходится так или иначе бороться

Ты её просто путаешь, этими полями General, Игорь, она их, мтк, и не знает, и знать это поле не надо, если в 8ке не придется. Не путай её заранее )

Igor Korolyov
Мучения с general это просто другой способ получения бинарных данных без "вредных" преобразований. Мы позволяем оракл-клиенту и ODBC получать именно "поток байт" (ничего не преобразуя ни на сервере ни в транспортной/оракл-клиентской части), но в этом самом старом фоксе полученные данные в структуре курсора помечаются как тип поля General (ну это может и логично - т.к. из иных типов только memo nocptrans хоть как-то соответствует "бинарным данным"), и с этим приходится так или иначе бороться

Хорошо, к примеру я делаю простой запрос без оракловых преобразований типов из блоба в клоб и получаю на клиенте курсор с типом поля General. Но к нему же напрямую не обратишься, с ним же тоже что то нужно делать чтобы "извлечь" картинку. Как с ним работать? Насильно превращать в Мемо, других вариантов как я понимаю нет?





Исправлено 2 раз(а). Последнее : Божья_коровка, 20.11.18 16:47