Скачать: CL | DM;

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

← →
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 вся ветка

Скачать: CL | DM;



Память: 0.55 MB
Время: 0.022 c