APEX Runtime only

If you have an Apex export from your development environment to install into your production environment, you might run into troubles when your production is Apex runtime only.

For an import to be successful, it is required to have a workspace. Create it using the following:

set serveroutput on size 1000000
set feedback off
-- This script can be run in sqlplus as the owner of the Oracle Apex owner.
begin
  wwv_flow_api.set_security_group_id(p_security_group_id=>1046129509285998);
end;
/
----------------
-- W O R K S P A C E
-- Creating a workspace will not create database schemas or objects.
-- This API will cause only meta data inserts.
prompt  Creating workspace ABC...
begin
wwv_flow_fnd_user_api.create_company (
  p_id                      => 1046207189286079,
  p_provisioning_company_id => 1046129509285998,
  p_short_name              => 'ABC',
  p_first_schema_provisioned=> 'ABC',
  p_company_schemas         => 'ABC',
  p_expire_fnd_user_accounts=> '',
  p_account_lifetime_days=> '',
  p_fnd_user_max_login_failures=> '');
end;
/

Now, note the security group id / provisioning company id. Check your export file(s) from your development environment and before importing into production change the identifier in the export file(s).

Once this is done it is safe to import the application using only an SQL prompt.

In this example, in production a workspace ABC is created identified by nr. 1046129509285998 and has corresponding database schema ABC, which is not required but more clear.

apexlib_tabform and ORA-00911: invalid character

When validating a report by looping its values (i.e. :)

for i in 1 .. apexlib_tabform.getrowcount loop
  v_num := apexlib_tabform.nv('ATTR_ID', i);
end loop;

You can get an ORA-00911 message. My first attempt was to enhance the procedure ApexLib_Util.debug to find out more. Interesting outputs, but no indication for a solution though.

After some complexity reduction on my query, I found the entire query is parsed to the ApexLib_TabForm package and gets mis-interpreted  because of an order by clause in the query.

So, the solution is to get rid of the order by and use the sort checkboxes on the Report attributes page instead.

MySQL Database Error: Illegal mix of collations

Recently I restored some older MySQL 5.1 database. In the meantime some minor patches were applied and suddenly I received an error (while calling from a java app):

MySQL Database Error: Illegal mix of collations (utf8_general_ci,IMPLICIT) and (utf8_unicode_ci,IMPLICIT) for operation …

Usually my tables are all created (something) like this:

create table apl_users
(usr_id                 int(10)        unsigned not null auto_increment primary key
,usr_login              varchar(40)             not null
,usr_password           varchar(40)             not null
,usr_name               varchar(80)
,index (usr_login)
) engine=InnoDB default charset=utf8;

And a stored procedure who uses this is not really fancy:

create procedure sp_get_usr( in p_in_usr_login varchar(40) )
begin
  select usr_id
  ,      usr_login
  ,      usr_password
  ,      usr_name
  from   apl_users
  where  usr_login = p_in_usr_login;
end;

But somehow (after an upgrade) I got the error mentioned above. After some experimenting on how to collate, I found out maybe it has something to do with the database settings itself (for some odd reason, a bugmantis installation in the past was defaulted to a latin_swedish character set; I’d never paid much attention to that). So I recreated the database from:

create database my_database;

to:

create database my_database default character set 'utf8' collate 'utf8_general_ci';

An now, so far (the fat lady is not singing yet), no errors calling stored procedures from my Java application…

Setting MySQL root password for the first time

Reminder, on Linux set password for the first time:

mysqladmin -u root password THEPASSWORD

Or, when there is a known password:

mysqladmin -u root -p password THEPASSWORD

Or, when using tables (first install or when password is known):

# mysql -u root -pBLABLA
mysql> use mysql
mysql> update user set password=PASSWORD("NEWBLA") where user = 'root';
mysql> flush privileges;
mysql> quit

Calling R from Java using JDeveloper

Download: rJava0.7 from http://www.rforge.net/rJava/files/

Extract from “rJava 0.7\rJava\jri\JRI.jar” and put the .class files inside your project. Still not able to compile, also add the JRI.jar file to the library path (for compilation purposes):

For the sake of convenience, put “import org.rosuda.JRI.*;” everywhere although every class specifically mentioned is better of course.

Now, a more common error is shown on the console when trying to use the R engine:

Cannot find JRI native library!
Please make sure that the JRI native library is in a directory listed in java.library.path.
java.lang.UnsatisfiedLinkError: no jri in java.library.path

Obviously the JRI.jar is not on the library path (but the swing application contains it -they should work on that).

Still, on any client ‘R’ will be installed; which contains the JRI.jar if rJava gets installed. So, let’s do that first, It is adviced to use version 2.9, so let’s do a full-install with 2.9.1 (if that will fail, we try 2.9.0).

In Vista, install it in the user environment as administrator:

Then set R_HOME to the proper location and add R_HOME/bin to the Windows path:

Although this should work immediately, the paranoia mode is fully operational, so reboot first.

After a reboot, run ‘R’ and install rJava using this command:

install.packages('rJava',,'http://www.rforge.net/')

Now the JRI.jar should be in the library/rJava/jri directory and it should be the same (hopefully) as in the JDeveloper project(!). This part is rather buggy in my optinion, since we only can assume the intall.packages command uses exactly the same as the version in the files section mentioned in the very first line of this post.

The ‘UnsatisfiedLinkError’ is still there when running a test from JDeveloper, so after some googling the native DLLs must be on the system path as well, in this case the jri.dll (pretty clear exception, not). This is an important step for the installation manual.

When the R_HOME/library/rJava/jri is added to the system path, the test from inside JDeveloper works! Now let’s go for a deployment on another machine. It is clear, the development machine is a bit more intelligent than one without a Java SDK (only JRE 1.6 is required). When all system variables are set correctly (nu user environment variable), all works nicely.

For the future; not to include the JRI.jar inside the deployment.