Where did you get #1? If you do not know how to do it, it does not mean that
Oracle can't.
--
Karl Westberg, MCP
Paul Mapstone wrote in message <365997B8.6B605638_at_t-mi.com>...
>After a gap of 8 years I recently had the misfortune to need to use
>Oracle for a while. It has come a long way with its performance, stored
>procs, triggers, PL/SQL in the server, etc. However, I noticed the
>following important facilities were still missing:
>
>1. Cannot do a DELETE with a join or correlated sub-query.
>2. No Sybase style temporary tables.
>3. Cannot easily create and use a table in a stored procedure, temporary
>or not.
>4. you cannot write a stored proc to return result rows (yes, I know you
>can return a REFCURSOR, but that is nowhere near as useful).
>
>I believe that 1-3 above are the reason why so much Oracle code requires
>cursors. Problem 4 results in a lot more SQL being embedded in
>applications, rather than in stored procedures, which makes tuning
>harder.
>
>> + PL/SQL is more powerful than TRANSACT/SQL
>No it isn't, it is just different (see above shortcomings) - stored
>functions are useful though, but Java in the db looks much better.
>T-SQL seems simpler to me, but maybe that is just familiarity.
>
>> + Row level locking been for years in Oracle, only recently in
>> Sybase.
>I can honestly say I have not found the lack of row-level locking to be
>a problem. I suspect that this is more of an issue if an application
>has been designed for Oracle, then ported. On the rare occasions I have
>needed this, I have just padded the row so each fits on a single page.
Received on Tue Nov 24 1998 - 00:00:00 CST
