Newbie transiting from VBA to TSQL, using SQL Server 2005 Enterprise:

Need help to do this:

Open Table_A

WITH TableA
DO UNTIL .EOF
Read value from TableA.ColumnA
Run SQL Statement on TableB based on value
Move to the next record
LOOP
END


How do I do this in TSQL?

Thanks,
Bubbles

bubbles (bubbles.one (AT) hotmail (DOT) com) writes:
It is not unlikely that this is a single SQL statement, but it depends on
what operation you intend do to on TableB. Assuming that the operation
is "Give me the total order sum for each customer", the query in Northwind
is:

SELECT C.CompanyName, SUM(OD.Quantity * OD.UnitPrice)
FROM [Order Details] OD
JOIN Orders O ON OD.OrderID = O.OrderID
JOIN Customers C ON O.CustomerID = C.CustomerID
GROUP BY C.CompanyName

A very important lesson of this is that the mindset in SQL is completely
different from a client language.



--
Erland Sommarskog, SQL Server MVP, esquel (AT) sommarskog (DOT) se

Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/pro...ads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodinf...ons/books.mspx

Thanks for the reply.

What I need to do is this:

Every night I pull data from a likned server. This is an automated
job.


TableB contains millions of records with the details of transactions
on the products.

I want to loop through TableA's values (product names) to generate and
run a series of
SQL statements with these value so I can generate various analyses.

Thanks,
Bubbles



On Mar 29, 3:22 pm, Erland Sommarskog <esq... (AT) sommarskog (DOT) se> wrote:

bubbles (bubbles.one (AT) hotmail (DOT) com) writes:
First lesson in SQL: stop think in loops. The normal approach is that you
handle all data at once as in the query that I showed you. There are
exceptions when looping may be called for, or may be the best solution,
but nothing you have said this far, indicates that this would be necessary.

Since I don't know what the queries against TableB look like, I cannot
assist more than with the example I provided. I forgot to mention that
it runs in the Northwind database. (Which does not ship with SQL 2005,
but is on SQL 2000, and can be downloaded from Microsoft.com.)




--
Erland Sommarskog, SQL Server MVP, esquel (AT) sommarskog (DOT) se

Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/pro...ads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodinf...ons/books.mspx

On Mar 29, 8:10 pm, Erland Sommarskog <esq... (AT) sommarskog (DOT) se> wrote:


Thank you for your patience.
Here is the whole deal:

01. Download tblWarrantyCalls, tblDeliveries, tblReplacements

02. Append tblReplacements to tblDeliveries

03. Merge tblWarrantyCalls, tblDeliveries into tblCalls (based on
certain criteria)

04. Generate a product list tblProducts from tblCalls

05. Using the product list, run queries against tblCalls such that
the following analyses are generated into different tables
(tables created on the fly).

Each product will cause about 20 tables to be created (deleted
and
re-created at each run of the job) with various analyses.

These tables are then linked to front-end Microsoft Access
applications
that present the data both graphically and in the raw (if
required).

This process saves users a lot of time, as they will not need to
run queries
against a humongous database. All required analyses are already
pre-generated.
Even raw data for each product are seperated into their own
tables, so running
queries against them are much faster.

Question:
1. Is this a good strategy?
2. How to achieve this in TSQL?

Thanks!
Bubbles

Solved this problem using cursors.
Thanks!



On Mar 29, 8:10 pm, Erland Sommarskog <esq... (AT) sommarskog (DOT) se> wrote:

bubbles wrote:

Which works, but is slower and more complex than set-based
operations. Sometimes it's necessary (e.g. sending e-mails,
generating PDFs); more often it isn't. In your particular
case, "running [Access] queries against a humongous database"
shouldn't be a problem if you use proper indexes.

bubbles (bubbles.one (AT) hotmail (DOT) com) writes:
If the table indeed have different layout depending on product, you
would indeed have to loop, for instance using a cursor as you discovered.
But if all sets of tables have the same layout, you should probably have
one single set of tables instead, and in this case there would not be any
need for loops.


--
Erland Sommarskog, SQL Server MVP, esquel (AT) sommarskog (DOT) se

Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/pro...ads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodinf...ons/books.mspx

Thank you for your reply.

The tables are in fact seperated by products, as each set of product-
specific data are handled by
different engineers. These sets of data need to be sliced and diced
into various analyses, and the
engineers would also need to dive into raw data for some of their
work.

Because these product-specific data sets are large (several million
records each), I thought that
perprocessing and seperating them into their respective tables would
help the engineers access
their analyses and data faster.

In any case, I have already done the needful and have had the required
tables generated.

Thanks!
Bubbles




On Mar 31, 5:33 am, Erland Sommarskog <esq... (AT) sommarskog (DOT) se> wrote:

bubbles wrote:

This would probably still be better handled using a single table,
including the separating column(s) in indexes as appropriate - though I
understand the limited motivation for applying further development
effort to a system that does work.

You could save the engineers the trouble of remembering an extra WHERE
clause by providing each of them with a set of views, along the lines of

create view TheTable_eng1 as
select *
from TheTable
where some_column = 'eng1'