IDS crashes in flexible grid create table commit

Hello All, I am using Informix version 11.70.FC4GE. I have two nodes set up in a flexible grid, with ER active. Whenever I try to create a table within a begin/commit block, IDS crashes. So, this causes a crash when trying to execute the commit: begin; execute procedure ifx_grid_connect('gridname',1); create table test (field1 integer); execute procedure ifx_grid_disconnect();commit; This also causes IDS to crash: execute procedure ifx_grid_connect('gridname',1);begin; create table test (field1 integer);commit; execute procedure ifx_grid_disconnect(); If I don't use the begin/commit block, then the table is created with no problem on both nodes(which is what I want). The set of SQL I want to execute is much more than this, but I narrowed it down to the create table that causes the crash. Interestingly enough, the table actually does get created on both nodes, even though IDS crashes. The database I am using uses unbuffered logging, and I want the newly created table to participate in replication. I can't find any documentation that says you should not do table creates in begin/commit blocks in a flexible grid environment. Does anyone know if this is a known limitation? Thanks, Jeff

Original Post: Hello All, I am using Informix version 11.70.FC4GE. I have two nodes set up in a flexible grid, with ER active. Whenever I try to create a table within a begin/commit block, IDS crashes. So, this causes a crash when trying to execute the commit: begin; execute procedure ifx_grid_connect('gridname',1); create table test (field1 integer); execute procedure ifx_grid_disconnect();commit; This also causes IDS to crash: execute procedure ifx_grid_connect('gridname',1);begin; create table test (field1 integer);commit; execute procedure ifx_grid_disconnect(); If I don't use the begin/commit block, then the table is created with no problem on both nodes(which is what I want). The set of SQL I want to execute is much more than this, but I narrowed it down to the create table that causes the crash. Interestingly enough, the table actually does get created on both nodes, even though IDS crashes. The database I am using uses unbuffered logging, and I want the newly created table to participate in replication. I can't find any documentation that says you should not do table creates in begin/commit blocks in a flexible grid environment. Does anyone know if this is a known limitation? Thanks, Jeff Response: Yes you should be able to create tables in begin/commit blocks. If the server crashes, it would be a defect. You should open a PMR with support. If my memory is right I think it is an already reported problem, but if you have SQL that you can supply to support that crashes the server, then if it isn't already known, a new defect can be submitted (assuming it can be reproduced here). Jacques Renaut IBM Informix Advanced Support APD Team

Is there a case with tech support? From: "JEFFREY GENEGA" <jeffrey.genega@spirent.com> To: ids@iiug.org, Date: 06/26/2012 06:35 AM Subject: IDS crashes in flexible grid create table commit [27473] Sent by: ids-bounces@iiug.org Hello All, I am using Informix version 11.70.FC4GE. I have two nodes set up in a flexible grid, with ER active. Whenever I try to create a table within a begin/commit block, IDS crashes. So, this causes a crash when trying to execute the commit: begin; execute procedure ifx_grid_connect('gridname',1); create table test (field1 integer); execute procedure ifx_grid_disconnect();commit; This also causes IDS to crash: execute procedure ifx_grid_connect('gridname',1);begin; create table test (field1 integer);commit; execute procedure ifx_grid_disconnect(); If I don't use the begin/commit block, then the table is created with n= o problem on both nodes(which is what I want). The set of SQL I want to execute is much more than this, but I narrowed it down to the create table that= causes the crash. Interestingly enough, the table actually does get created on both nodes= , even though IDS crashes. The database I am using uses unbuffered logging, and I want the newly created table to participate in replication. I can't find any documentation that says you should not do table create= s in begin/commit blocks in a flexible grid environment. Does anyone know if= this is a known limitation? Thanks, Jeff ***********************************************************************= ******** Forum Note: Use "Reply" to post a response in the discussion forum. =

Orignal post: Yes you should be able to create tables in begin/commit blocks. If the server crashes, it would be a defect. You should open a PMR with support. If my memory is right I think it is an already reported problem, but if you have SQL that you can supply to support that crashes the server, then if it isn't already known, a new defect can be submitted (assuming it can be reproduced here). Jacques Renaut IBM Informix Advanced Support APD Team Response: I think this could be APAR IC80880, but that would only be the case if you also have SQL tracing turned on. If you have sql tracing enabled, if you disable it, then the create should no longer crash the server. This APAR is fixed in 11.70.xC5. Jacques Renaut IBM Informix Advanced Support APD Team

Hello Jeff. The use of procedures in flexible grid must be done after connecting to it, so if you really need to, just change your begin work statement after the ifx_grid_connect, it should work fine. Regards. Alexandre Marini IBM Informix Certified Professional v10 / v11.50 / v11.70 IBM Information Management Informix Technical Professional IBM Infosphere DataStage Technical Professional Database Administrator - Cleartech Ltda BRIUG website administrator Informix independent consultant > To: ids@iiug.org > From: jeffrey.genega@spirent.com > Subject: IDS crashes in flexible grid create table commit [27473] > Date: Tue, 26 Jun 2012 08:33:33 -0400 > > Hello All, > > I am using Informix version 11.70.FC4GE. I have two nodes set up in a flexible > grid, with ER active. Whenever I try to create a table within a begin/commit > block, IDS crashes. > > So, this causes a crash when trying to execute the commit: > > begin; > execute procedure ifx_grid_connect('gridname',1); > create table test (field1 integer); > execute procedure ifx_grid_disconnect();> commit; > > This also causes IDS to crash: > > execute procedure ifx_grid_connect('gridname',1);> begin; > create table test (field1 integer);> commit; > execute procedure ifx_grid_disconnect();> > If I don't use the begin/commit block, then the table is created with no > problem on both nodes(which is what I want). The set of SQL I want to execute > is much more than this, but I narrowed it down to the create table that causes > the crash. > > Interestingly enough, the table actually does get created on both nodes, even > though IDS crashes. > > The database I am using uses unbuffered logging, and I want the newly created > table to participate in replication. > > I can't find any documentation that says you should not do table creates in > begin/commit blocks in a flexible grid environment. Does anyone know if this > is a known limitation? > > Thanks, > Jeff > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. >

I had SQLTRACE set to level=low. I changed it to level=off and now I no longer have the problem. Thanks!

Ok sorry about my mistaken, really. Alexandre Marini IBM Informix Certified Professional v10 / v11.50 / v11.70 IBM Information Management Informix Technical Professional IBM Infosphere DataStage Technical Professional Database Administrator - Cleartech Ltda BRIUG website administrator Informix independent consultant > To: ids@iiug.org > From: jeffrey.genega@spirent.com > Subject: Re: IDS crashes in flexible grid create table comm [27478] > Date: Tue, 26 Jun 2012 09:37:26 -0400 > > I had SQLTRACE set to level=low. I changed it to level=off and now I no longer > have the problem. > > Thanks! > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. >

This is a classic example of why I never upgrade immediately to a new release!.. I usually wait a couple of years to make sure most of the bugs get fixed Sometimes, new releases deprecate features and compatibility which were previously available, requiring modifications or rolling back to previous the release. If something is stable and everything is properly working, don't mess with it!