Главная страница
    Top.Mail.Ru    Яндекс.Метрика
Форум: "Базы";
Текущий архив: 2004.09.05;
Скачать: [xml.tar.bz2];

Вниз

Проблема с полями   Найти похожие ветки 

 
Sergey13 ©   (2004-08-09 11:27) [40]

2[38] Nikolay M. ©   (09.08.04 11:20)
ИМХО, запаришся подставлять, если это не просто "действующая программа", а чужая (без исходников) "действующая программа" . Т.е. саму то таблу на вьюху - нет проблем. А вот ведение той таблицы в закрытой программе, а ведение новых таблиц - как? Тут по крайней мере все очень непросто. ИМХО


 
Nikolay M. ©   (2004-08-09 11:29) [41]


> Рафик   (09.08.04 11:23) [39]
> А ссылку по полям, как можно сделать!

А теперь тоже самое, но по-русски? И если это вопрос, то еще бы не помешало и знак "?" в конце поставить :)


 
sniknik ©   (2004-08-09 11:34) [42]

сомнение есть насчет ограничения...  не о самом ограничениии а о посчитаном обьеме записи. nvarchar в записи занимает 4 байта (это же указатель), стоит ли учитывать обьем на который он указывает а не тот что занимает?

сделал таблицу по примеру скрипта... все поля видны.
естественно это  
> [UnitTsht] AS ([dbo].[fnUnitTimeSum]([UnitID], 1)) ,
> [UnitTpz] AS ([dbo].[fnUnitTimeSum]([UnitID], 2)) ,
выкинул (ну нет такой у меня)

дело не в этом. (имхо) скорее в методах доступа (если счас скажет что BDE использует, не удивлюсь ;о)).


 
Рафик   (2004-08-09 11:37) [43]

Ничего не понял, что мне сделать то лучше, как мне от этого извращения избавиться?

Я уже в полном тупике блин!


 
Рафик   (2004-08-09 11:44) [44]

Интересная вещь поменял nvarChar на Varchar и поле увидилось, чем это может быть плачевно, подсажите пожалуста!!!


 
sniknik ©   (2004-08-09 11:55) [45]

> Я уже в полном тупике блин!
не ты один, ты всех в него поставил. ;о))

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

могу только предложить, выслать тебе тестовую програмку (500кб архив), если в ней по твоему запросу поля увидиш то дело явно не в базе. а в твоем (так и непоказаном) коде (/структуре определенной в десигне).

> nvarChar на Varchar и поле увидилось, чем это может быть плачевно
неправильной работой проги, n это "национальный"/national, типа руского.... так ты значений в поле не видел, а не самого поля?????


 
Nikolay M. ©   (2004-08-09 12:11) [46]


> nvarchar в записи занимает 4 байта (это же указатель),

2 байта. При чем тут указатель?

nvarchar(n)

Variable-length Unicode character data of n characters. n must be a value from 1 through 4,000. Storage size, in bytes, is two times the number of characters entered. The data entered can be 0 characters in length. The SQL-92 synonyms for nvarchar are national char varying and national character varying.


 
Рафик   (2004-08-09 12:34) [47]

Да у меня и кода нет ни какого обычный запрос Select * From tblUnits, в DBGRID, нет полей которые имеют тип nvarChar.


 
sniknik ©   (2004-08-09 12:44) [48]

> 2 байта. При чем тут указатель?
varchar указывает на то что что в записи не хранится сама строка как в случае char, а только указатель на нее сама она в другом месте (иначе не достигнуть вариабельности в длинне).
вот при этом.

можеш полистать BOL (вижу знаком, ссылки копировать умееш) по теме архитектура базы.
почему 4 а не два? а хрен его знает именно такой встречал в описаниях (может резерв, может для однотипности с мемо/имеджем, может просто меня память подводит и действительно 2)

для облегчения поиска (это типа подтверждение что я прав, в том что не надо было варчары считать)
раздел Pages and Extents
....

Rows cannot span pages in SQL Server. In SQL Server 2000, the maximum amount of data contained in a single row is 8060 bytes, not including text, ntext, and image data.

хотя чего доказывать? см.
> Рафик   (09.08.04 11:44) [44]
это у него действительно не от ограничения.


 
sniknik ©   (2004-08-09 12:46) [49]

> Да у меня и кода нет ни какого обычный запрос Select * From tblUnits, в DBGRID, нет полей которые имеют тип nvarChar.
ага, запрос естественно висит в воздухе, а несуществующие nvarChar-ы не имеют отношения к показаному скрипту. а что же мы тут тогда обсуждаем?


 
Ega23 ©   (2004-08-09 12:59) [50]

2 sniknik ©   (09.08.04 12:46) [49]

1. nvarchar от varchar отличается только тем, что юникодовая строка.
2. Действительно, varchar всего лишь указатель; если таблица с одним полем varchar(8000), то длина записи - 4 байта.
3. Ты имеешь что-то против BDE?   :о)

2 Рафик   (09.08.04 12:34) [47]
Исправь nvarchar на varchar


 
Nikolay M. ©   (2004-08-09 13:02) [51]


> sniknik ©   (09.08.04 12:44) [48]

Уговорил. Насколько помню, варчары хранятся в "куче" в MySQL и, кажется, ИБ, а вот насчет мсскл такой уверенности не было, виноват :)


 
sniknik ©   (2004-08-09 13:36) [52]

> 2 sniknik ©   (09.08.04 12:46) [49]
мне то это зачем? я чтото против этого говорил?

> 3. Ты имеешь что-то против BDE?   :о)
а то. BDE хорош для парадокса и тд. локальные базы, и то не всегда, сейчас.
юникод он кстати не поддерживает. но по вопросу (исчезают поля, а не данные в них символами вопроса) непонять. и не предположить (неуказано что используется)

> 2 Рафик   (09.08.04 12:34) [47]
> Исправь nvarchar на varchar
он это уже сделал, см. [44]. ну а если родная прога использует их для 2х-3х-... языков? а не только английский-локальный. тогда как?
глюки на оригинальную прогу спишем? чего гады не предусмотрели, мы же тут править будем!


 
s999   (2004-08-09 14:10) [53]


> Интересная вещь поменял nvarChar на Varchar и поле увидилось,
> чем это может быть плачевно, подсажите пожалуста!!!


Скорее всего, просто компоненты доступа не поддерживают тип данных nvarChar.



Страницы: 1 2 вся ветка

Форум: "Базы";
Текущий архив: 2004.09.05;
Скачать: [xml.tar.bz2];

Наверх





Память: 0.55 MB
Время: 0.048 c
1-1092739496
CAMCOH
2004-08-17 14:44
2004.09.05
Canvas. Помогите разобратся.


14-1092582660
Дмитрий12
2004-08-15 19:11
2004.09.05
Пожалуйста, помогите перевести код на C++:


14-1092310311
olookin
2004-08-12 15:31
2004.09.05
Вы считаете, что программы, поставляемые в составе Delphi...


14-1092631028
КаПиБаРа
2004-08-16 08:37
2004.09.05
Порекомендуйте программы


3-1091967151
Piero
2004-08-08 16:12
2004.09.05
Dataset not in edit mode





Afrikaans Albanian Arabic Armenian Azerbaijani Basque Belarusian Bulgarian Catalan Chinese (Simplified) Chinese (Traditional) Croatian Czech Danish Dutch English Estonian Filipino Finnish French
Galician Georgian German Greek Haitian Creole Hebrew Hindi Hungarian Icelandic Indonesian Irish Italian Japanese Korean Latvian Lithuanian Macedonian Malay Maltese Norwegian
Persian Polish Portuguese Romanian Russian Serbian Slovak Slovenian Spanish Swahili Swedish Thai Turkish Ukrainian Urdu Vietnamese Welsh Yiddish Bengali Bosnian
Cebuano Esperanto Gujarati Hausa Hmong Igbo Javanese Kannada Khmer Lao Latin Maori Marathi Mongolian Nepali Punjabi Somali Tamil Telugu Yoruba
Zulu
Английский Французский Немецкий Итальянский Португальский Русский Испанский