T-SQL functions in ORACLE

Question

Use T-SQL functions in ORACLE too, so you can write one script version that works in SYBASE, SQLSERVER and ORACLE when need to use the following functions:
ceiling, charindex, dateadd, datediff, datename, datepart, day, db_id, db_name, getdate, host_id, host_name, left, len, month, replicate, right, space, str, str_replace, stuff, substring, suser_id, suser_name, user_id, user_name and year.
The file [comp_tsql_ORA_schema.txt|http://forums.databasejournal.com/attachment.php?attachmentid=564&d=1258547015] creates the tablespace and schema to put the objects, and the file [comp_tsql_ORA.txt|http://forums.databasejournal.com/attachment.php?attachmentid=569&d=1259256898] creates the functions into the new schema. They will be avaliable for any schema of the oracle instance.
Hope this help!
Any suggestion please contact.
aklein2003
Edited by: user1958693 on 26/11/2009 10:16

Answer 1

jgarry wrote:
J2EE beta released around 1999. Religious programming wars far preceded that. Here's but [one example|http://groups.google.com/group/comp.lang.lisp/browse_thread/thread/1c50bc13e9302f00/34bb8f3ac77e2388?q=programming+language+religion#34bb8f3ac77e2388] from a quick google. I'm no longer convinced that elegance is a desirable trait for a language. So call me a heretic.
Ever tried XLISP? :-)
It's different. Back then it was simply the language itself. And it was not really a religious kind of battle, but more a mine-is-bigger-and-better-than-yours one.
With Java, it is all about The Acrhitecture and the blessed language of Java. ;-)
I wouldn't so much blame J2EE believers for that. I think there is a fundamental complexity to web type paradigms that hasn't been described in a precise and encompassing enough manner to enable correct project planning.The basic problem is that the database is treated as a persistent storage layer only. A bit bucket. And that is exactly what a database is not.
But as it is used that, loads of database features now need to be duplicated in the application layer. Which is done. Very poorly.
Heck, I've even been told that J2EE's 3-tier architecture is not client server. Such ignorance is really unbelievable. Or is it pure stupidity?Until you just made me look it up, I would have thought that too, I'm sure I saw client/server defined as two-tier in the last century. But I have much more stupid misdefinitions to deal with on a daily basis, simply from the multiplicity of paradigms. I tend to retreat into my shell. Hehehe. Know that feeling... These days I rather run away, or set shields to full power, than try to get in yet another frustrating, fruitless and futile discussion with a Java head about the wonders of the J2EE architecture. Or trying to explain that this "new" architecture is predated with what we used in the 80's on mainframe systems with transaction monitors, block devices (the 80's web browsers) and databases - which software layer for software layer was almost identical to "+The Great Architecture+" of today. (and we did it without buzzwords too) ;-)
Client-server is a software architecture and in essence describes 3 basic software components. The User Interface (UI), the Application (APP) and the Database (DB). And there are various ways to put these components together in a client-server architecture. The mistake that the Java fanbois make is thinking that client-server means having the client as the UI and APP as a single component (so-called fat client) and then the DB component as the server.
There are numerous versions of these - including the APP component being a server component (as we now these days more commonly used in over the web).
My beef with the J2EE "+religion+" always has been that client-server is client-server. The fundamentals stay the same.