Blogs

4GL WHENEVER ERROR

Thursday, 16 February 2012

This article is written in English and Portuguese
Este artigo estÃ¡ escrito em InglÃªs e PortuguÃªs

English version:

I believe this is the first time I cover a 4GL topic here. But a recent customer situation motivated me to write this. Hopefully most of the readers will just say "Yeah... Everybody knows that...", but it's not the first time I see people making the confusion I'm going to describe, and in my opinion that happens because it's not intuitive. Although it's perfectly documented, I suppose many people just follow the intuitive approach and fall into the problem.

I'm talking about the WHENEVER statement. It is used to define the behavior of the program when(ever) a defined condition (ERROR, SQLERROR, WARNING, SQLWARNING or NOTFOUND) happens. The behavior can be CONTINUE, STOP, GOTO or CALL function. Seems pretty simple and handy... so why am I writing this? The usual confusion relates to the scope of the WHENEVER statement. At first glance you could think this was a program instruction, and the effect or scope of it would be until the program flow reached another WHENEVER statement. And this is the confusion many people make.
In reality it's not a program instruction, but instead it's a compiler directive. As stated in the documentation the scope is local to the module where it appears. If the module contains only function definitions, then all this functions will behave accordingly to the conditions used in the WHENEVER statement. The program flow is irrelevant.
This is better shown with a practical example (line numbers added for clarity)

 1  DATABASE sysmaster
 2  MAIN
 3        DEFINE v INTEGER
 4        CALL func_1() RETURNING v
 5  END MAIN
 6
 7  FUNCTION func_0()
 8        WHENEVER ERROR CONTINUE 
 9  END FUNCTION
10
11  FUNCTION func_1()
12        SELECT no_column FROM no_table
13        RETURN 1,2
14  END FUNCTION

Ok, ...

Informix on AIX patch levels

Saturday, 11 February 2012

IBM has recently publish a document stating the OS levels required and other known issues:

http://www-01.ibm.com/support/docview.wss?uid=swg21579767

If you're already running Informix on AIX, or are planning to, then you should took a quick look at it

New Informix Blog from Gary Proctor

Friday, 10 February 2012

Gary Proctor - IBM Business Development Exec - has started a new blog. Gary's blog is focused on solutions build on Informix:

Informed Mix - Random Postings about IBM Informix

For your convenience Gary's blog has been added to Informix Zone (right side) and will also be re-published on planetIDS.com.

I believe that Gary's postings will help to spread the word about Informix and I wish him a successful start !

Sweet CRM / Doce CRM

Thursday, 09 February 2012

This article is written in English and Portuguese
Este artigo estÃ¡ escrito em InglÃªs e PortuguÃªs

English Version:

A recent press release by Oninit is being echoed across the Internet. Oninit have completed the port of SugarCRM, an open-source CRM system to Informix.
This gives SugarCRM users the opportunity to use Informix as the underlying database to their CRM system, effectively taking advantage of all the features we all know and love (performance, scalability, high availability features, complete platform options, simplicity etc.).

But there is even more to this.. Accordingly to SugarCRM site ther...

Procedures / Procedimentos Owner vs Restricted

Monday, 06 February 2012

This article is written in English and Portuguese
Este artigo estÃ¡ escrito em InglÃªs e PortuguÃªs

English version:

Introduction

This article focus on a little known aspect of stored procedures or functions. That probably explains why it was the less voted in a recent poll I've conducted. Nonetheless it's (from my point of view) a very interesting topic. During this article I'll be referring to procedures, but I could use the term functions.
If we take a look at the sysprocedures table we'll see a field called mode. This field is just one character and the values it can contain are:

D or d
DBA
O or o
Owner
P or p
Protected
R or r
Restricted
T or t
Trigger

I'm not interested in all of these, but the lower case letters mean "protected" (created by the system), D is for DBA procedures. P is an old nomenclature for protected procedures. T is used for procedures defined as Trigger procedures. And then we have O and R. O for owner mode and R for restricted mode. What is the difference between them? Assume you're using informix user and you run:

CREATE PROCEDURE test()
END PROCEDURE

You'll have an OWNER mode procedure, owned by informix user. But if instead you run:

CREATE PROCEDURE myuser.test()
END PROCEDURE

You'll have a RESTRICTED mode procedure owned by myuser.
You need to have DBA privilege to create a procedure on behalfwith another user name.

Why RESTRICTED?

The reasons why the restricted mode procedures/functions were created are based on security. Let's imagine the following scenario:

You have two databases called db1 and db2
You have a user myuser with connect privileges on db1 and db2 and another user mydba with DBA privileges on db1
User myuser needs to be connected to db1 and run a distributed query to db2
The db2's DBA grants the required privileges on db2 to user myuser

Now, without the RESTRICTED mode procedures, mydba could create a local db1 procedure on behalf of myuser, and with that it could remotely access the data on db2. Note that the db2 DBA did not intend to give the privileges to anyone else beside myuser. So a local DBA could use it's privileges to abuse some of the remote privileges granted to some of the local users.
This is why the RESTRICTED mode was created. Every time we create a procedure on behalf of another user, it will be created as a RESTRICTED mode procedure. And as such any remote operatio...

More Articles...