TQuery и или ключу или лыжи не едут

← →
testpu (2002-07-25 10:27) [0]

Программировал на C#, нарадоваться не мог, только проги сильно тяжелые получаются и на P-100 тормозят жутко.
Решил перейти на CBuilder, столкнулся с проблемой.
Запрос:
SELECT * FROM DTable WHERE DTable.[Id]=@Id
В C# я так и передавал @Id, а в CBuilder надо чтобы было написано
SELECT * FROM DTable WHERE DTable.[Id]=:Id
Мне что теперь все запросы переписывать?
Локальные то перепенные должны быть с "@"
DECLARE @local int SEY @local=1
SELECT * FROM DTable WHERE DTable.[Id]=:Id AND DTable.[Field]=@local
Или у VCL - левцев не принято параметры в запрос передавать.
Подскажите, пожалуйста как быть. Мож у кого компонент есть нормальный, чтоб на Transact-SQL запросы понимал.

← →
kaif © (2002-07-25 13:00) [1]

Я не силен в С, но по-моему, дело в том, что параметр объекта TQuery это тоже объект, а не просто локальная переменная. А синтаксис с двоеточием вообще не С-шный, это синтаксис парсера SQL-запроса внутри компонента TQuery. Если я правильно понял вопрос...

← →
testpu (2002-07-25 13:07) [2]

Ну понятно, что это TQuery так запрограммирован. Но как другие программеры с этой проблемой борятся. Неужели в Delphi вручную запросы делают? Я в Sql analizere отлаживаю, а потом делаю Query.SQL.LoadFromFile(XXX.sql) да и все, а теперь вся моя технология на смарку.

← →
SergSuper (2002-07-25 14:41) [3]

Интересно: а как же тогда C# отличает локальные переменные от параметров запроса?

← →
Lord Warlock © (2002-07-25 14:45) [4]

> testpu (25.07.02 13:07)

> Неужели в Delphi вручную запросы делают?

В основном. И параметр пишется :ID вне зависимости, dephi или Cbuilder

← →
testpu (2002-07-25 18:20) [5]

>Интересно: а как же тогда C# отличает локальные переменные от параметров запроса?

А я те, которые не локальные ремаркирую после отладки.

А еще в C# можно писать так:
string Stroka=@"
------
Сколько хочешь строк без двойных кавычек
Например весь SQL запрос
----
"; // Здесь только кавычки закрываются
А в Delphi есть что - то подобное, или надо обязательно
SQL.Add() делать?

← →
evgeg © (2002-07-25 22:00) [6]

> я те, которые не локальные ремаркирую после отладки.

Чего-чего вы делаете? Если я правильно понял, вы удаляете параметры вручную каждый раз после изменения запроса?
И это вы считаете удобным? Мне лично нахрен такие удобства не нужны.

← →
app © (2002-07-26 19:44) [7]

app © (26.07.02 19:33)

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

Оправдания кто первый начал и кто что сказал излишне.

комодератор

← →
testpu (2002-07-26 21:43) [8]

Ну все таки хочется объяснить. Тестируемый запрос:
USE Advertisement
-- Это все не локальные переменные
DECLARE @IdSubsection int SET @IdSubsection = 1
DECLARE @AllowSubsection bit SET @AllowSubsection = 0
DECLARE @AllowDate int SET @AllowDate = 0
DECLARE @NumberStart int SET @NumberStart = 5
DECLARE @NumberEnd int SET @NumberEnd = 7
DECLARE @DaysCount int SET @DaysCount = 5
DECLARE @MonthsCount int SET @MonthsCount = 1
DECLARE @DateStart datetime SET @DateStart = "4/01/98"
DECLARE @DateEnd datetime SET @DateEnd = "7/18/02"
DECLARE @Allowlocation bit SET @AllowLocation = 1
DECLARE @Location varchar(200) SET @Location = "223322"

-- Чтение информации об объявлении
-- А это локальная переменныя
DECLARE @Cmd varchar(8000)
SET @Cmd =
"
SELECT DISTINCT
Advertisement.*,
[SubsectionName] = Subsection.[Name],
[SectionIndex] = [Section].[Index],
[SectionName] = [Section].[Name]
FROM Advertisement
INNER JOIN Subsection ON Advertisement.IdSubsection = Subsection.[Id]
INNER JOIN [Section] ON Subsection.[IdSection] = [Section].[Id]
LEFT JOIN Location ON Location.[IdAdvertisement] = Advertisement.[Id]
LEFT JOIN Number ON Number.[IdAdvertisement] = Advertisement.[Id]
WHERE
" +
-- Если необходимо учесть раздел
CASE @AllowSubsection
WHEN 1 THEN "Advertisement.[IdSubsection] = " + CONVERT(varchar, @IdSubsection)
ELSE "1 = 1"
END
+ " AND " +
-- Если необходимо учесть раздел
CASE @AllowLocation
WHEN 1 THEN "Location.[Value] = " + CONVERT(varchar, @Location)
ELSE "1 = 1"
END
+ " AND " +
-- Если необходимо учесть даты
CASE @AllowDate
-- Интервал номеров
WHEN 1 THEN "Number.[Value] BETWEEN " + CONVERT(varchar, @NumberStart) + " AND " + CONVERT(varchar, @NumberEnd)
-- Количество дней от текущей даты
WHEN 2 THEN "Advertisement.[Date] BETWEEN DATEADD(day, -" + CONVERT(varchar, @DaysCount) +", GETDATE()) AND GETDATE()"
--
WHEN 3 THEN "Advertisement.[Date] BETWEEN DATEADD(month, -" + CONVERT(varchar, @MonthsCount) +", GETDATE()) AND GETDATE()"
WHEN 4 THEN "Advertisement.[Date] BETWEEN """ + CONVERT(varchar, @DateStart) + """ AND """ + CONVERT(varchar, @DateEnd) + """"
ELSE "1 = 1"
END +
"
ORDER BY [Date] DESC
"
EXECUTE(@Cmd)
----------------------------------------------------------------
Используемый запрос:
USE Advertisement
-- Это все не локальные переменные
/*
DECLARE @IdSubsection int SET @IdSubsection = 1
DECLARE @AllowSubsection bit SET @AllowSubsection = 0
DECLARE @AllowDate int SET @AllowDate = 0
DECLARE @NumberStart int SET @NumberStart = 5
DECLARE @NumberEnd int SET @NumberEnd = 7
DECLARE @DaysCount int SET @DaysCount = 5
DECLARE @MonthsCount int SET @MonthsCount = 1
DECLARE @DateStart datetime SET @DateStart = "4/01/98"
DECLARE @DateEnd datetime SET @DateEnd = "7/18/02"
DECLARE @Allowlocation bit SET @AllowLocation = 1
DECLARE @Location varchar(200) SET @Location = "223322"
*/
-- Чтение информации об объявлении
-- А это локальная переменныя
DECLARE @Cmd varchar(8000)
SET @Cmd =
"
SELECT DISTINCT
Advertisement.*,
[SubsectionName] = Subsection.[Name],
[SectionIndex] = [Section].[Index],
[SectionName] = [Section].[Name]
FROM Advertisement
INNER JOIN Subsection ON Advertisement.IdSubsection = Subsection.[Id]
INNER JOIN [Section] ON Subsection.[IdSection] = [Section].[Id]
LEFT JOIN Location ON Location.[IdAdvertisement] = Advertisement.[Id]
LEFT JOIN Number ON Number.[IdAdvertisement] = Advertisement.[Id]
WHERE
" +
-- Если необходимо учесть раздел
CASE @AllowSubsection
WHEN 1 THEN "Advertisement.[IdSubsection] = " + CONVERT(varchar, @IdSubsection)
ELSE "1 = 1"
END
+ " AND " +
-- Если необходимо учесть раздел
CASE @AllowLocation
WHEN 1 THEN "Location.[Value] = " + CONVERT(varchar, @Location)
ELSE "1 = 1"
END
+ " AND " +
-- Если необходимо учесть даты
CASE @AllowDate
-- Интервал номеров
WHEN 1 THEN "Number.[Value] BETWEEN " + CONVERT(varchar, @NumberStart) + " AND " + CONVERT(varchar, @NumberEnd)
-- Количество дней от текущей даты
WHEN 2 THEN "Advertisement.[Date] BETWEEN DATEADD(day, -" + CONVERT(varchar, @DaysCount) +", GETDATE()) AND GETDATE()"
--
WHEN 3 THEN "Advertisement.[Date] BETWEEN DATEADD(month, -" + CONVERT(varchar, @MonthsCount) +", GETDATE()) AND GETDATE()"
WHEN 4 THEN "Advertisement.[Date] BETWEEN """ + CONVERT(varchar, @DateStart) + """ AND """ + CONVERT(varchar, @DateEnd) + """"
ELSE "1 = 1"
END +
"
ORDER BY [Date] DESC
"
EXECUTE(@Cmd)

Как видите, легким движением руки за 1 сек. превращаем запрос из SQL Analizer в тот, который можно в проге юзать. И всего то для этого нужно, чтобы в TQuery переменные назывались не :X, а @X.
Неужели ни у кого такого компонента нет?

Мдя... Я лично всю бизнес-логику БД реализую в хранимых процедурах! Это очень удобное средство да будет вам известно! Тем более что MSSQL для этого даже есть очень много полезных инструментов, типа дебагера процедур, куаналайзер и т.д.
Но это мое личное мнение, его не обязательно придерживаться!

Почему вы просто не сделаете замену @ на :?
Search\Replace

Вообще-то просто testpu, как мне кажется, столкнулся со стандартной проблемой: попытка перноса старых (нет, не правильно: пригодных и удобных в предыдущей освоенной системе) средств на новую. где так нельзя/неудобно/несподручно и т.д. Стандартая проблема, сам переживал ее не раз.

По сути хотелось бы поддержать реплику evgeg © (26.07.02 23:38), которая и напрашивается вроде сама-собой после LoadFromFile, если уж так необходимо именно из файла. Вот только хорошо ли это с точки зрения скорости? Хотя если нужна гибкость без перекомпиляции - может и так хорошо.
Я вообще делаю так: отлаживаю запрос в QAnalizer, после чего copy/paste в необходимый TQuery. Хотя это только мое мнение.

← →
ppcat (2002-07-29 08:49) [12]

Послушай, testpu. Твоя проблема решается легко, а про Builder я вот что скажу - приехав в Англию будь добр говори по английски, так тебя лучше поймут.

Вместо Query.SQL.Add(...) можно написать Query.SQL.Text:= "...";
одной строкой получается. А если тебе все "@" на ":" заменить пришлось, StringReplace (в хелпе есть) тебе поможет. Вообще, в Борланде интересного и удобного не меньше, чем в Майкрософт, а может и поболее

TQuery и или ключу или лыжи не едут Найти похожие ветки