SQL Server Adventures for the Oracle DBA

  • Comments posted here are about the content posted at temp

  • Well said and I am glad that you have got past the whole experience of being yelled at and gone to a place that appreciates you! I don't think yelling at other staff members is acceptable. I have worked with a programmer who couldn't program and my approach to that difficult situation was first to try and help them. When it became fairly obvious that they were not cut out to be a programmer I guess I tried to suggest they change career. Not like your case, howevwer, where you clearly are a competent developer.

    Thanks

    David 🙂

  • Good article, I still remember when I move from T-SQL to PL/SQL I found the SQL was so much difference. Luckly I use SQL Navigator which make things lot more simple. Now I still code in both SQL 🙂 Personally I like PL/SQL especially the CURSOR

  • Experience, experience, experience and a will to spend some time banging your head on the desk is what is required to do such a swap of working tools...

    After going through Oracle, SQL server and Sybase I think that is just a question of a few months missing it. After that is a piece of cake!

    Having a tough job teaches you a lot!! All good!

    Congratuilations with your new job, perseverance pays back!!

    Can be applied to programming languages, once you understand what it is important to learn first you will be ok!!

    Next step then is CLR C# ? ;P

  • Good story, sounds like you had fun...

     

    Btw you say "though in SQL 2000 there is array processing."  Perhaps I am being a little daft - but could you explain? 

     

    Cheers

    Wang.

     

  • Very nice article. I'm an Oracle person who's dabbled in SQL, yes, it does seem very true that SQL is not SQL (shhh, don't tell the recruiters (:=))

  • Array processing - before SQL Server 2000, you can only create temporary table, but now you can create an arrary.

    DECLARE arraryname TABLE (....)

    It is just liked creating a temp table but it does not take up space in Tempdb.

    You use the exact same command to insert data and select data but you don't have to delete it afterward.

     

     

  • ...though in SQL 2000 there is array processing

    This definitely stumped me!!!!!

    How come?

  • Good article, appreciate your writing about your experiences (sounds a bit tough, glad you survived).

     I think there is a need for more articles about the conceptual mapping: how does one do a job in SQL Server vs Oracle. SQL syntax is reasonably similar, but other operations are radically different. Most of my experience is in SQL server, but I am occasionally called on to do something in an Oracle instance and it can be a bit intimidating. For example I had to make an archive copy of an Oracle data model on the same machine under a different name (this was part of a third party application). In MS, I would simply do a .bak and restore it under a different name, but that does not seem directly mappable to Oracle. The way I finally did it in Oracle was a whole lot messier and I'm sure it's not the best way.

     

    ...

    -- FORTRAN manual for Xerox Computers --

  • Real nice article. It exactly mirrors reality. I worked

    in Oracle 8i very extensively almost 5 years plus. from 95 to 2000 probably. After that for the last 5 years I am working on SQL Server. Now I have to get back to Oracle 10g for my new job.

    same plight here.

     

     

  • I have had similar challenges but just the reverse.  I started in SQL Server 7 and had to work in Oracle 8i.  I have been burnt several times by the limited tools which Oracle provides and get frustrated with how much longer it takes to do the same things in Oracle.  I have been burnt by Oracle DBA Studio to change a password which never happened and looking up a constraint which Oracle DBA Studio displayed the incorrect fields which the constraint was on.  Oracles tools take forever to load, if they do load, as they have been written in Java.

    Oracle seems to work best if you do everything through SQL Plus but who has the time or the budget?  I really don't wish to bash Oracle and many people swear by it. I wish I could be one of them but I find myself swearing at it most of the time.

    I am glad you were able to turn your situation around and have a positive outcome.  It is helpful for an individual to work with more than one vendors database product.  You know more about the challenges and advantages of using one database over the other.

    Good Luck

  • I'm a bit divided on this one. On one hand, I think you should have quit your job the first day you were yelled at, I can't stand experienced (and very often not so experienced!) developers who refuse to teach anything to their less experienced peers. It's not like they were born experts.

    On the other hand, that painful experience forced you to learn things you probably wouldn't have even thought about if the DBAs were in charge of creating all tables/DTS packages/stored procs/etc. So in the end it was good for you, but was it necessary? I don't know.

    It all comes down to the age old debate between the people who think the best way to learn how to swim is through gradual lessons, starting at the shallow end of the pool and slowly moving to the deep end, and the ones who think the best way is to just throw you into a turbulent river hoping that your survival instinct will take over and force you to swim. Some will say the last method creates better swimmers, but others will point out that it will also drown quite a few.

  • I did SQL Server --> Oracle and now I'm back to SQL Server (3 jobs).

    I have no doubt that SQL Server would be but a footnote in database books if Oracle had taken the initiative to develop a user-centric front end for their dbms in the 90s.  I honestly never could figure out what they must've been thinking when I was working with Oracle.

    Thank God they didn't work on the front end.  I love sql server.

  • Regarding last post.... survival of the fittest!!!

    I prefer the crash course style, if you get thrown into a tough environment your learning curve is perfect!!

  • Ah, table variables.  Yes I see what you mean.  However, I should point out that they DO take up space in tempdb, and have a few other side effects.  eg You don't get statistics on table variables, which can lead to interesting things like no paralellism (ll?) in queries. 

     

Viewing 15 posts - 1 through 15 (of 17 total)

You must be logged in to reply to this topic. Login to reply