Subject Re: zip code distance calculation
Author irajoel2000
Finally got it to work like this:
Instead of using parameters I used variables and built the query.
works like a charm.

lat = 12.123
lon = -74.9876

q.sql = [SELECT (69.1*(]
q.sql = q.sql + lat
q.sql = q.sql + [-LATITUDE))*(69.1*(]
q.sql = q.sql + lat
q.sql = q.sql + [-LATITUDE))+(69.1*(]
q.sql = q.sql + lon
q.sql = q.sql + [-(LONGITUDE))*COSINE)*(69.1*(]
q.sql = q.sql + lon
q.sql = q.sql + [-(LONGITUDE))*COSINE) ]
q.sql = q.sql + [AS DISTANCE, NAME, NAME2, CONTACT, ]
q.sql = q.sql + [ADDRESS1, ADDRESS2, CITY, STATE, ZIP, ]
q.sql = q.sql + [PHONE, EXT, HOTLINE, FAX, INTERNET, WWWEB,
LATITUDE, ]
q.sql = q.sql + [DESCRIPT, WEBTYPE, WEBSITE, CLOSED, IDNUM,
LONGITUDE, ]
q.sql = q.sql + [TYPE1, EDATE, GIVE_ADDR, NOTE, COSINE FROM
WEBDATA ]
q.sql = q.sql + [WHERE WEBSITE = 'Y' ]
q.sql = q.sql + [ORDER BY WEBTYPE, DISTANCE, NAME]
q.params["var3"] := date()-540

Thanks. One more question. Is there a way to retrieve the date and
time that a particular firebird table was last updated (written to)?





--- In firebird-support@yahoogroups.com, Helen Borrie <helebor@...>
wrote:
>
> At 02:04 PM 10/01/2009, you wrote:
> >Helen -
> >
> >thanks for patience on this, but I'm guessing that variables
within
> >an "AS" clause is not supported in my programming environment. I
> >simplified the equation for testing purposes.
>
> I really don't know what you mean by an "AS" clause. In this
context the keyword AS is an optional marker for a derived field.
>
>
>
> >For instance this works;
> >
> >SELECT (69.1*(40.1-LATITUDE)) AS DISTANCE, NAME FROM WEBDATA
> >
> >and this works
> >
> >SELECT (69.1*(40.1-LATITUDE)) AS DISTANCE, NAME FROM WEDATA WHERE
> >EDATE = :var1
>
> So far, this is good syntax...
>
> >params["var1] = date()
>
> But this is not.
>
> I can't guess what syntax you are attempting here. In
ObjectPascal, as long as EDATE is a column in WE[B]DATA, an
assignment statement to a date type must be cast, using AsDate or
AsDateTime. In some Delphi interfaces you can refer to a parameter
via its array of names, if it is supported, but that has nothing to
do with Firebird.
>
> So, assuming you are using the Delphi Date function here (which is
unwise, though it serves for the example), you would need
> Params['var1'].AsDateTime := Date;
>
> or Params['var1']->AsDateTime = date() for CPPB I guess.
>
> It's unwise because you cannot guarantee that the local client's
system date is in synch with the server's date. You should always
use the server's context variables or the special date literals to
get that date (or timestamp). Read the book!
>
>
> >BUT this does not work
> >
> >SELECT :lat1-LATITUDE AS DISTANCE, NAME FROM WEBDATA
> >
> >The above line throws off an -802 error
>
> The -802 errors are to do with data type/size mismatches. So look
at the possible return values from that calculation for overflows,
etc.
>
> What you *could* try is treating the parameter argument itself as
though it were a sub-expression, e.g.
> SELECT ((:lat1) - LATITUDE) AS DISTANCE, NAME FROM WEBDATA
>
> But it will still give you an -802 if the parameter and the column
have incompatible *SQL* data types or the calculation results in an
overflow.
>
> >I'm wondering if a stored procedure could be used to generate the
> >rowset.
>
> Sure it could. And in your case it could be quite instructive if
you include some exception handling. It would help you to get your
head around why these exceptions are happening.
>
> At the same time, you're really not saying anything about the
environment: you're leaving others to guess about it. You seem to
have the SQL language confused with the client-side language: you
seem to need to do more research about how your DA components handle
database types. We don't know what data interface you're trying to
use; we don't know what versions anything you are using (and this
really does matter!) - server, client, database on-disk structure
(ODS), SQL dialect of the database, BDE version (if {{{shudder}}} you
are using the BDE) or versions of Firebird-friendly DACs that are too
old...etc...
>
> >thanks for patience on this,
>
> I've done my bit and gone past what's on-topic for this list (which
is blatant abuse of power, since I'm the list moderator!) I'll
leave it for others now.
>
> ./heLen
>