Type mismatch for field Field1 , expecting: LargeInt

← →
Дмитрий (2016-10-28 18:26) [0]

Есть "справочник" состояний из 5-х записей с кодами состояния типа int(10)
Есть таблица изготавливаемых изделий.
Есть вьюха q_State, в запросе код состояния изделия вычисляется посредством case when ... then 4 ... else 1 end as StateID
Есть датасет с изделиями (ADQueryItems), в запросе связана таблица изделий с вьюхой, откуда берется вычисленный код состояния.
Дасет изделий связан с датасетом "справочника".
При открытии наборов нормально отображается справочник и нормально отбираются изделия соответсвенно состоянию.
Однако при попытке отсортировать изделия выдается ошибка
ADQueryItems: Type mismatch for field "StateID", expecting: LargeInt actual: Integer.
Попробовал изменить в справочнике на tinyint, не помогло.

Почему вылезает несоответствие типов при сортировке, хотя не вылезает при открытии и перемещении по датасетам?

← →
Дмитрий (2016-11-09 18:09) [1]

Причину не нашел, сделал связь с текстовым полем

← →
stas © (2016-11-10 13:05) [2]

Если явно не указан тип поля в запросе, то он определяется по 1 значению.
Перед сортировкой у тебя 1 значение, после другое. Задай этому полю тип в запросе

(when ... then 4
...
else 1
end as StateID) as int (или как там по синтаксису)

← →
Дмитрий (2016-11-21 18:00) [3]

Сразу попробовал и Cast( ... as SIGNED), и Cast( ... as UNSIGNED)
Не помогло
Кроме того, с чего бы сервер для 1 выдавал один тип, а для 4 другой

← →
stas © (2016-11-22 15:20) [4]

Дмитрий (21.11.16 18:00) [3]
Покажи полный текст запроса. и скажи какая СУБД.

← →
iop © (2016-11-22 15:22) [5]

запрос здесь не при делах как и сервер.

сортировка у него клиентская.

.... за что и наказан

← →
sniknik © (2016-11-22 16:28) [6]

> Кроме того, с чего бы сервер для 1 выдавал один тип, а для 4 другой
а с чего ты решил что ругается на "разнотипные" поля в одном столбце?
ошибка
> ADQueryItems: Type mismatch for field "StateID", expecting: LargeInt actual: Integer.
ожидается (для операции) тип LargeInt, фактический Integer.

← →
sniknik © (2016-11-22 16:31) [7]

> Сразу попробовал и Cast( ... as SIGNED), и Cast( ... as UNSIGNED)
что кстати не всегда тип в базах... и у инта и у ларджинта есть знаковое и без знаковое представление.

← →
Дмитрий (2016-11-22 17:31) [8]

> stas © (22.11.16 15:20) [4]
База mySQL
Сейчас запрос переделан через if вместо case, и подставлены текстовые значения
Было же так
create VIEW `q_mstate` AS select i.itemid, case when (i.Start is null) then 0 -- chermovik when CurDate() >= DATE_ADD(i.Complect, INTERVAL 365 DAY) then 4 -- arhiv when not i.ComplectFrom is null then 3 -- maked when ((DebtM=1) and (DebtMFact is null)) or ((DebtF=1) and (DebtFFact is null)) then 2 -- dolg else 1 end as MState from items i inner join mon m on i.itemid=m.itemid;

Код состояния задействуется в запросе, который отображается в GridEh
select ... from items i join mon m on m.ItemID = i.ItemID INNER JOIN q_MState ms on ms.ItemID = i.ItemID WHERE MState=:MState ;

← →
Дмитрий (2016-11-22 17:36) [9]

> iop © (22.11.16 15:22) [5]
> запрос здесь не при делах как и сервер.сортировка у него клиентская.
Сортировка осуществляется путем подстановки списка полей в выражение "Order By" запроса

> sniknik © (22.11.16 16:28) [6]
> с чего ты решил что ругается на "разнотипные" поля в одном столбце?
1. Об этом говорит сообщение об ошибке
2. После изменения типа поля на текстовое, ошибка исчезла

← →
stas © (2016-11-22 17:49) [10]

select ... from items i join mon m on m.ItemID = i.ItemID INNER JOIN q_MState ms on ms.ItemID = i.ItemID WHERE MState=:MState ;

Это ADOQueryItems ?
У тебя проблема с параметром, когда добавляешь order by, пересоздается параметр.
Ему нужно явно указать тип после добавления order by.
Уже точно не помню, но по моему можно где-то указать что параметр не пересоздавать.

← →
iop © (2016-11-22 17:59) [11]

Сортировка осуществляется путем подстановки списка полей в выражение "Order By" запроса

кого волнует что там делается, если исключение рождено внутри vcl?

ADQueryItems: Type mismatch for field "StateID", expecting: LargeInt actual: Integer.

ни сервер ни запрос к этому не имеют ни малейшего отношения.
вся буча внутри датасета.

← →
sniknik © (2016-11-23 13:06) [12]

> 1. Об этом говорит сообщение об ошибке
перечитай его еще раз

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

+ сортировка строк отличается от сортировки чисел.

> ни сервер ни запрос к этому не имеют ни малейшего отношения.
эээ... а вот удастся ему подогнать запросом подходящий тип, и это будет опровержением, ведь починится то запросом... ;) сарказм.

> База mySQL
> Сейчас запрос переделан через if вместо case, и подставлены
> текстовые значения
> Было же так

> create VIEW `q_mstate` AS
> select i.itemid,
> case
> when (i.Start is null) then 0 -- chermovik
> when CurDate() >= DATE_ADD(i.Complect, INTERVAL 365 DAY)
> then 4 -- arhiv
> when not i.ComplectFrom is null then 3 -- maked
> when ((DebtM=1) and (DebtMFact is null))
> or
> ((DebtF=1) and (DebtFFact is null)) then 2 -- dolg
> else 1
> end as MState
> from items i
> inner join mon m on i.itemid=m.itemid;

> ADQueryItems: Type mismatch for field "StateID", expecting:
> LargeInt actual: Integer.

В приведенном запросе слова StateID я не увидел. Сдается мне, что где-то показания ложные.

> В приведенном запросе слова StateID я не увидел.
Потому что оно здесь, в "волшебных пузырьках"
select
...
from items i
join mon m on m.ItemID = i.ItemID
INNER JOIN q_MState ms on ms.ItemID = i.ItemID
WHERE MState=:MState ;

← →
Дмитрий (2016-11-23 17:35) [15]

> Игорь Шевченко © (23.11.16 14:15) [13]
В результате переделки запроса с интежер на текстовый параметр и обратно "StateID" превратился в "MState"

> iop © (22.11.16 17:59) [11]
Поскольку проблема возникает при реакции датасета, то, разумеется, датасет причастен
Но это не значит, что сортировка происходит на клиенте

> sniknik © (23.11.16 13:06) [12]
> а вот удастся ему подогнать запросом подходящий тип, и это будет опровержением, ведь починится то запросом... ;) сарказм.
угу, с текстовым параметром работает

> stas © (22.11.16 17:49) [10]
>У тебя проблема с параметром, когда добавляешь order by, пересоздается параметр.Ему нужно явно указать тип после добавления order by.
Это мысль. Параметр дергать не пробовал.

Но это не значит, что сортировка происходит на клиенте

это означало, что бессмысленно уточнять такие вещи как :
Покажи полный текст запроса. и скажи какая СУБД.

а как именно там сортируется
вот по этому огрызку

Однако при попытке отсортировать изделия выдается ошибка
ADQueryItems: Type mismatch for field "StateID", expecting: LargeInt actual: Integer.

понять невозможно.

точнее все что понятно, что проблема стопроцентно не в серверном ордербае.

о чем и было написано вскользь.

а главный посыл что "запрос здесь не при делах как и сервер."- он без внимания.

ага

> Но это не значит, что сортировка происходит на клиенте
значит, именно на клиенте, т.к.
> ... при попытке отсортировать ...
> ADQueryItems: Type mismatch for field "StateID", expecting: LargeInt actual: Integer.
ошибка от клиентского компонента. ну и банально у тебя в запросах order by нет, не показано, а то что не показано - не существует.

Дмитрий (23.11.16 17:35) [15]

http://segfault.kiev.ua/smart-questions-ru.html

Type mismatch for field Field1 , expecting: LargeInt Найти похожие ветки