Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

SQL Error during run time

Status
Not open for further replies.

raisin96

Programmer
Oct 10, 2002
21
US
Hi,

I'm currently encountering an error msg during runtime:

==========================================
Fatal error: sqlca errcode -603
WARNING: [BEGIN: already a transaction in progress]...
==========================================

I was just calling a stored function when I encountered this msg (the function still returns the right value)...

My function is something like this:

CREATE FUNCTION getipadd (char(8))
RETURNS CHAR(25)
AS
'
DECLARE
hv_AgentCode ALIAS FOR $1;
hv_IPPORT char(25);
BEGIN
SELECT distinct ac_ipaddress||ac_port
INTO hv_IPPORT
FROM agent
WHERE agent.ac_agentcode = hv_AgentCode;

RETURN hv_IPPORT;
END;
'
LANGUAGE 'plpgsql';

I called the function in a C program (embedded sql) under an AIX system.

By the way, is there a list of sqlerror codes, the meaning of each and the action to do in case I encounter this errors?


Thanks.



 
Hi raisin96,

I think postgres is confusing the keyword "Begin" as a command to begin a transaction. Maybe you could rework the syntax/structure of your function to avoid any confusion. The following is from the Postgres 7.2.1 doc concerning the SQL "BEGIN" command, not to be confused with the Begin keyword used in embedded SQL within a function.



BEGIN
Name
BEGIN -- start a transaction block
Synopsis

BEGIN [ WORK | TRANSACTION ]

Inputs



WORK
TRANSACTION
Optional keywords. They have no effect.


Outputs



BEGIN
This signifies that a new transaction has been started.

NOTICE: BEGIN: already a transaction in progress
This indicates that a transaction was already in progress. The current transaction is not affected.


Description
By default, PostgreSQL executes transactions in unchained mode (also known as "autocommit" in other database systems). In other words, each user statement is executed in its own transaction and a commit is implicitly performed at the end of the statement (if execution was successful, otherwise a rollback is done). BEGIN initiates a user transaction in chained mode, i.e., all user statements after BEGIN command will be executed in a single transaction until an explicit COMMIT, ROLLBACK, or execution abort. Statements in chained mode are executed much faster, because transaction start/commit requires significant CPU and disk activity. Execution of multiple statements inside a transaction is also required for consistency when changing several related tables.

The default transaction isolation level in PostgreSQL is READ COMMITTED, where queries inside the transaction see only changes committed before query execution. So, you have to use SET TRANSACTION ISOLATION LEVEL SERIALIZABLE just after BEGIN if you need more rigorous transaction isolation. In SERIALIZABLE mode queries will see only changes committed before the entire transaction began (actually, before execution of the first DML statement in a serializable transaction).

If the transaction is committed, PostgreSQL will ensure either that all updates are done or else that none of them are done. Transactions have the standard ACID (atomic, consistent, isolatable, and durable) property.

Notes
Refer to LOCK for further information about locking tables inside a transaction.

Use COMMIT or ROLLBACK to terminate a transaction.

Usage
To begin a user transaction:

BEGIN WORK;


Compatibility
SQL92
BEGIN is a PostgreSQL language extension. There is no explicit BEGIN command in SQL92; transaction initiation is always implicit and it terminates either with a COMMIT or ROLLBACK statement.

Note: Many relational database systems offer an autocommit feature as a convenience.


Incidentally, the BEGIN keyword is used for a different purpose in embedded SQL. You are advised to be careful about the transaction semantics when porting database applications.

SQL92 also requires SERIALIZABLE to be the default transaction isolation level.

Leland F. Jackson, CPA
Software - Master (TM)
Nothing Runs Like the Fox
 
Thanks Leland123. I added an "EXEC SQL COMMIT WORK;" after calling my function and its now woking normally. Best regards.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top