Помогите с SQL запросом.

← →
Mortal (2005-01-15 18:27) [0]

Проблема такая:

Необходимо выполнить запрос:

UPDATE L0, reg SET reg.C_KATL = L0.C_KATL
WHERE (reg.NPP=L0.NPP);

Если выполнять запрос в Accessе то все в лучшем виде.

Когда пробую в Delphi на компоненте TQuery то ругается на запятую.

Удаляю запятую (что ИМХО - бред) вроде что-то делает, но результат 0.

Зарание спасибо.

← →
Соловьев © (2005-01-15 18:39) [1]

>Удаляю запятую (что ИМХО - бред)
То в Ацесе нормально, а в BDE для dBase, FoxPro - нет

>но результат 0.
Ну значит так и есть

← →
Anatoly Podgoretsky © (2005-01-15 19:43) [2]

По синтаксису смотри справку по LocalSQL, у тебя же написан какой то бред, недопустимый для LocalSQL. Никаих множественных таблиц. После удаления запятой получается друго бред.

← →
Mortal (2005-01-15 19:53) [3]

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

И все-таки вопрос не получается разрешить.

По Accessу все должно присваиваться, а по BDE ничего не происходит.

Может есть у кого мысли.

И еще один вопрос из области тупизма:

Опять запрос:

SELECT L0.NPP L0.C_KATL FROM L0
WHERE L0.C_KATL=[x];

Тож проще простого. Но дело в том, что если, к примеру, вместо [x] ставить трехзначное число то запрос работает, если ставить 2значное то не работает.
Формат поля: Тип - Numeric; Размер - 3.

Пробовал и с нулем впереди писать т.е. пример: 081
Эффекта нет. :(

Может я чего не знаю.

← →
Anatoly Podgoretsky © (2005-01-15 20:24) [4]

Забудь ты про Акцесс, раз работаешь с LocalSQL

← →
Mortal (2005-01-15 20:28) [5]

Понятно. Может кто знает где найти что-нибудь почитать про него.
на случай если ща сам ничего не найду.

← →
sniknik © (2005-01-15 20:35) [6]

запрос конечно бредовый (это про [1]), для аксеса синтаксис немного другой (не знаю чего у тебя в аксессе все в лучшем виде) там должно быть так
UPDATE reg INNER JOIN L0 ON reg.NPP=L0.NPP SET reg.C_KATL=L0.C_KATL
не знаю как это с BDE пройдет...

> еще один вопрос из области тупизма:
> Опять запрос:

> SELECT L0.NPP L0.C_KATL FROM L0
> WHERE L0.C_KATL=[x];
кавычки [] зачем? все что в них воспринимается как нестандартное имя поля либо параметра. у тебя же в них значение (число). зачем? (возможно (есть такой вариант) BDE преобразует внутренности кавычек к строке (или другой кто в цепочке подключений), тогда ноль (081) нужно заменить на пробел (непонятно правда с какой стороны) ( 81) или (81 ), лучше конечно их просто убрать)

> Может я чего не знаю.
ничего. можно сказать? ;о)

← →
Mortal (2005-01-15 22:13) [7]

[] это я хотел показать образность переменное.

никаких [] я не использовал, хотя и с ними пробовал.

← →
sniknik © (2005-01-15 22:31) [8]

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

← →
Mortal (2005-01-16 00:09) [9]

ошибки-то нет.

какая-то проблема с 2значными числами. Ща попробую еще как-нибудь их записать.

← →
Mortal (2005-01-16 00:34) [10]

Заработала машина.
Заменил 81 на 81.0 и все получилось.
И вопрос на миллион почему трехзначные числа работали и без десятых.

← →
Johnmen © (2005-01-16 01:24) [11]

Тип поля C_KATL ?

← →
sniknik © (2005-01-16 09:33) [12]

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

> И вопрос на миллион почему трехзначные числа работали и без десятых.
т.к. инфы о структуре используемых таблиц нет то только как предположение
поле которому присвоение (к примеру) Char(3), откуда присваивается Double, значит будет неявное преодбазование типа (сам то не поставил)
берем для примера (на MSSQL, удобнее) преобразование
SELECT CAST(81.0 as Char)
получаем "81.0 " при присвоении этого короткой строке будет "обрезание" до 3 (в нашем случае - Char(3)) символов итого туда попадет "81."
теперь трехзначное SELECT CAST(811.0 as Char)
в итоге после описанных преобразований будет "811"
при сравнении опять если стоят разные типы будет преобразование... тот же CAST(81 as Char) из целого числа (integer) даст итог "81" а сравнивается с "81."

да чуть не забыл, письмом выслал адрес счета для милиона. ;о)

← →
Mortal (2005-01-16 10:16) [14]

Умно.

тип поля Double (Float). Size: 3.
Видимо так оно и есть. Видимо и при сравнении он рассматривает не как число, а как набор 3 символов.

Хотя ради эксперимента попробовал выбирать число 81.1 и совпадений он не нашел. Значит все не так.

Так что миллионный вопрос остается открытым :)

> тип поля Double (Float). Size: 3.
другое дело, это не стринг
для типов с плавающей точкой, операции на точное сравнение могут не работать (в зависимости от числа, вернее от разрядной маски, если входят получится нет то тогда неопределено, смотря как интерпретируется часть которая не в переменной а записана непосредственно) вообще найди почитай про числа с плавающей запятой (на королевстве есть например)

p.s. информация опять недостаточная т.что и это может неподходить к твоему случаю (чтото еще влияет), вообще если хочеш ответов пиши так подробно чтобы по описанию можно было повторить ситуацию. (тест сделать)

Да ладно. Вопрос то уже решен. Пусть не получил достойного научного объяснения, но мы люди приземленные нам важен результат.

http://www.delphikingdom.com/asp/viewitem.asp?UrlItem=/helloworld/reals.htm

чего должно быть "достойно" научное обьяснение в форуме? нобелевской премии?

по моему оно чаще всего адекватно вопросу.

Помогите с SQL запросом. Найти похожие ветки