Беда таблички - заменяется ID командой Replace, Gather.

MaestroEv
Дата: 26.11.2012 10:21:13
Есть в программе Id код записи вот этот: Нx€Ѕд)џJҐMЕЊ  cM4
В таблички в разные он лезет Replacом нормально, а вот в одну лезет вот так: Íx__ä)_JÃMÅ_  cM4 и естественно это уже другой код. Он как-то преобразуется в момент записи в эту таблицу. Записывая даже в ручном режиме (Replace) во всякие разные lheubt таблицы - все нормально. Проблема именно с одной табличкой. Поле переименовывал. Добавлял в другое, новое - все едино - беда именно с табличкой.

Что с табличкой не так? Куда копать?
AndreTM
Дата: 26.11.2012 10:26:52
CP таблицы?
Dima T
Дата: 26.11.2012 10:28:16
MaestroEv
Нx€Ѕд)џJҐMЕЊ  cM4

Жесть.
попробуй тип поля Charaster (binary) поставить.
ArgonS
Дата: 26.11.2012 10:31:42
MaestroEv,

а пробовали создать клона таблицы(желательно ручками)? Если получиться записывать все по "нормальному", то проблема с самой таблицей, если нет то с кодом.
MaestroEv
Дата: 26.11.2012 10:34:39
Блин. Вот я.. не ожидал. Там и правда 866. Спасибо. Единственная табличка из "прошлой жизни".
Станислав С...кий
Дата: 26.11.2012 10:39:09
MaestroEv,
Код записи = строковые данные....:-( Голову бы разработчику оторвать...
MaestroEv
В таблички в разные он лезет Replacом нормально, а вот в одну лезет вот так:

Кто куда лезет? :-)))

По теме... Что-то мне кажется, что тут проблема с кодировкой.... Копай в эту сторону...
MaestroEv
Дата: 27.11.2012 07:34:10
Да с кодировкой.. спасибо.

Строковые записи - код записи - голову оторвать..
А как иначе? Нумерик? Чтобы всегда рос? А если таблицам по 15 лет? При вводе новой записи искать дырки? На это уйдет куча ресурсов если таблиц более 100...
А если код уникален на 10 серверах.. то составной индекс?

Че-то я пока с головой останусь.. А вот тем кто использует нумерик в ID .. тем стоит задуматься. :)
Мимоходом555
Дата: 27.11.2012 08:38:10
MaestroEv

Че-то я пока с головой останусь.. А вот тем кто использует нумерик в ID .. тем стоит задуматься. :)


Насколько я помню, в DBF таблице может быть максимум 1 миллиард записей, почему Вы решили, что нумерика для этого не хватит?
Dima T
Дата: 27.11.2012 09:23:09
MaestroEv
Строковые записи - код записи - голову оторвать..
А как иначе? Нумерик? Чтобы всегда рос? А если таблицам по 15 лет? При вводе новой записи искать дырки? На это уйдет куча ресурсов если таблиц более 100...
А если код уникален на 10 серверах.. то составной индекс?

Все зависит от задачи. У тебя походу GUID в строке хранится. Он тоже 16 байт. Просто для читабельности его при выводе в 16-ричный вид преобразовывают. В фоксе под него нет специального типа, вот и хранят в строке, только такие строки надо как Binary хранить, чтоб кодовые страницы не гадили и индексы правильно работали при collate "russian"
Ну и про 15 лет и дырки ты загнул. Скорее всего разработчики просто решили использовать GUID чтобы не заморачиваться с написаним самопальных счетчиков и распределением диапазонов ID-шников по разным базам.

MaestroEv
Че-то я пока с головой останусь.. А вот тем кто использует нумерик в ID .. тем стоит задуматься. :)

нумерик не советую (он как строка хранится), а вот Integer - да. причем везде где только можно.
У GUIDа один плюс - глобальная уникальность, зато есть серьезный минус - размер. Сравни или 16 байт или 4 байта Integer, который позволяет сгенерить 2 миллиарда значений, которых в 99% случаев хватит на 100 лет работы.
А 4 байта против 16 это:
1. Размер базы меньше. Посчитай сколько там ID-шников разных хранится.
2. Сравнение быстрее, т.е. операции индексирования и поиска

Я как-то переболел GUIDами в свое время, тоже сначала подумал какое замечательное супер-изобретение, а потом проводил тесты, взял базу не маленькую и заменил все поля Integer на GUID: размер вырос ощутимо, время тех же выборок выросло в разы.
q1w1e1
Дата: 27.11.2012 09:27:24
Я конечно не корифей, поэтому лучше сослаться на классиков, например Базиян, где он писал, что поле Numeric(это у него совет, а не руководство), надо применять, где будут операции над числами, и приведёно код для получения id в символьном виде..