Вопрос про DBGrid.DataSource.DataSet.FieldValues[];

← →
vegarulez © (2008-09-17 12:53) [0]

Собственно вопрос в следуещем. есть БД Access, через Query + Dataset помещаю нужную мне выборку в грид. И всё бы хорошо но мне нужно временами при счелчке на нужной строке - вытаскивать некторые значения из этого массива.
Так вот когда я обращаюсь к данным, которые являются числовыми в БД - они нормально добавляются в стринговую переменную. Если же данные текстовые в БД то при обращении к ним выдаётся сообщение:
Could not convert variant of type (Null) into type (String)
... s: array[0..4] of string; ... s[0]:= DBGrid1.DataSource.DataSet.FieldValues["a"]; s[1]:=DBGrid1.DataSource.DataSet.FieldValues["b"];

Подскажите как быть. Это текстовое поле заполнено и явно не Null.

← →
clickmaker © (2008-09-17 12:57) [1]

> Это текстовое поле заполнено и явно не Null

либо оно таки нул, либо ошибка в другом месте

← →
Поросенок Винни-Пух © (2008-09-17 12:59) [2]

VarToStr(DBGrid1.DataSource.DataSet.FieldValues["a"])

← →
Поросенок Винни-Пух © (2008-09-17 13:00) [3]

Либо FiedByName().AsString

← →
vegarulez © (2008-09-17 13:03) [4]

нет, значение явно не нулл. в гриде оно есть, в базе тоже есть. только данные имеющие тип "Числовой" легко добавляются в s а те данные, что имеют в бд тип данных - "Текстовый" - выдают такую вот ошибку, хотя ещё раз повторюсь в гриде нормально отображаются.

← →
vegarulez © (2008-09-17 13:03) [5]

Поросенок Винни-Пух © (17.09.08 13:00) [2,3] аха сечас попробую.

← →
Правильный$Вася (2008-09-17 13:14) [6]

> имеют в бд тип данных - "Текстовый"

а, так это не varchar, это явно CLOB

← →
vegarulez © (2008-09-17 13:18) [7]

> Поросенок Винни-Пух © (17.09.08 12:59) [2]

В этом случае записывает пустоту.

> Поросенок Винни-Пух © (17.09.08 13:00) [3]

в этом случае всё ОК.

s[1]:=DBGrid1.DataSource.DataSet.FieldByName("b").AsString;

> Правильный$Вася (17.09.08 13:14) [6]
> > имеют в бд тип данных - "Текстовый"а, так это не varchar,
> это явно CLOB

А при чём тут Блоб? Блоб это не текстовые данные.

← →
Правильный$Вася (2008-09-17 13:19) [8]

> А при чём тут Блоб? Блоб это не текстовые данные.

да ты читать-то не умеешь
я написал CLOB - это character large object, то есть безразмерный текст

← →
vegarulez © (2008-09-17 13:21) [9]

> Правильный$Вася (17.09.08 13:19) [8]

приношу извенения -быстро читал.
и? в чём изюм CLOB? подскажи.

← →
Правильный$Вася (2008-09-17 13:46) [10]

это ты подскажи
твое текстовое поле - безразмерное или имеет предел длины в базе
потому как с безразмерными несколько по-другому нужно оперировтаь

← →
Поросенок Винни-Пух © (2008-09-17 13:56) [11]

нет, значение явно не нулл. в гриде оно есть

Очередной борец с очевидным за право быть в жизни невероятному

← →
Поросенок Винни-Пух © (2008-09-17 14:13) [12]

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

и у тебя два пути:
1. Вынуть процессор, вскрыть винт и наблюдая магнитные домены совершать опреации в мозге, параллельно рисуя в воображении картину, которая должна была нарисоваться программой (формы, данные, значения)

2. Перестать быть блондинкой и стать программистом. И верить не органам чувст а тому, что говорит эксепшен.

← →
vegarulez © (2008-09-17 14:47) [13]

Правильный$Вася (17.09.08 13:46) [10]
да оно конечно. там в БД задана конечная фиксированная длинна текстового поля.

Поросенок Винни-Пух © (17.09.08 14:13) [12]
ну я канеш не гуру - поэтому сюда и пишу. это первое - второе, не хотелось говорить так, как говорил один не безЫзвестный чел - "Я верю своим, глазам, я верю своим ушам"... но если в датасете эти ТЕКСТОВЫЕ данные есть, то они там и есть - единственно как они представляются. А то что вариант = нулл, это факт - не понятно только почему. И если ты такой умный может перестанешь бисером махать, или процессоры разбирать - а подскажешь почему оное так, а не по другому - опираясь на законы физики.

З.ы. Впринципе проблема решилась. Но хочется понять, что к чему после вашего ликбеза.

← →
Поросенок Винни-Пух © (2008-09-17 14:51) [14]

но если в датасете эти ТЕКСТОВЫЕ данные есть, то они там и есть - единственно как они представляются. А то что вариант = нулл, это факт - не понятно только почему.

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

> опираясь на законы физики.

пипец приплыли.
что тебе физически объяснить? как в ячейке памяти оказалось значение которое программа интрепретирует как пустое значение?
или что?

Вот тебе еще один пример чувака, который верил своим глазам, но не верил функции ClassName:

http://delphimaster.net/view/3-1221628427/

Св-во TField.Value использовать без нужды не следует, применяя вместо него явное преобразование типа данных AsInteger,AsString,AsBCD,AsFloat...
Это во-первых, делает код куда внятнее и прозрачнее (в т.ч. при ловле багов), во-вторых, по назначению использует внутренние переменные явного типа, в-третьих "переладывают" работу по преобразованию данных с кода на обертку (в данном случае ADO)
С нулами (NULL) в БД несколько запутаннее. Если нул лежит в стринговом поле, то св-во AsString вернет пустую строку точно также, как если в этом поле таблицы (запроса) хранилась бы пустая строка. А вот если NULL в нетекстовом поле, то приведение типа (AsInteger к примеру) даст AV, избежать которое можно двумя способами: "клиентским", используя перед присвоением метод TField.IsNull, и "серверным", выставив этому полю св-во NOT NULL на сервере.
А вот VALUE в случае нула исключение не вызовет, но что будет в переменной, которой присвоили этот нул - хз. Поэтому не рекомендуется писать

var
sf1: string;
if2: integer;
ff3: extended;
fd4: TDate;

begin
with ADODataSet1 do
begin
sf1 := FieldByName("F1").Value;
if2 := FieldByName("F2").Value;
ff3 := FieldByName("F3").Value;
df4 := FieldByName("F4").Value;
end;
end;

а использовать технологию

with ADODataSet1 do
begin
sf1 := FieldByName("F1").AsString;
if FieldByName("F2").IsNull then
if2 := FieldByName("F2").AsInteger;
if FieldByName("F3").IsNull then
ff3 := FieldByName("F3").AsFloat;
if FieldByName("F4").IsNull then
df4 := FieldByName("F4").AsDateTime;
end;

← →
Правильный$Вася (2008-09-17 15:47) [19]

> Св-во TField.Value использовать без нужды не следует

так автор его и не использует
Because of this flexibility, it is often preferable to use the FieldValues property (or the FieldByName method) rather than the Fields, FieldList, or AggFields properties

так автор его и не использует

Так один фик FieldValues это вариант. От чего и вся траблема.

Вопрос про DBGrid.DataSource.DataSet.FieldValues[]; Найти похожие ветки