Oracle Forms 6i vs. Oracle 11gR2

Oracle Forms 6i is a well known application, and despite it no longer being supported, it shares a huge user base. Most applications are so vast that it's simply not feasible to ever upgrade them. Instead some are being gradually replaced while others just drag on.

While Oracle Forms 6i client is of course supported even on Windows 7 and Server 2008, it is unclear whether it will be play nice with future Oracle database releases.

As Oracle datase 11gR2 has been released on Windows platforms too, I considered upgrading our old RDBMS to 11gR2. Of course we use Oracle Forms 6i client/server, which is only certified for Oracle 10gR1.

To my surprise, Oracle Forms 6i is able to connect to 11gR2 using username/password. When using Native Windows Authentication however, the client just freezes for a few seconds, then quits. I tried all patches, and even patched Oracle RSF to 8.0.6.3 - but the problem remained. It seems to be a fundemalten problem as the client is unable to connect to a 11gR2 database as soon as the parameter sqlnet.authentication_services includes NTS.

With 11gR1 however, everything's fine in this regard.

Oracle SQLDeveloper on Windows x64

There is a new version of Oracle SQLDeveloper available. The release notes are here. This time there is even a build for 64bit Windows platforms available. All that needs to be done after unpacking is to point it to the JDK x64 java.exe. It doesn't work with a 32bit JDK!


There were quite some workarounds floating around to make it work. Having to install a 32bit JDK on a 64bit OS for a 32bit Java application always seemed weird to me. So I'm glad Oracle finally got around the bend and provide a fully functional SQL Developer for Windows x64.


Of course the language / regional fix still applies to this version, as they didn't bother to include a GUI option to specify them. In case you are wondering why your SQL Developer shows up in some weird language other than English, add these lines to your sqldeveloper/bin/sqldeveloper.conf:

AddVMOption -Duser.language=en
AddVMOption -Duser.country=US

improving the LG BD390?

I recently got a LG BD390, which is of course a bluray player that features UPnP/DLNA support, as you all already know.

Someone has gotten the alleged firmware from LG, but turns out just to be the cross-compile toolchain and ucLinux. Well, anyway we know know that the BD370 and BD390 are based on that.

I don't think that there isn't a way to get console access to this device. A detailed network scan revealed this:

PORT STATE SERVICE VERSION
111/tcp open rpcbind
9736/tcp open unknown
44394/tcp open unknown

Port 44394 TCP returns a "500 internal server error", but probably just due to an incorrect URL. At least this means a webserver is running, so there is hope. ;-)

SS4200 woes

Well, ever since I had the SS4200 it just froze from time to time. I never had a chance to find out the details, because it mostly froze during the day when I was at work, or at night when I was out drin^H^H^H^H studying.

I always thought it was related to my custom kernel. Now it finally froze in my presence, so I could check it out. I opened the case and found the fans spinning rather slowly, and the CPU and northbridge were very hot. I figured the poor thing overheated.
So in fact I was right, because I enabled thermal management and CPU throtteling in my kernel, and loaded all those modules of course.
Add the fact that the Celeron 420 actually doesn't support SpeedStep, and you've got a few kernel moduels going crazy.
I'll remove the thermal and cpu throtteling modules for the time being and see whether that improves stability.

In the long run I want a NAS that doesn't consume more power than really necessary, so I'll probably switch the CPU to a Celeron E1400 or similiar. Those already got a 2nd core and support SpeedStep. While that's got a higher TDP, I think the power consumption is going to be lower, over all.

Guess we'll have to wait and see.

C# debugging

If you are a C# developer using Visual Studio 2008 and you need to debug your solution using arguments? Then read on.

There is a nice security feature in VS2008 that prevents arguments from being passed on to your executable. There even is a nice warning message, that tells you something about some bogus debug security settings. I haven't found any of these settings anywhere in the project, solution or even VS2008 settings.

I've still found a workaround, however:

1. In your C# project settings under Debug activate SQL-Server debugging
2. Make sure you've entered some arguments in the run options
3. Debug your solution
4. Profit!

You'll see the familiar messagebox telling you that the security settings permit the arguments from being passed on to the executable. Continue anyway. Then you'll see a second messagebox, yapping on about some debug security settings that were disabled. Well guess what - from now on you can use arguments to debug! Oh and of course you can disable SQL server debugging, it's only needed to trigger that metaphysical process in VS2008. ;)