Re: Will the following code run when connected to Oracle?

Hi Kevin,

Everytime I hear a single application must support multiple database versions, the fine hairs at the back of my neck all stand up. Spooky ;)

OK, a few suggestions.

Check out the link I gave you previously, check out the SQL Reference manual and research exactly what is an Oracle temporary table, the required syntax (CREATE GLOBAL TEMPORARY TABLE temp1 ...) and determine if Oracle's temporary table solution is even close to what you're after. Even if it is, it's best to precreate the table first, then use the ON COMMIT DELETE ROWS options to automate the cleaning out of data.

But believe me, in Oracle it's all unnecessary.

I'm not entirely sure how the user selects the required accounts and products but you should either be able to query the required tables directly, or use dynamic SQL to build the required queries as necessary.

Trust me (which I always told my patients before the rather unfortunate mal-practice suit), read the Oracle Concepts manual. It's essential reading for anyone new to Oracle. Also highly recommended is the Thomas Kyte Book 'Expert One on One: Oracle' which is a great introduction to the Oracle world for SQL Server persons.

Good Luck

Richard
<kgoff_at_worldnet.att.net> wrote in message news:14Eb9.1427$jG2.96165_at_bgtnsc05-news.ops.worldnet.att.net...
> Richard,
>
> While I appreciate your response, you really didn't answer my question.
Let
> me try this again.
>
> We have a vertical market app, written in .NET. We sell the app to
> manufacturers. Most use SQL Server, though we are running into some
> potential customers who use Oracle. Our app must support both databases.
>
> We have a reporting module, where an end-user can run many different
reports
> based on certain accounts/products. The user might pick 1 account and 10
> products, he might pick 20 accounts and 20 products....or maybe 50
accounts
> and 2000 products. The software must query the invoice tables in the
> back-end database against what the user selected. There may be dozens
of
> users doing the same thing at the same time.
>
> So the application needs to collect the user selections for
accounts/items,
> build temporary tables in the back-end database that represent the list of
> accts/items that the user selected, and then run a SQL statement that
joins
> the back-end invoice table with the account/product temp tables that,
again,
> represent what the user selected.
>
> The code that I posted represents a stripped down version of what we need
to
> do. It isn't 'SQL Server' logic...it represents the only way that I know
to
> address this reporting requirements. Much of our reporting requirements
> involve things that are variable at run-time. So my question is...will
this
> code run without modification when connected to SQL Server, or is the
syntax
> for creating temp tables a bit different?
>
> If you know of a better way to address this reporting requirement, I'd be
> very interested to know what it is.
>
> Kevin
>
>
>
> Kevin
Received on Fri Aug 30 2002 - 14:51:03 CEST