🚀 go-pugleaf

"Heinz Ketchup" 
<heinz_like_the_ketchup@h0tmail.n0spam.c0m.n0spam> wrote in 
message news:43fb7f38$1@newsgroups.borland.com...
>
> I Apologize if this is a stupid question, but I haven't had
> any success thus far on resolving this issue.
>
> I have a TADO query setup at design time with a SQL Statement
> and Parameters.
>
> When I assign the Parameters based on the design time query
> everything works peachy clean.
>
> // Perform SQL Operations
> QueryPointer->Close();
>
> QueryPointer->Parameters->ParamByName("StartDateTimeString")->Value 
> = StartingDateTime;
>
> QueryPointer->Parameters->ParamByName("EndDateTimeString")->Value 
> = EndingDateTime;
>
> QueryPointer->Parameters->ParamByName("TagNameQuery")->Value = 
> TagNameString;
>
> QueryPointer->Open();
>
> Do stuff with the dataset.
>
> The SQL Statement is
> SELECT tagName, timeString, curVal, offset
> FROM DBA.vwAccumMinute
> WHERE (tme >= :StartDateTimeString) AND (tme <= 
> :EndDateTimeString) AND (tagName = :TagNameQuery)
> ORDER BY tme
>
> On the Down Side:
> When I manually create the SQL Text:
> The error I get is a type mismatch.
>
> QueryPointer->Close();
> QueryPointer->SQL->Clear();
> QueryPointer->SQL->Text = SQLStatementString;
> QueryPointer->Open();
>
> ...
> SQLStatementString =
> "SELECT tagName, timeString, curVal, offset
> FROM DBA.vwAccumMinute
> WHERE (tme >= '1138778100' AND tme <= '1138863600') AND 
> (tagName = 'Tag1') ORDER BY tme
>
> On the analysis of both SQL Statement's, they appear identical.
> The process I use is just a little different.
>
> The reason I am doing this is to see if I can use the same 
> Query with a "modified" sql statement.
> i.e. SELECT tagName, timeString, curVal
> blah blah blah...
> WHERE (tagName = 'This' or tagName = 'That' or tagName = 
> 'Meep')
>
> Any assistance is HIGHLY appreciated.
> PS: Code is in the correct order and compiles fine.
> I'm just trying to get across my problem, so please don't take
> the represented code line by line.
>
> Thank you v. much,
> Heinz

Hi Heinz,

My guess is that the problem is in:

WHERE (tme >= '1138778100' AND tme <= '1138863600') AND (tagName 
= 'Tag1') ORDER BY tme

Those numbers don't look like any valid date/time format to me. 
I'd suggest using parameters as you did with the design-time SQL 
statement.  In fact, I suggest you always use parameters for best 
efficiency and to make sure you don't have to escape quote 
characters out of literal strings.

- Arnie 

"Arnie" <none> wrote:
>
>Hi Heinz,
>
>My guess is that the problem is in:
>
>WHERE (tme >= '1138778100' AND tme <= '1138863600') AND (tagName 
>= 'Tag1') ORDER BY tme
>
>Those numbers don't look like any valid date/time format to me. 
>I'd suggest using parameters as you did with the design-time SQL 
>statement.  In fact, I suggest you always use parameters for best 
>efficiency and to make sure you don't have to escape quote 
>characters out of literal strings.
>
>- Arnie 

Hi Arnie,

Thanks for the Feedback! Greatly Appreciated.
I think it'd be nice to pass in parameters to, but with
a changing "WHERE" clause, it seems the TDataModule I have
would get muddled.

I did manage to track down, though not completely understand
why one process works and not the other. More or less,
it's an educated guess.

It came down to the way the DB fields were structured.

The DB Table has fields as strings,
and a VIEW, I "SELECT" from refers to this DB Table.
Strangely, in the view it does Date Mathematics on the string
fields (which is a date in string format), and the final result
is it returns a date (which is correct based on the math). 

The numbers are a calculated date in UTC seconds.

That was what was killing the Query. 
So I type casted the "View" to return the Date as a String, 
and it works fine now. 

I guess it's a DB thing where it is flexible with 
field type conversions with in the database software, and doesn't do the same when it's coming from my code, as it must be a defined type.

Well... at least it works now.

Thanks,
Heinz