VNC on openSUSE 11 was 10.3

As some other colleagues, I ran into some trouble upgrading from openSuse 10.3 to openSuse 11 when using VNC.

My server is located in a data-center, so I usually use ssh to logon. In rare occasions I want to graphically take control (when it’s time for a new kernel). And from openSuse 11 this isn’t that simple anymore.

Lot’s of Google hits on this problem, but it depends on your configuration. I’ve got 2. First:
-edit /etc/xinetd.d/vnc and set depth to 32 bits
-remove any IPv6 reference in your /etc/hosts file

But I know for sure that I’ve accomplished something else when I created my first openSuse 11 (vmware) installation way-back in 2009. I’ve forgotten how I’ve managed that one, but it still has its IPv6 references. So, I’ll get back on that one!

For now, my new (fallback) host is configured for remote access. I’ll get back in touch when I’ve discovered the other solution.

Print stylesheet for zoom

While Opera, Firefox and Safari print html pages very nice and have shrink to fit features, IE often seems to corrupt the margins.

A reminder to myself, use in header part:

<style type="text/css" media="print">
  body { zoom: .65; }
</style>

The zoom property is only used by IE.

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…