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

From: Daniel Morgan <dmorgan_at_exesolutions.com>
Date: Fri, 30 Aug 2002 18:16:15 GMT
Message-ID: <3D6FB654.950CA9CF_at_exesolutions.com>


kgoff_at_worldnet.att.net wrote:

> 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

Sorry to be harsh but apparently you are hard of reading. Richard gave you the best possible advice. If you choose to ignore it then do so at your own peril.

You will build an application that corrupts data, has poor performance, doesn't scale, is insecure, your competition will eat you alive, and you will deserve to take your project and your company to the unemployment queue.

The fact that you want to use a single code basis is your business. But what you need to understand, clearly and concisely, is that except for the fact that it sounds good in theory ... IT DOES NOT WORK!

And just so you know ... if you worked for me ... (note the use of the past tense "ed" on word "work") ....

Daniel Morgan Received on Fri Aug 30 2002 - 20:16:15 CEST

Original text of this message