Re: Another angle on this....

My comments, barbs, interspersed below.

Daniel Morgan

Tom McClelland wrote:

> Your points are valid, I don't contest them. However as someone coming
> from SQL Server to Oracle I have faced the following significant (to
> me) irritations:
>
> 1. Empty strings turned into nulls. Empty strings per se are not
> supported

What's your point? Those going from Oracle to SQL Server can complain about the exact opposite. So they are different ... so what? Did you think Oracle was SQL Server with another company name on the CD? Do you think that everything Microsoft does is the "standard" to which everyone else must adhere? Do you think that because you learned SQL Server first somehow that makes it better? Good grief. If I followed that logic I'd be whining about things being different than they were in Fortran IV.

>
> 2. Quoted identifiers are case sensitive, just what you need...

BFD
>
> 3. No support for identity columns, instead requiring programmers to
> create sequences and triggers to achieve effects that are trivial in
> other databases

Implementing a seqence takes 29 keystrokes. Count them ... 29 to create the sequence and add it to an insert statement. This is a lot of whining over 29 keystrokes. But go the other way ... I'd like to see you make your identity column count backwards by every third number and reset itself after every 300 inserts.

>
> 4. No option to ignore case on indexes or character-string comparison

BFD. It is that bloody painful to type UPPER()?

>
> 5. No support for comparison operators in arithmetic expressions

I'm not clear on what you mean by comparison operators. But I strongly suspect you are totally incorrect.

>
> 6. No support for "Case" notation

Wrong! I use CASE WHEN in much of what I write. Try RTFM.

>
> 7. Bugs in the ODBC driver which (in my case) make CLOBS unusable, so
> I have to rely on varchar2(4000)

Try an ODBC driver from another company.

> 8. Out-of-the-box retrieval of multi-record datasets at 1/40 the speed
> of SQL Server in my (highly optimised) ODBC usage (SQLBindCol,
> multi-record Chunked retrievals, etc)

Then you don't have a clue what you are doing.

> I know that there are work-arounds for some of these "features". And I
> understand that Oracle is a great tool for those wanting to store vast
> quantities of data. A competitor to SQL Server for those just wanting
> to store a few million records and have a thousands of transactions
> per day, with less than 50 permanent users, it ain't, IMHO.
>
> Ducks back into large concrete bunker and dons flameproof suit <G>
>
> Regards

What your list clearly indicates to me is that you are totally clueless as to what Oracle is. Let me give you the reverse complaint list. One for which there is no work-around in SQL Server.

1. No multiversioning.

Didn't need any others. That one is more than enough. When you figure out how to code around that in TransactSQL let Bill Gates know.

BTW: When the developer of the Jet engine left Microsoft and started his own company two or three years back his database platform of choice was Oracle on Linux. I guess he didn't know as much about it as you.

Daniel Morgan Received on Mon Feb 18 2002 - 12:15:59 CST