Monthly Archives: March 2010

How firefox 3.6 accelerates the phasing out of Jinitiator (and frustrates Metalink..)

Customer using Webforms, Application Server 10.1.2.0.2 with Jinitiator on the client. Planning to upgrade the client to Java 6.17 / 6.18, so these java-versions are already installed on the clients. We’re testing the java-configuration on the web-server (formsweb.cfg), but production still works with the old Jinitiator.

Also the customer is using Firefox, 3.5 in this case, and Internet Explorer (6!). Suddenly the application does not work anymore for a lot of clients, as a matter of fact, the firefox-users.

They had upgraded their Firefox to 3.6., and got the message that an add-on must me installed ( appears to be the JRE  / Jinitiator) . After installing this, it still does not work.

The answer comes from here :  no more Java < 6.10 anymore in  Firefox 3.6 and above…. So the plans we had for upgrading JRE to Java 6.17 or 6.18, we have to accelarate these… No  more Jinitiator.

By the way: ever tried to open notes in  Metalink with Firefox 3.6 ? Does not look nice.  Following  this item at the support page of Mozilla.

By |March 15th, 2010|Categories: App. Server|Tags: , , , |0 Comments

Apex : wwv_flow.accept, PLS-00306, wrong number of types of arguments

Database: 10.2.0.2, Apex 3.2.1. Application works fine, until there’s a bit of load of users logging in. They get a http-404 message. Full message derived from error-logging of Apache:

[Wed Mar 10 09:21:58 2010] [error]

  • [ecid: 1268209318:194.13.31.219:1543:0:26453,0] mod_plsql: /pls/apex_app/wwv_flow.accept HTTP-404 ORA-06550: line 22, column 3: PLS-00306: wrong number or types of arguments in call to ‘ACCEPT’ ORA-06550: line 22, column 3: PLS-00306: wrong number or types of arguments in call to ‘ACCEPT’ ORA-06550: line 22, column 3:PL/SQL: Statement ignored

    When looking at the error-logging of Apex, there are a massive amount of the same errors.

    The package ‘www_flow.accept’ is a genuine Apex-package, so it doesn’t look like an application thing. After poking around on Metalink and forums, the following was found:

    Metalink: this could be the result of database bug 5228292 or 4752541 (fixed in 10.2.0.3 introducing bug 5705795, also fixed in 10.2.0.3, also one-off patch available) and the problem went away after issuing ALTER SYSTEM FLUSH SHARED_POOL as SYS. So yes, this is a workaround, and yes I put this in a job every night. Did it help? Unfortunately not.

    In the forums it seems that not using ‘clearing caches’ in the sessions is causing some trouble, and one of the solutions (sorry, could not find the URL and the author anymore) we used, and I quote the author:

    I had the exact same problem when I tried to submit my login credintials. I got around it by adding a process to my login page.

    Process type: Clear Cache For Current Session (removes all state for current session)
    Process point: On Load – Before header.

    After I start using this process I haven’t seen the error.

    Implemented this (by our developer), and … now we wait. Don’t know of it helped yet, but it looks like an old story: not neatly programming will be punished, also by Apex.  Whether it helped or not with me, maybe it helps you to solve your problem or gives you a clue.

    By |March 13th, 2010|Categories: Database|Tags: , |0 Comments

    ORA-03114 / 03113 while running dbms_java package

    Short note this time. Got errors (ora-03114 / ora-03113)  while running any dbms_java script on a 10.2.0.2 database. Took a while, but then I found out it only happens when I’m connected  through sql*net.  Directly on the server gave no problem at all. And… it only occurs in my test-environment, not in development, and not in production.

    What is different in my test-environment? Ahh…., on that node there are two different versions of the database installed, a 10.2.0.3 and a 10.2.0.2. And.. only one listener, from the 10.2.0.3 – software tree.

    Stopped the listener of the 10.2.0.3, and started the listener of the 10.2.0.2 (after configuring), and it worked again! The only thing is now that the other database has the problem of the dbms_java..   Configured two listeners, one at port 1521, the other on 1526, reconfigured tnsnames on the application server,  problem solved.

    The cause of this failure? I think it has to do with environment-variables, but I was too lazy to dig thoroughly, so any suggestions are welcome.

    For the record, the test script I used (it does nothing here, deleted a line with a call to a java program);

    set serveroutput on
    declare
    l_output dbms_output.chararr;
    l_lines number;
    begin
    dbms_output.enable(1000000);
    dbms_java.set_output(1000000);
    dbms_output.get_lines(l_output, l_lines);
    for i in 1 .. l_lines loop
    dbms_output.put_line(l_output(i));
    end loop;
    end;
    /

    Result:

    SQL>@test_java
    ERROR:
    ORA-03114: not connected to ORACLE

    declare
    *
    ERROR at line 1:
    ORA-03113: end-of-file on communication channel

    By |March 5th, 2010|Categories: Database|Tags: |0 Comments