[thelist] ASP/SQL Solution for Double Currency Web Site

[Michele Foster]

Rudy,

This sounds good.. need to do some testing on my end..

Quick question, can I *still* use WHERE clauses and this SELECT statement
harmoniously?  I had only posted the SELECT of the SQL statement ..

The current situation .. is building the SQL statement based on the items
selected in the form (search page).  So, there are a few IF's and ENDIF's
required in order to string the SQL statement before actually processing it.
Which creates my WHERE clause(s) as required, followed by my ORDER BY

Am I still ok with your SELECT method?

One last thing .. you are saying let SQL handle the mathematical function
and NOT the ASP eh?  Didn't realize I could perform mathematical functions
within the SQL.. that's bloody sweet.  Could have used THAT knowledge more
than once in the past.  <G>

Thanks,

Michele

From: "rudy" <r937 at interlog.com>

> > this will require me to make a second call to the DB to get
> > this value out.. I think.  I don't believe I can use an "AND" within
> > a SELECT statement in SQL, but I could be mistaken on this.
>
> not a second call, no
>
> yes, sql does have an AND, but you're looking for a table join
>
> here's your current select statement --
>
>    SELECT Stuff, Price
>        FROM ceramics
>
> here it is with a table join to the OOAK record shown above
>
>    SELECT Stuff, Price,
>         Price * theRate as USPrice
>           FROM ceramics, USexchangeRate
>
> hey, where's the WHERE clause?   i am sure you must be wondering
>
> usually, tables are joined with a WHERE clause (or ON condition) that
> specifies which rows of table 1 get joined up to which rows of table 2
>
> when the join condition is missing, *every* row of table 1 gets joined
with
> *every* row of table 2
>
> in your case there is only one row in the USexchangeRate table!!  think
> about which rows from the ceramics table you will get back   ;o)
>

> note the absence of a WHERE clause indicating which rows to update, so all
> of them will be updated -- but there's only one row!!  (you'd have to use
a
> different approach if you were timestamping your rates)