So I am sure all the wordpress experts are going to say, what the H#$3 did you do that for, and well it seemed like a good thing at the time. Ok this is one i did as a stuff up while trying to resolve issues with this site over the last few days. I found how to really screw up without actually breaking a thing. I had edited a couple of files simple enough, but failed to see the effect it was having or would have. If you change the setting define(‘WP_USE_THEMES’, true); to false in the index.php, the site works fine but you can’t see a damn thing. Lesson learned,  and now I know a bit more about wordpress and its activities

So in the end I am finally upgraded to the latest WP 2.71 and can get down to making things work, and writing more in my blog.

See ya round

Peter

Martin Evans has announced that the DBD::ODBC 1.20 was released eariler this week. He has advised there is still an issue with SQL Native Client at version 10.00.1600 and is looking for testers to work with him to verify the code.

Below is the changes from this release

• Fix bug in handling of SQL_WLONGVARCHAR when not built with unicode support. The column was not identified as a long column and hence the size of the column was not restricted to LongReadLen.  Can causeDBD::ODBC to attempt to allocate a huge amount of memory.

• Minor changes to Makefile.PL to help diagnose how it decided which driver manager to use and where it was found.

• Offer suggestion to debian-based systems when some of unixODBC is found (the bin part) but the development part is missing.

• In 20SqlServer.t attempt to drop any procedures we created if they still exist at the end of the test. Reported by Michael Higgins.
• In 12blob.t separate code to delete test table into sub and call at being and end, handle failures from prepare there were two ENDs.

• In ODBCTEST.pm when no acceptable test column type is found output all the found types and BAIL_OUT the entire test.

• Skip rt_39841.t unless actually using the SQL Server ODBC driver or native client.

• Handle drivers which return 0 for SQL_MAX_COLUMN_NAME_LEN.

• Double the buffer size used for column names if built with unicode.

Like all things, test before implementing this against production systems.

See ya round

Peter

Ok time to blow my trumpet, wow I predicted this with my colleagues here the other day when the idea of anyone buying Sun was mooted. If IBM didn’t I said Oracle was a suitor.

What an interesting assortment of product they now have and the complete stack from storage to application and monitoring. The need a few ancillary products for the data centre such as an ITIL complaint Service management system to integrate with Enterprise Manager. This is potentially a paradigm shift in the industry. Oracle got bigger again and Sun and its products have a new lease on life. From the position of keeping Solaris and the Sun product line alive Oracle will provide the necessary stability to allow new development for Spark and Solaris strengthening the business. Oracle will not break anything up in this acquisition because they don’t have to.

Oracle now are the greatest player in the middeware space with the acquisition of the java badge, Suns Glassfish Server and the products that came out of the Sun acquisition of SeeBeyond and there messaging gateway. I understand many health care providers used the SeeBeyond servers for the HL7 messaging, mix this with the recent deal that bought BEA and its a tasty pie in middleware at Oracle and they get a lot of the healthcare industry.

Databases are now strengthened with Sun MySql being part of the Oracle farm. Oracle has InnoDB already so will strengthen this. Microsoft has a stiff competitor in small to midsize databases.

Oracles 52 acquisitions are now strengthened with a platform to run it all on.

So what’s next, give Oracle a few months to swallow this down, they have such a good track record over the last few years that this will be pretty straightforward and then on to a new morsel to swallow

My bet is EMC, a big pill to swallow but potentially a great fit to the other technology.

Any takers

See ya round

Peter

I have spent some time recently to locate any information for the calculation of disk space required for flashback recovery when migrating a database from Oracle 9 or earlier to 10. This is not an easy thing to find nor understand to resolve this. There is a formula I found on this Oracle forum thread http://forums.oracle.com/forums/thread.jspa?messageID=2034242.

My problem is this I have a 700GB data warehouse ???, its a crude design, database that is moving from 9i to 10g and  the decision has been made as part of migrating all the databases to 10G there will be some use of new features in 10G, flashback recovery and RMAN compressed backups.

I really still dont know what we are going to require for this database but based on our tests it has been decided to provide 2100GB of disk for the space for db_recovery_destination flash recovery, this includes space for 2 compressed full backups and archive logs and flash recovery logs. or no flash recovery and more backups.

I will provide an update to this in a few months  as to how successful the chosen numbers have been, and what eventual configuration we have chosen for the combination of flash, archivelogs and backups

See ya round

Peter