Re: L:ist - Can do/do better in MS SQL than Oracle

Imbedded comment-

tlam15_at_hotmail.com (tingl) wrote:

>I think what you are talking about here have more to do with
>implementation and design differences rather than missing features. I
>was talking about some things that can be done in one database just
>flat out cannot be done in another in any way.
>
>> Oracle does not like mixed-case for tables and fields. (Lots
>> of tools can not handle this).
>
>I am not sure what kind of tools you are using. I have no problems
>with mixed case. Even it is a problem, it is just a matter of style.
>It would be silly to say Windows file name being not case-sensitive a
>missing feature.
>

If you create an Oracle table with some tool that allows the table names and field names to be created in mixed-case( some ETL tools, Access etc) ( or with a Create table "Mixed_Case_Name" ( "Field1" varchar2(10) , "Field2" varchar2(10) ) statement )
then to use SqlPlus ( for example ) to access that data you would need to use "s around the table_name and field name.. select "Field1","Field2" from "Mixed_Case_Name"

This is a problem unless you are aware of it...Not big, but sometimes annoying...

>
>benbrugman_at_onbekend.nl (Ben Brugman) wrote in message news:<3ca9d8d1.32919890_at_news.nl.uu.net>...
>> On 28 Mar 2002 12:52:44 -0800, tlam15_at_hotmail.com (tingl) wrote:
>>
>> Well I have seen a few things you can't do in Oracle which you can
>> in SQL-server.
>>
>> Use serializable and expect the transactions te be serializable.
>> (Yes Oracle does prefent the phenomena's discribed in SQL-92,
>> but I can come up with transactions which can not be serialized
>> if run together on Oracle. And serializable means that there must
>> be a garantee that all finished transactions should be serializable).
>> example see the further on ##
>>
>> Some SQL-92 syntax queries where outer and inner joins are
>> used in one query could not be expressed in the Oracle syntax
>> without going to a completely different query.
>>
>> Oracle does not like mixed-case for tables and fields. (Lots
>> of tools can not handle this).
>>
>> I do not want to go into the discussion which is better, but there
>> are differences between the two RDBMSses. And I expect that
>> anything which can be done on the one can one way or the other
>> be done on the other. But some things involve a lot of work in
>> one RDBMS and hardly any work in the other.
>> My guess is this works both ways.
>> (Try to implement a after/row trigger from Oracle in SQL-server).
>>
>>
>> ben brugman.
>>
>>
>>
>> ##
>> Please do not read on if you are not interrested in the
>> serializability discussion. This has been handled before on
>> in several discussion groups.
>>
>> Serializable, standard example where the serializable of Oracle fails.
>> Two accounts, with the business rule that the accounts together can
>> not become sub zero. Withdrawels are done with writing extra
>> information into the database (add a withdrawel row).
>>
>> Sequence:
>> Set serializable
>> Start transaction
>> Read the amount available on the two accounts.
>> See if there is enough money to do the withdrawel.
>> Add the extra row for the withdrawel
>> Commit.
>>
>> If this sequence is run concurrently (2 times) then it can result in a
>> situation which can not happen if the sequence is run serialized (2
>> times).
>>
>> For a more formal explenation see :
>> Making Sapshot Isolation Serializable
>> http://www.cs.umb.edu/~isotest/snaptest/snaptest.pdf
>>
>>
>>
>> >Hi,
>> >
>> >I have worked with both SQL Server and Oracle. I have not seen
>> >anything you can do with SQL Server that can't be done in Oracle. The
>> >only advantage of SQL Server is ease of management and configuration.
>> >It requires little attention most of the time, but the trade off here
>> >is flexibility. With all things taken into consideration, I still
>> >prefer Oracle to SQL Server. The main reasons are portability and
>> >scalability. And most of all we do not want to be locked into any
>> >single vendor.
>> >
>> >
>> >Tony
>> >www.w3base.com
>> >
>>
>> Ben Brugman
Received on Thu Apr 04 2002 - 12:44:49 CST