That speaks to what I've been seeing. Developers with an understanding of the db are getting harder and harder to find. I'm finding people don't even know the sql that's giving them a problem. We had an ORA- error on an insert and I asked to see the insert statement. They couldn't get it to me as they said it was created and stored as a java bean via some tool (I started to zone out so I might have gotten the terminiology wrong). To them if it's an ORA- error it's a db problem. Personally, I'm not too dogmatic about where the code resides as it's usually not my decision. I just insist that if they want an app that people can troubleshoot they need to add hooks to the code to be able to figure out where problems lie. Also, I see this more for small applications. I don't see how you can avoid pl/sql if you have to do ETL on massive amounts of data. _____ From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of RameshGeecee Sent: Monday, April 13, 2009 7:33 AM To: oracle-l@xxxxxxxxxxxxx Subject: Real-life PL/SQL these days ... Hi Listers, I was wondering what are the real-life PL/SQL usages in these days of n-tier applications. Is anybody putting code into the PL/SQL layer in the modern applications any more? Looks like most of the apps getting built these days are either java / C# apps with the db being just a "store" for data and nothing more with the app developers removed from the db, by an OR Mapper like Hibernate. What's your take on the current majority of the systems? -- Regards, Ramesh.