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

I know you are just looking for a quick answer to your question. But in the end of the day, what Richard said stands. All the reporting requirements you indicated are not really relavent to the question that you asked. You are basically asking if your codes can be RDBMS independent. The answer is no.

The small picture. SQL server temp table is created on the fly and diappears entirely when the session terminates. ORACLE temp table is not temporary at all. It is the data in the temp table that is temporary. So typically, if you do want to use it, you create them beforehand so that many users can use the same temp table. You can not create them dynamically the way you do it with SQL server. ORACLE can only have one copy of that temp table, so you can not have 2 sessions trying to create the same temp table dynamically.

The bigger picture. You can minimize the RDBMS dependency of your codes, but you can not eliminate it entirely. The OLEDB driver that you choose plays a big part in the equation. I would say start thinking globally, like whether to place your codes in the RDBMS and call them via stored procedures.

I bet programmers would really like to be able to access RDBMS like a it's black box. Just plug it in and forget about what's going in on in there. That's not gonna happen anytime soon. May never happen. I think the day it happens is the day when the DBA title disappear for good from the IT world.

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 - 16:02:47 CEST