ORACLENERD

OpenOffice Writer: AutoComplete?

Now that I'm using Ubuntu, I'm also using OpenOffice.

However, I like Google Docs quite a bit so I've used OpenOffice sparingly.

I've had trouble with Google Docs though; the Download as Word bastardizes the document. Looks great as a pdf, not so much as a Word document. The reason for creating a Word document is for recruiters, they all seem to have some sort of application that parses the Word document and fills in your employment history and such. This would be a great place for XML and some sort of standard wouldn't it?

Anyway, in OpenOffice Writer, I type in:

November 2009

which Writer immediately turns into

11/01/09

No! Stop it!
I tried turning AutoComplete off:

Tools --> AutoCorrect

and disabling everything I can find...try again. Same result.

Reading this thread, I begin to wonder if it's like Excel...you know, you enter a date and it automatically puts it into the default date format.

Sure enough, right click on the column, select "Character" and voila! No more transformation.

Labels: open source, openoffice, ubuntu

¶ 11/03/2009 08:56:00 PM 2 Comments Links to this post

Alerts - Scheduler Jobs Did Not Run

The last couple of days our warehouse environment hasn't been updating properly. It's basically a collection of Materialized Views based on the OLTP system. It appears as though many (all?) of our scheduler jobs are not running. DBA believes it has something to do with the Flash Recovery Area running out of space. I don't know and I don't have the time to find a root cause. I do know that there were no errors and the jobs were not in a failed status.

Rather than have the business inform us their reports our not right I was tasked with creating an alert if the jobs did not run. Usually we set up alerts for things that break or actually completed. I think this is the first time I've had to build something to the opposite.

Here's what I came up with:

CREATE OR REPLACE
PROCEDURE jobs_did_not_run
AS
  b VARCHAR2(3) := CHR(10);
  TYPE r_table IS RECORD
  (
    job_name VARCHAR2(30),
    next_run_date DATE,
    job_action VARCHAR2(4000)
  );
  TYPE t_table IS TABLE OF R_TABLE;
  l_table T_TABLE := T_TABLE();
  l_subject VARCHAR2(50) := 'Alert - Jobs have not run';
  l_message VARCHAR2(32767);
BEGIN
  SELECT job_name, next_run_date, job_action
  BULK COLLECT INTO l_table
  FROM dba_scheduler_jobs
  WHERE state = 'SCHEDULED'
    AND enabled = 'TRUE'
    AND next_run_date < SYSDATE;
 
  l_message := 'The following jobs have not run today:' || b;
  FOR i IN 1..l_table.COUNT LOOP
    l_message := l_message || 'Job:           ' || 
                   l_table(i).job_name || b;
    l_message := l_message || 'Next Run Date: ' || 
                   TO_CHAR( l_table(i).next_run_date, 'MM/DD/YYYY HH24:MI:SS' ) || b;
    l_message := l_message || 'Action:        ' || 
                   l_table(i).job_action || b;
  END LOOP;

  utl_mail.send
    ( sender => '',
      recipients => '',
      subject => l_subject,
      message => l_message );

END jobs_did_not_run;
/
show errors

You can find it here in my Google Code home for DBA Utilities. I do believe that at some future point this will be incorporated into a package, but for now it is a standalone procedure.

You'll receive a nice little email noting the JOB_NAME, scheduled NEXT_RUN_DATE and the JOB_ACTION (the anonymous block).

Labels: code, dba, open source

¶ 3/06/2009 11:57:00 PM 0 Comments Links to this post

It's the Data, Stupid!

Search for the phrase on Google and you'll get plenty of results.

After reflecting for a few days on reaction to MySQL, I think I've realized what is at the heart of it all. Data.

Application developers are not stewards of data. They believe that to be the job of the DBA.

Someone recently asked one of our architects what features of MySQL convinced them to choose this as our new database engine. It's open source!

Of course, that makes perfect sense.

Can it connect to Oracle?

I don't know.

Our architects are made up primarily of former application developers, be it web or client server apps. Data was never that important...

They are currently driving our tool set to favor the application developers, which makes perfect sense to them. It's all about the interface.

But it's not. In the health-care industry, data is king. For any industry really.

I've been trying to convince everyone that this million dollar piece of software called Oracle is not just a bucket, it's feature rich. Streams, Queueing, all kinds of really cool tools. According to our DBAs, none of that stuff is used.

No wonder we're moving to MySQL.

So my quest is to convince the powers that be is to stop wasting money on our million dollar buckets and use them to their full capabilities.

If you have any information to help in this fight, links, slideshows, whatever, please send them on to me (myfirstname.mylastname@gmail.com), please!

Help me turn the tide back to Oracle, back to the data!

Labels: database, mysql, open source, oracle

¶ 2/06/2008 10:30:00 PM 1 Comments Links to this post

Open Source Obsession?

Since our new CIO came on board last January, there seems to a big movement towards Open Source tools.

While I have nothing against them, I've used various tools in the past; I just don't see what our obsession is with them.

Let's start with Ruby on Rails. An open source framework built on top of Ruby. It's used for web development. It's supposed to be a much more user intuitive language which makes it so easy. Fair enough. I'm always for something that will make my job easier. Our corporate website and provider portals were previously created on the dot net framework.

It was decided last year to replace our entire web infrastructure with Ruby on Rails. I'm still trying to figure out why. It's not that I am a pro-Microsoft guy, but the site worked. There were complaints about it missing this or that functionality, but that's fairly easy to remedy. As far as I know, dot net can support AJAX functionality (which I believe was at the heart of everything).

The demos of the new site were very cool (apparently we paid someone a lot of money to design the site...a LOT of money). It looked all web 2.0ey, big buttons, small text (which is a suprise given we are an HMO managing Medicare). It looked a lot like the 37signals applications in fact. I guess I've read Tom Kyte for far too long and his rant about putting business logic in the database because the front end will always change. Seems true. Java or dot net were all the rage a few years back, now it's Ruby, in a couple of years it will be something else (ApEx!) at which point we will have to rewrite the whole thing.

Next up, MySQL. It's a given that this database has come a long way. Version 5 even has stored procedures. It's a great free database that supports many websites out there. Free is good. Well, mostly free anyway, we do pay support costs right now. Almost every new project is built on top of MySQL. Why? I'm not sure other than free.

I asked the question to the CIO in one of our All-Hands meetings and his response was cost.

Fair enough, Oracle is expensive. The way we use Oracle is even more so. Each project seems to get it's own database. Why they don't get a schema on an existing database I don't quite understand. I've been told that it is a logistical nightmare to pull down a database that affects so many different applications. Each group wants their own version, etc., etc.

I can understand the Data Warehouse having their own database and perhaps our main appplication having it's own database; but every single application? Why not a one off database that houses all the smaller applications in different schemas? That's what Oracle was built for? Plus you can reuse code, reduce the number of instances (thus reducing the cost)...I just don't understand.

I believe my main complaint is that they are still just treating the database (whether Oracle or MySQL) like a bucket. Web people should not be writing SQL; Ruby people should not be writing SQL; just like I shouldn't be writing Ruby code. I don't know it.

I would be willing to bet that I could re-create many of our smaller applications in a much shorter period of time in Oracle and ApEx given the same requirements.

So I rant on. If I truly thought that this was an effort to make IT cheaper and more sustainable, I would be on board. I just don't see that that is the case...

Labels: database, mysql, open source, oracle, rant, work