Discussion:
Truncate temp table on SPL crash.
(too old to reply)
Isidre Pons Roca
2013-04-17 06:45:28 UTC
Permalink
Hi all,



We have a Stored Procedure that uses temporary tables.


A process calling this procedure hundreds of thousands every day.


Each call must clean the contents of the temporary table.


To improve performance we have moved to use delete to use the truncate, to clean temporary tables.


Once the procedure done this move only works right the first time is called, in the same session (same process).


The error at second call is -710 (Sqlerror), -101 (Isamerror) to any action over the temp table, the truncate works wit no error.


We do not know what is wrong


We would appreciate any help, comments.


Environment:
Informix Dynamic Server 11.50.FC4
Sun solaris 10
Sparc computer.


Exemple of procedure:



create procedure test_truncate()
returning smallint, varchar(40);


define p_v_loop smallint;
define p_v_column1 smallint;
define p_v_column2 varchar(40);




set debug file to "/tmp/test_truncate.log";
trace on;
begin
on exception
create temp table table1(
column1 smallint,
column2 varchar(40,0)
) with no log;
create unique index i1_table1 on table1
(column1);
end exception with resume;
-- delete from table1 where 1 = 1;
truncate table table1;
end;


for p_v_loop in (1 to 10 step 1)
let p_v_column1 = p_v_loop;
let p_v_column2 = "Column 2 of row "||p_v_loop;
insert into table1 values (p_v_column1, p_v_column2);
end for;


foreach
select * into p_v_column1, p_v_column2
from table1
order by column1
return p_v_column1, p_v_column2 with resume;
end foreach;
trace off;
end procedure;




TIA,
Isidre


.
Art Kagel
2013-04-17 14:08:44 UTC
Permalink
OK, handling temp tables in a stored procedure is a pain, but there is a
protocol that's been worked out over the years. Assuming that the table
and its contents are only needed with the one procedure and you are not
using it to pass data to other procedures or to the caller, the protocol is:


1. if you are using a version earlier than 11.70 then set up an
exception to trap and ignore the -206 error if the temp table doesn't exist
when you try to drop it in step #2.
2. if 11.70+ then drop table if exists <temp table>; else drop table
<temp table>;
3. create temp table (index etc.)
4. use temp table
5. drop temp table -- You want this even with step #2 so you don't leave
the temp table around unnecessarily if the proc is called only once in a
longer session.

The drop table is needed in case the procedure is short circuited before
falling out of the processing loop and dropping the temp table. This can
happen if you have a loop with RETURN WITH RESUME inside it and the user
never tries to fetch past the last record (or if you have trapped the last
record and manually exit the loop and drop the temp table before returning
the last record, if the user never fetches that last record). Don't try to
reuse the temp table by truncating it. Just drop it and create it new if
the user calls the procedure again.

Art

Art S. Kagel
Advanced DataTools (www.advancedatatools.com)
Blog: http://informix-myview.blogspot.com/

Disclaimer: Please keep in mind that my own opinions are my own opinions
and do not reflect on my employer, Advanced DataTools, the IIUG, nor any
other organization with which I am associated either explicitly,
implicitly, or by inference. Neither do those opinions reflect those of
other individuals affiliated with any entity with which I am affiliated nor
those of the entities themselves.


On Wed, Apr 17, 2013 at 2:45 AM, Isidre Pons Roca <***@base.cat> wrote:

> Hi all,
>
> We have a Stored Procedure that uses temporary tables.
>
> A process calling this procedure hundreds of thousands every day.
>
> Each call must clean the contents of the temporary table.
>
> To improve performance we have moved to use delete to use the truncate, to
> clean temporary tables.
>
> Once the procedure done this move only works right the first time is
> called, in the same session (same process).
>
> The error at second call is -710 (Sqlerror), -101 (Isamerror) to any
> action over the temp table, the truncate works wit no error.
>
> We do not know what is wrong
>
> We would appreciate any help, comments.
>
> Environment:
> Informix Dynamic Server 11.50.FC4
> Sun solaris 10
> Sparc computer.
>
> Exemple of procedure:
>
> create procedure test_truncate()
> returning smallint, varchar(40);
>
> define p_v_loop smallint;
> define p_v_column1 smallint;
> define p_v_column2 varchar(40);
>
>
> set debug file to "/tmp/test_truncate.log";
> trace on;
> begin
> on exception
> create temp table table1(
> column1 smallint,
> column2 varchar(40,0)
> ) with no log;
> create unique index i1_table1 on table1
> (column1);
> end exception with resume;
> -- delete from table1 where 1 = 1;
> truncate table table1;
> end;
>
> for p_v_loop in (1 to 10 step 1)
> let p_v_column1 = p_v_loop;
> let p_v_column2 = "Column 2 of row "||p_v_loop;
> insert into table1 values (p_v_column1, p_v_column2);
> end for;
>
> foreach
> select * into p_v_column1, p_v_column2
> from table1
> order by column1
> return p_v_column1, p_v_column2 with resume;
> end foreach;
> trace off;
> end procedure;
>
>
> TIA,
> Isidre
>
> [image: BASE-Gestiᅵᅵ d]
>
> *Advertiment legal*: Aquest missatge i, si escau, els fitxers annexos
> tenen caire confidencial, especialment pel que fa a les dades personals, i
> s'adrecen e xclusivament al destinatari referenciat. Si vostÚ no ho és i
> l'ha rebut per error o se li ha fet arribar per qualsevol motiu, us demanem
> que ens ho comuniqui per aquesta mateixa via i el destrueixi o l'esborri i,
> en tot cas, s'abstingui d'utilitzar, reproduir, alterar, arxivar o
> comunicar a tercers aquest missatge i fitxers annexos, tot sota pena
> d'entrar en responsabilitats legals.
> *Abans d'imprimir aquest missatge o qualsevol dels documents adjunts, si
> us plau comproveu que és veritablement necessari.*
>
> *Advertencia legal*: Este mensaje y, en su caso, los ficheros anexos son
> confidenciales, especialmente en lo que respecta a los datos personales, y
> se dirigen exclusivamente al destinatario referenciado. Si usted no lo es y
> lo ha recibido por error o tiene conocimiento del mismo por cualquier
> motivo, le rogamos que nos lo comunique por este medio y proceda a
> destruirlo o borrarlo, y que en todo caso se abstenga d e utilizar,
> reproducir, alterar, archivar o comunicar a terceros el presente mensaje y
> ficheros anexos, todo ello bajo pena de incurrir en responsabilidades
> legales.
> *Antes de imprimir este mensaje o cualquiera de los documentos adjuntos,
> por favor compruebe que es verdaderamente necesario.*
>
> *Disclaimer*: This message and any attached files transmitted with it, is
> confidential, especially as regards personal data. It is intended solely
> for the use of the individual or entity to whom it is addressed. If you are
> not the intended recipient and have received this information in error or
> have accessed it for any reason, please notify us of this fact by email
> reply and then destroy or delete the message, refraining from any
> reproduction, use, alteration, filing or communication to third parties of
> this message and attached files on penalty of incurring legal
> responsibilities.
> *Before printing this message or any attachments, plea se check that it
> is really necessary.*
>
> ------------------------------
> .
>
>
> _______________________________________________
> Informix-list mailing list
> Informix-***@iiug.org
> http://www.iiug.org/mailman/listinfo/informix-list
>
>
Art Kagel
2013-04-17 14:09:02 UTC
Permalink
OK, handling temp tables in a stored procedure is a pain, but there is a
protocol that's been worked out over the years. Assuming that the table
and its contents are only needed with the one procedure and you are not
using it to pass data to other procedures or to the caller, the protocol is:


1. if you are using a version earlier than 11.70 then set up an
exception to trap and ignore the -206 error if the temp table doesn't exist
when you try to drop it in step #2.
2. if 11.70+ then drop table if exists <temp table>; else drop table
<temp table>;
3. create temp table (index etc.)
4. use temp table
5. drop temp table -- You want this even with step #2 so you don't leave
the temp table around unnecessarily if the proc is called only once in a
longer session.

The drop table is needed in case the procedure is short circuited before
falling out of the processing loop and dropping the temp table. This can
happen if you have a loop with RETURN WITH RESUME inside it and the user
never tries to fetch past the last record (or if you have trapped the last
record and manually exit the loop and drop the temp table before returning
the last record, if the user never fetches that last record). Don't try to
reuse the temp table by truncating it. Just drop it and create it new if
the user calls the procedure again.

Art

Art S. Kagel
Advanced DataTools (www.advancedatatools.com)
Blog: http://informix-myview.blogspot.com/

Disclaimer: Please keep in mind that my own opinions are my own opinions
and do not reflect on my employer, Advanced DataTools, the IIUG, nor any
other organization with which I am associated either explicitly,
implicitly, or by inference. Neither do those opinions reflect those of
other individuals affiliated with any entity with which I am affiliated nor
those of the entities themselves.


On Wed, Apr 17, 2013 at 2:45 AM, Isidre Pons Roca <***@base.cat> wrote:

> Hi all,
>
> We have a Stored Procedure that uses temporary tables.
>
> A process calling this procedure hundreds of thousands every day.
>
> Each call must clean the contents of the temporary table.
>
> To improve performance we have moved to use delete to use the truncate, to
> clean temporary tables.
>
> Once the procedure done this move only works right the first time is
> called, in the same session (same process).
>
> The error at second call is -710 (Sqlerror), -101 (Isamerror) to any
> action over the temp table, the truncate works wit no error.
>
> We do not know what is wrong
>
> We would appreciate any help, comments.
>
> Environment:
> Informix Dynamic Server 11.50.FC4
> Sun solaris 10
> Sparc computer.
>
> Exemple of procedure:
>
> create procedure test_truncate()
> returning smallint, varchar(40);
>
> define p_v_loop smallint;
> define p_v_column1 smallint;
> define p_v_column2 varchar(40);
>
>
> set debug file to "/tmp/test_truncate.log";
> trace on;
> begin
> on exception
> create temp table table1(
> column1 smallint,
> column2 varchar(40,0)
> ) with no log;
> create unique index i1_table1 on table1
> (column1);
> end exception with resume;
> -- delete from table1 where 1 = 1;
> truncate table table1;
> end;
>
> for p_v_loop in (1 to 10 step 1)
> let p_v_column1 = p_v_loop;
> let p_v_column2 = "Column 2 of row "||p_v_loop;
> insert into table1 values (p_v_column1, p_v_column2);
> end for;
>
> foreach
> select * into p_v_column1, p_v_column2
> from table1
> order by column1
> return p_v_column1, p_v_column2 with resume;
> end foreach;
> trace off;
> end procedure;
>
>
> TIA,
> Isidre
>
> [image: BASE-Gestiᅵᅵ d]
>
> *Advertiment legal*: Aquest missatge i, si escau, els fitxers annexos
> tenen caire confidencial, especialment pel que fa a les dades personals, i
> s'adrecen e xclusivament al destinatari referenciat. Si vostÚ no ho és i
> l'ha rebut per error o se li ha fet arribar per qualsevol motiu, us demanem
> que ens ho comuniqui per aquesta mateixa via i el destrueixi o l'esborri i,
> en tot cas, s'abstingui d'utilitzar, reproduir, alterar, arxivar o
> comunicar a tercers aquest missatge i fitxers annexos, tot sota pena
> d'entrar en responsabilitats legals.
> *Abans d'imprimir aquest missatge o qualsevol dels documents adjunts, si
> us plau comproveu que és veritablement necessari.*
>
> *Advertencia legal*: Este mensaje y, en su caso, los ficheros anexos son
> confidenciales, especialmente en lo que respecta a los datos personales, y
> se dirigen exclusivamente al destinatario referenciado. Si usted no lo es y
> lo ha recibido por error o tiene conocimiento del mismo por cualquier
> motivo, le rogamos que nos lo comunique por este medio y proceda a
> destruirlo o borrarlo, y que en todo caso se abstenga d e utilizar,
> reproducir, alterar, archivar o comunicar a terceros el presente mensaje y
> ficheros anexos, todo ello bajo pena de incurrir en responsabilidades
> legales.
> *Antes de imprimir este mensaje o cualquiera de los documentos adjuntos,
> por favor compruebe que es verdaderamente necesario.*
>
> *Disclaimer*: This message and any attached files transmitted with it, is
> confidential, especially as regards personal data. It is intended solely
> for the use of the individual or entity to whom it is addressed. If you are
> not the intended recipient and have received this information in error or
> have accessed it for any reason, please notify us of this fact by email
> reply and then destroy or delete the message, refraining from any
> reproduction, use, alteration, filing or communication to third parties of
> this message and attached files on penalty of incurring legal
> responsibilities.
> *Before printing this message or any attachments, plea se check that it
> is really necessary.*
>
> ------------------------------
> .
>
>
> _______________________________________________
> Informix-list mailing list
> Informix-***@iiug.org
> http://www.iiug.org/mailman/listinfo/informix-list
>
>
Plugge, Joe R.
2013-06-07 06:33:21 UTC
Permalink
I cannot remember the command that tells Informix to start returning data immediately within a stored procedure. It tells the procedure to start returning rows right away ... anybody out there know what I am referring to?

Joe
Plugge, Joe R.
2013-06-07 13:10:10 UTC
Permalink
Thanks John ... I knew it was out there, just could not remember what the actual command was ..

Joe

From: John Miller iii [mailto:***@us.ibm.com]
Sent: Friday, June 07, 2013 2:53 AM
To: Plugge, Joe R.
Cc: informix-***@iiug.org
Subject: Option to have sql in SPL start returning data immediately ...


Set optimization first rows

will tell the optimizer to avoid using blocking operations and use inline operators.


John F. Miller III


-----informix-list-***@iiug.org<mailto:-----informix-list-***@iiug.org> wrote: -----

>To: "informix-***@iiug.org<mailto:informix-***@iiug.org>" <informix-***@iiug.org<mailto:informix-***@iiug.org>>
>From: "Plugge, Joe R."
>Sent by: informix-list-***@iiug.org<mailto:informix-list-***@iiug.org>
>Date: 06/06/2013 11:36PM
>Subject: Option to have sql in SPL start returning data immediately
>...
>
>I cannot remember the command that tells Informix to start returning
>data immediately within a stored procedure. It tells the procedure
>to start returning rows right away ... anybody out there know what I
>am referring to? Joe
>_______________________________________________ Informix-list mailing
>list Informix-***@iiug.org<mailto:Informix-***@iiug.org>
>http://www.iiug.org/mailman/listinfo/informix-list
Loading...