|
|
|
Поле - Тип данных: Двоичный
|
|||
|---|---|---|---|
|
#18+
Попалась мне база в формате Access 97 с очень странным полем. Тип данных - Двоичный. В поле хранились обычные строки. При этом в таблице быkи и обычные текстовые поля. В 97 Access их с виду не отличишь от обычных строк, а в Access 2003 - иероглифы. Копание в реестре (...Nls\CodePage...; ...\FontMapper...) привело к тому, что русский появился везде (в некоторых программах раньше встречались иероглифы вместо русских букв), но поле в Access 2003 по прежнему оставалось с иероглифами. Задачу удалось решить только сохранив таблицу в текстовый файл, и заново импортировав двоичные поля как строки. Такого типа данных теоретически нет в природе. Но в конструкторе чёрным по белому написано: Тип данных - Двоичный. Вот по поводу типа данных вопросы: 1. как научить Access 2003 нормально отображать текст в этих полях. 2. как самому создавать поля с таким типом данных 3. как изменить размер поля с таким типом данных 4. зачем вообще оно нужно ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.08.2004, 11:27:53 |
|
||
|
Поле - Тип данных: Двоичный
|
|||
|---|---|---|---|
|
#18+
SELECT t1.fNumber, StrConv([fBinary],64) AS Выражение1, t1.fText, t1.fMemo FROM t1; ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.08.2004, 11:51:12 |
|
||
|
Поле - Тип данных: Двоичный
|
|||
|---|---|---|---|
|
#18+
Что там ANSI, я догадывался. Но вопрос не в этом. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.08.2004, 11:59:04 |
|
||
|
Поле - Тип данных: Двоичный
|
|||
|---|---|---|---|
|
#18+
1. Как я понял, ты взял базу, в которой текст хранится в ANSI, тебе его нужно конвертонуть UPDATE t1 SET t1.fBinary = StrConv([fBinary],64); 2 и 3. ALTER TABLE t1 ADD COLUMN НовоеПоле Binary(87); Думаю размер можно задать и в конструкторе 4. Зачем нужен такой тип? Думаю для совместимости с другими базами ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.08.2004, 12:11:48 |
|
||
|
Поле - Тип данных: Двоичный
|
|||
|---|---|---|---|
|
#18+
2 Roma R спасибо всё понял, но по поводу последнего вопроса - непонятки. ведь в оригинальной таблице строки хранились в двух видах полей - двоичных и текстовых. провёл эксперимент: создал таблицу счётчик + строка (254) индексы по счётчику-ключ, по строке-допускаются совпадения результаты: Код: plaintext 1. 2. 3. 4. 5. 6. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.08.2004, 12:58:19 |
|
||
|
Поле - Тип данных: Двоичный
|
|||
|---|---|---|---|
|
#18+
привет marvan Поскольку файл в формате 97, думаю, поле создавали в VBA-коде, манипулируя TableDefs примерно следующим образом Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. двоичное поле хранит произвольные данные - что напишешь, то и будет. Если формат файла > 97 и хранить будешь строки, то заказывать надо удвоенную длину, поскольку писаться будет юникод. По поводу крякозябров. - Как всегда, песня из двух куплетов. Если проблема возникает в пределах одной версии, то поем так: у поля есть свойство CollationOrder, (не провярял, но) думаю, что для избавления от крякозябров достаточно подрулить его значение. При переносе с 97 в 2003, думаю, проблема возникает в связи с тем, что 97й пишет в поле ANSI, а 2003 читать хочет юникод. Поэтому и работает либо указанный Roma R StrConv, либо выгрузка/загрузка через текстовый файл. Вновь загруженные данные строковые уже в юникоде в поле пишутся. Вот так я думаю. С выражением лица, Victosha ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.08.2004, 13:09:12 |
|
||
|
Поле - Тип данных: Двоичный
|
|||
|---|---|---|---|
|
#18+
marvan2 Roma R спасибо всё понял, но по поводу последнего вопроса - непонятки. ведь в оригинальной таблице строки хранились в двух видах полей - двоичных и текстовых. провёл эксперимент: создал таблицу счётчик + строка (254) индексы по счётчику-ключ, по строке-допускаются совпадения результаты: Код: plaintext 1. 2. 3. 4. 5. 6. Текст - это фактически VarChar, а двоичное - честное binary - без Var - сколько байт заказал размера, столько и получил размера файла ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.08.2004, 13:13:13 |
|
||
|
Поле - Тип данных: Двоичный
|
|||
|---|---|---|---|
|
#18+
Зачем нужен такой тип? Ну массив фиксированного размера или структуру туда можно записать. в отличие от LongBinary (OLE) - слишком редко применяется в акцессах, чтобы его в конструктор размещать ... (думаю так. или выражение лица у меня такое.) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.08.2004, 13:16:50 |
|
||
|
Поле - Тип данных: Двоичный
|
|||
|---|---|---|---|
|
#18+
Похоже, двоичный тип данных действительно ошибка природы. Редкий зверь с тремя кривыми лапами. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.08.2004, 13:30:41 |
|
||
|
Поле - Тип данных: Двоичный
|
|||
|---|---|---|---|
|
#18+
marvanПохоже, двоичный тип данных действительно ошибка природы. Редкий зверь с тремя кривыми лапами. ну, может, им строка фиксированной ширины понадобилась, и они ее прямо в базе фиксировать решили... А может, они так интернационализацию делали... (с выражением лица) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.08.2004, 13:56:00 |
|
||
|
|

start [/forum/topic.php?fid=45&tid=1672568]: |
0ms |
get settings: |
6ms |
get forum list: |
10ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
18ms |
get topic data: |
6ms |
get forum data: |
2ms |
get page messages: |
27ms |
get tp. blocked users: |
1ms |
| others: | 265ms |
| total: | 339ms |

| 0 / 0 |
